[erlang-questions] encoding packets a style+efficiency question

[Jon Watte]

Your "encode_packet()" really isn't that different from io_lib:format(),
except perhaps when you want to generate binary representations.
io_lib:format() takes a format string and arguments, and returns the
formatted data, much like vsprintf() in C.

Personally, I prefer to code the binaries myself, probably shallowly wrapped
in a module of encode and decode functions (much like the PDU suggestion
above).
For the one case where we rolled our own protocol, we ended up choosing
Google protocol buffers, and wrote an erlang encoder/decoder code generator
for protoc.

Sincerely,

jw


--
Americans might object: there is no way we would sacrifice our living
standards for the benefit of people in the rest of the world. Nevertheless,
whether we get there willingly or not, we shall soon have lower consumption
rates, because our present rates are unsustainable.



On Tue, Jul 26, 2011 at 12:36 AM, Anupam Kapoor <anupam.kapoor@REDACTED>wrote:

> hi all,
>
> i have been playing with an implementation of tftp
> (rfc-1350). encoding/decoding tftp-pdu's is trivial with erlang's bit
> syntax.
>
> there seem to be couple of approaches to encoding/decoding tftp-pdu's:
>
>   1. use native "in-place" encode/decode
>   2. have a 'generic' encode/decode routine which accepts
>         - a list of pdu primitives e.g. 'byte'/'string' etc. and
>         - a list of corresponding values
>      and returns the binary packet.
>
>      for example, encoding a tftp-data packet looks like this:
>          ,----
>          | %% encode data packet
>          | encode_data_pkt(BlkNum, Data) ->
>          |     encode_packet([?BYTE, ?BYTE, ?RAW],
> [?TFTP_OPCODE_DATA, BlkNum, Data]).
>          `----
>
> to me, approach #2 seems pretty close to rfc's packet-format
> specification. for example, the data-packet is shown as
>
>           2 bytes     2 bytes      n bytes
>           ----------------------------------
>          | Opcode |   Block #  |   Data     |
>           ----------------------------------
>
> can you please provide your suggestion on whether #2 might be a good
> approach to follow for complicated protocols e.g. gtp-v2 which defines a
> large number of messages ? also, are there better (increasing order of
> readability, performance etc.) approaches for doing this ?
>
> thank you
> kind regards
> anupam
>
> ps: the attached file contains encoders for tftp messages...
>
> --
> In the beginning was the lambda, and the lambda was with Emacs, and
> Emacs was the lambda.
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20110726/b33c22b1/attachment.htm>