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

Reply via email to