> 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" <[email protected]> > An: [email protected] > 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 > > _______________________________________________ > [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
