help on packet format for tcp/ip programming

[Jean-Paul Calderone]

On Thu, 08 Feb 2007 15:56:30 +0100, "Diez B. Roggisch" <deets at nospam.web.de> wrote:
>rattan at cps.cmich.edu wrote:
>
>> On Feb 8, 3:40 am, Grant Edwards <gra... at visi.com> wrote:
>>> On 2007-02-08, rat... at cps.cmich.edu <rat... at cps.cmich.edu> wrote:
>>>
>>> > struct module pack and unpack will only work for fixed size buffer :
>>> > pack('>1024sIL', buffer, count. offset) but the buffer size can vary
>>> > from one packet to the next  :-(
>>>
>>> Oh for Pete's sake...
>>>
>>> struct.pack('>%dsIL' % len(buffer), buffer, count, offset)
>>>
>>> --
>>> Grant Edwards                   grante             Yow!  I want the
>>> presidency
>>>                                   at               so bad I can already
>>>                                   taste
>>>                                visi.com            the hors d'oeuvres.
>>
>> that is great but how does one unpack on the other side?
>
>By peeking into the header, determining the number of bytes necessary?
>
>But why do you need this anyway - if you know that you will have python on
>both ends, use Pyro or xmlrpc.
>

Grant had the right idea, I think, but he failed to actually include a
byte length in his format. :)  So there's nothing to peek at.  If the
packing is done like this, instead..


    struct.pack('!IIL', len(buffer), count, offset) + buffer

Then it is a simple matter to unpack it once the receiving side, by waiting
for struct.calcsize('!IIL') bytes, using struct to get len(buffer), count,
and offset:

    length, count, offset = struct.unpack('!IIL', bytes)

And then waiting for `length' more bytes, which will be the buffer.

I'm not sure what the original use-case was here.  XML-RPC isn't a good
transport for arbitrary binary data.  If `buffer' contains text, though,
that might be a good suggestion.

Jean-Paul