[zeromq-dev] Unreliable multicast was: udp not enabled on Mac OS X 10.6

Martin Lucina mato at kotelna.sk
Fri Mar 5 18:48:25 CET 2010

sustrik at 250bpm.com said:
> > This is starting to look the the 'udp' transport we don't have (yet) :-)
> This is starting to look messy: rename udp->epgm, then introduce brand 
> new, incompatibel udp...

Not really. As we decided, udp is renamed to epgm but a deprecated udp
'alias' sticks around for a couple more releases. The ABI is still "Beta"
so it's not set in stone.

If an unreliable udp transport is available after that then it can be
reintroduced as 'udp' if it seems like a good idea :-)

> > Why would you need to know when a packet was lost, it is after all just
> > unreliable multicast...
> > 
> > What I see as more of a problem is that UDP datagrams are limited to 65,507
> > bytes in length, so any 0MQ UDP transport (multicast or unicast) would have
> > to split and recombine messages.
> Bingo. See what packet numbers are good for?

Yes, but once you introduce sequence numbers you're going to need a
handshake to initialise those, which means a "virtual connection" of some
sort, and if you want to do that using multicast I guess you'll end up with
something like PGM anyway :-)

Now, the question is, would it make sense to make just a *plain* UDP
transport? I.e. you try to send a message larger than the maximum datagram
size, you get an error back from 0MQ. Nothing wrong with that.

You can then trivially have a connectionless unicast or multicast UDP

I guess the answer depends on what applications Chris has in mind.


More information about the zeromq-dev mailing list