[OSC_dev] OSC over ZeroMQ

[Gaspard Bucher]

Hi there !

I have been looking at the ZeroMQ <http://www.zeromq.org/> library and found
that it does many things (surely much better) that the oscit library does:

1. handle subscriptions from not-yet-connected devices
2. handle different types of connections depending on protocol
(inter-process communication, network communication, in-process, etc)
3. fully asynchronous
4. reliable channel (both in terms of low jitter and ensured packet
delivery)


I think it should not be too hard to add ZeroConf on top of this.

The only drawback is that this library is using TCP for network connections.
Since I really want to be able to concentrate on the application layer of
oscit (make distributed OSC based systems easy) and not reinvent a transport
layer, I might use this library and see if the latency is really a problem
or if it's just a haunting ghost.

The typical latency of my sound system is around 5-10 ms (256-512 samples @
44.1kHz), whereas the measured latency of ZeroMQ is around 50us (0.05ms) (
http://www.zeromq.org/results:more-precise-0mq-tests).

This means that the latency of TCP transport with ZeroMQ is 220 times
*lower* then what I can easily handle (musically) with my sequencer.

What are your latency requirements ? Is 50us for transport too much ? Why ?

Cheers,

Gaspard

[Roger Dannenberg]

Thanks for the link. Looks very interesting. Whatever the claims, a
system built over TCP is not going to outperform TCP, so you should
probably be more concerned about latency in your network than whatever
OSC or 0MQ adds to that. If you are not going long distance through
multiple routers and you can afford a couple milliseconds for
retransmission whenever a packet gets lost, TCP seems like the way to go.

I've said this before, but regarding TCP and UDP, one way to think about
it is this: Most packets are going to be delivered just fine, with about
the same latency, overhead and performance. The significant difference
is what happens if/when a packet is dropped. Under TCP, the data will
show up, but it will be late (probably it will be detected on the next
message, and recovery will take about a round-trip time over the
network). Under UDP, the packet simply disappears. If your premise is
that packets are never dropped and therefore UDP is OK, then TCP offers
to guarantee your premise with a small overhead. In other scenarios, UDP
and TCP are really different, which is why both choices live on.

-Roger

Post by Gaspard Bucher
Hi there !
I have been looking at the ZeroMQ <http://www.zeromq.org/> library and
found that it does many things (surely much better) that the oscit

[Adrian Freed]

Under UDP, the packet simply disappears. If your premise is that packets are never dropped and therefore UDP is OK, then TCP offers to guarantee your premise with a small overhead. In other scenarios, UDP and TCP are really different, which is why both choices live on.
-Roger

Thanks, Roger.
There is a sneaky advantage we have been enjoying for years with UDP which may no longer by as widespread but it used to be common practice for routers and switches to prioritize UDP packets over TCP packets - especially in congestion scenarios. This is not just a consideration for big routers. $100 "gaming routers" allow users to set priorities on certain traffic types. Remember that the internet is premised on best efforts so such gaming of the traffic is "fair game" for everyone. Even though QOS protocols are available to formalize these tricks end to end, it is rather common (on our campus for example) to not implement them and instead use predictive overprovisioning .

The upshot of all this is that it is wise to invest some time measuring and tuning in your application and putting the effort into keeping your options open as to how encode your OSC.
At CNMAT we use SLIP wrapped USB serial point to point, TCP/IP on Gig. ethernet, and sometimes TCP/IP over firewire on small private networks. In the TML at Concordia where I am a visiting scholar this fall, they use Gig Ethernet on private networks created by doubling the number of ports on each computer. You can partition traffic types on each network this way if you want.