> 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.
That was my intention, yes - I thought the header information of the OP
contained a byte count already.
> 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.
Certainly XMLRPC isn't too good - and Pyro in many aspects better. AFAIK it
uses pickle, and that means that things should be comparably compact.
Diez
--
http://mail.python.org/mailman/listinfo/python-list
