[PD] netsend/netreceive questions ...

[Christof Ressi]

> 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 at gmail.com>
> An: pd-list at 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 at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
>