[zeromq-dev] [PATCH] Moved tests off 5555 (conflict with Eclipse)

[Martin Lucina]

ph at imatix.com said:
> On Wed, May 4, 2011 at 1:32 PM, Martin Sustrik <sustrik at 250bpm.com> wrote:
> 
> >> The real use case for "bind to random port", which I have used in the past
> >> for production work, is when you have dynamic parts of your topology. You
> >> don't care about the actual port numbers used for those parts.
> >
> > Dynamic parts of the topology should connect rather than bind, no?
> 
> It's like Mato says: using a dynamic name service, a service can bind
> to "random port", then publish its presence to the name service, which
> clients then use to look up the address and port of the service.
> 
> There's a pretty complete implementation of a name service
> architecture (missing only the actual payloads) in the Guide Clone
> examples.
> 
> Mato: IMO this should be done in language bindings, not libzmq. I
> added the concept to http://www.zeromq.org/topics:binding-abstractions
> some time ago.

If you do it in the language bindings you're still propagating the
original, fragile, hack (pseudocode):

  port = port_base
  tries = 1
  while (tries < 100 && bind(port) == ERROR)
      port += 1

If you're getting low on ports, or you picked a bad port_base, or some
application on your host is hogging ports, then the above will fail.

On the other hand, if the idiom is supported by libzmq then it can pass 
a port of 0 directly to bind(2), which results in the OS allocating you a
free port. However, this requires a getsockname() API of some kind to get
the allocated port number.

-mato