<div>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.</div>
<div> </div><div>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).</div><div>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.</div>
<div> </div><div>Sincerely,</div><div> </div><div>jw</div><div><br clear="all"><br>--<br>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. <br>
<br>
<br><br></div><div class="gmail_quote">On Tue, Jul 26, 2011 at 12:36 AM, Anupam Kapoor <span dir="ltr"><<a href="mailto:anupam.kapoor@gmail.com">anupam.kapoor@gmail.com</a>></span> wrote:<br><blockquote style="margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;" class="gmail_quote">
hi all,<br>
<br>
i have been playing with an implementation of tftp<br>
(rfc-1350). encoding/decoding tftp-pdu's is trivial with erlang's bit<br>
syntax.<br>
<br>
there seem to be couple of approaches to encoding/decoding tftp-pdu's:<br>
<br>
   1. use native "in-place" encode/decode<br>
   2. have a 'generic' encode/decode routine which accepts<br>
         - a list of pdu primitives e.g. 'byte'/'string' etc. and<br>
         - a list of corresponding values<br>
      and returns the binary packet.<br>
<br>
      for example, encoding a tftp-data packet looks like this:<br>
          ,----<br>
          | %% encode data packet<br>
          | encode_data_pkt(BlkNum, Data) -><br>
          |     encode_packet([?BYTE, ?BYTE, ?RAW],<br>
[?TFTP_OPCODE_DATA, BlkNum, Data]).<br>
          `----<br>
<br>
to me, approach #2 seems pretty close to rfc's packet-format<br>
specification. for example, the data-packet is shown as<br>
<br>
           2 bytes     2 bytes      n bytes<br>
           ----------------------------------<br>
          | Opcode |   Block #  |   Data     |<br>
           ----------------------------------<br>
<br>
can you please provide your suggestion on whether #2 might be a good<br>
approach to follow for complicated protocols e.g. gtp-v2 which defines a<br>
large number of messages ? also, are there better (increasing order of<br>
readability, performance etc.) approaches for doing this ?<br>
<br>
thank you<br>
kind regards<br>
anupam<br>
<br>
ps: the attached file contains encoders for tftp messages...<br>
<font color="#888888"><br>
--<br>
In the beginning was the lambda, and the lambda was with Emacs, and<br>
Emacs was the lambda.<br>
</font><br>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br></blockquote></div><br>