[PD] netsend/netreceive questions ...

[IOhannes m zmoelnig]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20170222/05bcf343/attachment.sig>