[PD] netsend/netreceive questions ...

[Christof Ressi]

> 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]) 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!).

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.

As you probably know, UDP is faster but error-prone, e.g. packages might get lost or be received in the wrong order.
TCP has a handshake mechanism which makes it slower but very reliable.

The rationale is this: If a message *must* arrive (like going to the next scene in a show) and your network connection is unstable or quite busy, use TCP. Otherwise go for UDP. 

Now some personal and second-hand experiences:

I never had a problems when sending UDP via localhost. However, I met a guy who got UDP package loss even on his localhost. Personally I never experienced this but it might happen if you send too much data.

I did experience package loss when sending UDP packages via network, more often with Wifi but also with Ethernet, but either the network was busy or the amount of data was quite large. When I switched to TCP everything was fine. 

For sending big lists of filenames I'd definitely go for TCP. Regarding the video syncing, it depends. If packet loss is theoretically acceptable - although it's certainly not desired -, go for UDP, otherwise TCP. 

Unfortunately, not all programs can handle OSC over TCP...


Regarding your question if you should use internals or externals: IIRC the iemnet objects are threaded (also true for the mrpeach net objects?) whereas the internal objects are not and may therefore block Pd on heavy traffic. IOhannes or others may please correct me!

Christof

*simple protocol used by Pd in [netsend]/[netreceive] (without the -b flag!) https://en.wikipedia.org/wiki/FUDI


 

> Gesendet: Mittwoch, 22. Februar 2017 um 11:57 Uhr
> Von: oliver <oliver at klingt.org>
> An: pd-list at mail.iem.at
> Betreff: [PD]  netsend/netreceive questions ...
>
> hi, a more general question about internal network communication:
> 
> which method would you say is the "best" way to communicate between PD 
> and other applications like MAX, GEM, VVVV in terms of speed and 
> reliability ?
> 
> i'm asking for a huge project that should be able to send/receive 
> time-critical messages (for video-synching) AND also big lists of 
> filenames etc. across applications.
> 
> maybe it's better to use [OSC] for the latter and [netsend] for single 
> floats (f.e. to send a time-synch message) ?
> 
> is it better to open more than one port (or is it a socket ?) for this 
> purpose or will that make things worse ?
> 
> should i use vanilla's [netsend] or are there other externals better 
> suited for this task ?
> 
> what are your experiences in this regard ?
> 
> 
> thanks a lot !
> 
> oliver
> 
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
>