[erlang-questions] Packet size parsing

[Tony Garnock-Jones]

Hi all,


How difficult might it be to support, in the C inet runtime, a new kind
of {packet, N} option for sockets,

  {packet, N, Offset}

where
  N - number of bytes of big-endian length indicator
  Offset - byte offset within the packet of the length indicator

The length indicator would include its own bytes. The entire packet,
including header, including length indicator, would be sent as a single
binary to the process using the socket.

This scheme is suitable for IP packets, AMQP frames, etc. that are
embedded in a TCP stream, where (a) the length isn't first in the frame,
and (b) the length includes the size of the header.

For example, given {packet, 2, 2}, the C parsing code would wait for
*four* bytes to arrive, would examine bytes 2 and 3, use the resulting
big-endian 16-bit word as an indicator of how many bytes to expect
(less, of course, the four bytes already read), and wait for the remainder:

 - read N + Offset bytes
 - let Len = the big-endian N-byte word at Offset
 - wait for Len - (N + Offset) more bytes
 - pass the entire Len-byte-long binary across to the application

On the outbound leg, bytes N through N + Offset of the outbound binary
would be replaced with the total length of the packet to be sent, during
transmission.

Note that {packet, N} is not quite equivalent to {packet, N, 0}, because
the packet *including* header would be sent to the user with
{packet,N,0}, and the packet *excluding* header would be sent with
{packet,N}.

Comments?


Tony
-- 
 [][][] Tony Garnock-Jones     | Mob: +44 (0)7905 974 211
   [][] LShift Ltd             | Tel: +44 (0)20 7729 7060
 []  [] http://www.lshift.net/ | Email: tonyg@REDACTED