[PD] netsend/netreceive questions ...

[Christof Ressi]

> SLIP-encoding is the only proper way to transmit OSC over TCP.

thanks! didn't know that. makes sense now. 

> Gesendet: Mittwoch, 22. Februar 2017 um 15:41 Uhr
> Von: "IOhannes m zmoelnig" <zmoelnig at iem.at>
> An: pd-list at lists.iem.at
> Betreff: Re: [PD] netsend/netreceive questions ...
>
> On 2017-02-22 15:16, Christof Ressi wrote:
> > 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, this is broken by design.
> 
> > 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!).
> 
> SLIP-encoding is the only proper way to transmit OSC over TCP.
> TCP/IP is a stream-based protocol (like the serial-line used by
> [comport]), whereas OSC is a packet-based protocol.
> to transmit packets over a data stream, you must somehow packetize it;
> SLIP is the suggested format for doing that.
> 
> > 
> > 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.
> 
> FUDI takes 1 to 9 bytes to transmit a single float, OSC always takes
> exactly 4 bytes.
> 
> OSC transmits the float with full precision, whereas FUDI will truncate
> and whatnot.
> 
> > For sending big lists of filenames I'd definitely go for TCP.
> > Unfortunately, not all programs can handle OSC over TCP...
> >
> 
> UDP-packets are limited in size (maximum 65536 bytes).
> so if you are sending large amounts of data, make sure that a single
> message doesn't exceed this size.
> (e.g. use multiple messages)
> 
> speaking of filenames: if you want to transmit strings/symbols with
> spaces (filenames on w32), OSC is certainly the better protocol (FUDI
> will split on the space).
> 
> > 
> > IIRC the iemnet objects are threaded (also true for the mrpeach net objects?) 
> 
> both are threaded.
> but iemnet uses a single worker thread to send the data, whereas
> mrpeach/net spins up a separate thread for each message.
> 
> afaict, this makes iemnet perform much better when dealing with large
> amounts of data.
> e.g. you can use it to saturate a 100MBit connection without audio
> dropouts (that is: without dropouts from the transmission itself; doing
> anything with that data will most likely clog your CPU).
> at least IIRC (i'm pretty sure about being able to saturate the
> connection; less sure about now audio dropouts)
> 
> mrpeach/net should block less than the built-in object, but in theory it
> might still block when spinning up to many threads.
> also mrpeach/net is prone to race-conditions, where one sending thread
> can overtake another sending thread (so the order of data arrival is not
> guaranteed). obviously mrpeach/net doesn't always exihibit that problem
> (else nobody would use it), but iirc i was able to trigger that
> behaviour in a lab situtation.
> 
> 
> fgsdr
> IOhannes
> 
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
>