> 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" <[email protected]> > An: [email protected] > 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_______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list > _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
