[PD] netsend/netreceive questions ...

[Roman Haefeli]

On Mit, 2017-02-22 at 18:56 +0100, Christof Ressi wrote:
> 
> > 
> > 
> > No, that's not a workable solution, even if it might seem to work
> > for
> > you. Since TCP is a stream oriented protocol and doesn't have any
> > notion of packets, you need to implement some mechanism to delimit
> > packets.
> That's correct! I was just wondering, why I thought that would
> work... I checked again and it turned out I was using
> [mrpeach/tcpsend] and [mrpeach/tcpreceive]. With these objects I can
> reliably send and receive OSC data. The help file explicitly states:
> 
> "tcpsend sends bytes over a tcp connection.
> Used in conjunction with packOSC will send OSC over tcp".
> 
> OTOH, the iemnet objects with the same name don't support that. And
> [netsend -b]/[netreceive -b] don't either, as you correctly pointed
> out. I guess, the mrpeach tcp objects use some kind of protocol
> internally to delimit messages... interesting...
I don't think so. Even with a TCP connection being a stream, TCP is
transported by IP packets. I believe what happens is that mrpeach/net
objects output each incoming chunk as a whole, or spoken from Pd view
as list. There is no guarantee whatsoever that those chunks are
received in the same configuration as they have been sent. While it
seems to work when you test on localhost, it might miserably fail with
some other network setup. TCP only guarantees that byte x[n+1] follows
byte x[n], but not that one chunk of data is also received as one chunk
of data. It might be split into two chunks, or two chunks are received
as one. 
iemnet's tcp* objects make this nature of TCP explicitly clear by
outputting only single bytes, a.k.a stream of bytes.

Roman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20170222/98158057/attachment.sig>