[zeromq-dev] Is UDP transport needed in ZeroMQ?

Pieter Hintjens ph at imatix.com
Sun Dec 29 20:23:08 CET 2013

On Sat, Dec 28, 2013 at 3:24 PM, Daniel Krikun <dkrikun0 at gmail.com> wrote:

> I'm not saying the patterns suck, they surely do not, personally I think
> they are very helpful, but they are not perfect. Maybe plain udp can be
> easier to grasp.

The point is that you can use higher level semantics like pub-sub and
then map them to physical transports depending on the actual location
and granularity of your processes, nodes, threads, etc.

For instance you can write a pub-sub event broadcast / collection
layer that works across inproc:// for threads, pgm:// for large
clouds, or udp:// for local networks or tcp:// for wide area networks.
The code and patterns don't change when your location / granularity
does. Further you can mix transports cleanly.

If you can't see the benefits of this, in building truly scalable
architectures, then you are simply not yet working at that challenge
level. If you hand-code transports you are building knowledge of your
scale and granularity into your code... it's of course doable, even
*easy*. It's just utterly unscalable.

Something like zbeacon is justifiable *only* because it is an
abstraction that hides the fact it's using UDP. You could extend
beaconing to work over other protocols, and we might do that.

And then the real costs of socket programming, portability etc. Just
take a look at zbeacon for this. To ask that application programmers
should be aware that (to take one example) on OS/X you have to use
SO_REUSEPORT, or to deal with the insanity that is Winsock...
please... I thought we way were past this. 20 years ago I was hiding
socket i/o in portability libraries like SFL[1].


[1] https://github.com/imatix/Xitami-25/blob/master/sfl/sflsock.c

More information about the zeromq-dev mailing list