[zeromq-dev] Binding to TCP port 0

gonzalo diethelm gdiethelm at dcv.cl
Thu Jan 26 19:58:28 CET 2012

> > > I think the "*" is fine, and it makes sense to me to extend it to
> > > all endpoint types.  I'm a bit concerned about having the full
> > > ${transport}://${path/port} string passed back.  That means that the
> > > app needs to parse that string out to get what it needs, when what
> > > it really wants is just the ${path/port} depending on the transport.
> > > Is there a reason to include more than the part of the transport
> > > string that was wildcarded?
> >
> > The immediate use case I can think of is to make an ad hoc channel for
> > communicating with a particular client and communicating the new
> > endpoint to the client via an already established channel. While that
> > my code (and possibly the client) already "knows" the transport and
> > the hostname and just needs to know the port, what it really wants to
> > communicate is the endpoint that the client should connect to. If I
> > just get the port number, then I still need to reconstruct the whole
> > endpoint string in order to connect to the new bound socket. I think
> > this is universal. Every time you bind a socket, you want something
> > connect to it, and that something needs the full endpoint address in
> > order to connect.
> Hrm...what I was thinking of was the initial establishment of a connection.
> For TCP for example, this could be via a portmapper or zeroconf, in which
> case all you care about is the port number.  I could see the full string being
> useful in the pre-established connection case, or for inproc, where the
> binding thread creates the worker threads and simply passes the inproc
> string on.
> I guess having that be the standard and either having a helper function in
> zmq proper, or in the language bindings, to do the parsing out of the wildcard
> part probably makes the most sense.

Perhaps you can have a getsockopt that returns just the "port" bound, and another that returns the full endpoint.

Gonzalo Diethelm
DCV Chile

More information about the zeromq-dev mailing list