[PD] socket object?

IOhannes m zmoelnig zmoelnig at iem.at
Fri Feb 17 09:31:58 CET 2012

Hash: SHA1

On 2012-02-16 23:01, Martin Peach wrote:
> The [mrpeach/tcp*] classes don't make any assumptions about content,
> they just output lists of floats as they arrive. It seems more efficient
> to do that than to output individual floats. Whatever is handling the
> output of a [tcp*] should be able to decide for itself where the packet
> boundaries are. I don't assume that a list is necessarily the same
> length as a packet.

i don't think [mrpeach/tcp*] is doing anything wrong here.
on the low-level side, you get buffers of data from the socket.
[mrpeach/tcp*] passes these buffers into user-land as they are.

theer's a  reason why [iemnet/tcp*] does it slightly differently (that
is: serialize the data):
- - explicitely break the false sense of security of the user, that tcp/ip
could be packet oriented; because from user experience (mainly roman's
netpd) it shows that you must take re-fragmentation into account if you
want to make a stable system. if you receive the stream as multi-byte
chunks the user therefore ought to serialize it manually.
- - for performance reasons, it is way more efficient to do the
serialization in C than in Pd.

]btw, you can turn off automatic serialization with [iemnet/tcp*", but i
would not advise to do so.

Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3636 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20120217/63347be2/attachment.bin>

More information about the Pd-list mailing list