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