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...
Gesendet: Mittwoch, 22. Februar 2017 um 16:08 Uhr Von: "Roman Haefeli" reduzent@gmail.com An: pd-list@lists.iem.at Betreff: Re: [PD] netsend/netreceive questions ...
On Mit, 2017-02-22 at 15:16 +0100, Christof Ressi wrote:
maybe it's better to use [OSC] for the latter and [netsend] for single floats (f.e. to send a time-synch message) ?
OSC is just a way to format your data and is independend from the actual protocol you use for transmitting the data. Most of the time you'll find OSC over UDP (e.g. [packOSC] -> [netsend -u -b] etc.) but it can also be TCP ([packOSC] -> [netsend -b])
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. OSC 1.0 proposed a 4-byte header to be prepended to each OSC packet that reflects the packet size. However, once the reading side gets it wrong, it will never able to the find the correct start of a packet again. That's why OSC 1.1 proposed SLIP encoding for serial / stream-oriented transports.
or SLIP for sending over a serial connection ([packOSC] -> [mrpeach/slipenc] -> [comport]). I've once worked with an Ion lighting console which expected SLIP encoded OSC over TCP (wtf!).
Absolutely no WTF. See above.
OSC itself just provides some convenience, it can be more efficient or not, depending on the message type. If you're just sending a single number, then FUDI* might make more sense. The difference might be neglectible, though.
I don't see a reason for OSC when both sides are Pd. FUDI isn't as common as OSC, though.
Roman_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list