On Thu, 08 Feb 2007 15:56:30 +0100, "Diez B. Roggisch" <[EMAIL PROTECTED]>
wrote:
>[EMAIL PROTECTED] wrote:
>
>> On Feb 8, 3:40 am, Grant Edwards <[EMAIL PROTECTED]> wrote:
>>> On 2007-02-08, [EMAIL PROTECTED] <[EMAIL PROTECTED]> 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
--
http://mail.python.org/mailman/listinfo/python-list
