[zeromq-dev] Binding to TCP port 0

[Ian Barber]

On Thu, Feb 9, 2012 at 5:19 PM, Pierre Ynard <linkfanel at yahoo.fr> wrote:

>
>
> I like your patch, and I'm looking forward to try it!
>

Thanks!


 I'm confused, I don't really understand the meaning of connecting to a
> wildcard.
>

It just means "fill in the name for me".

>
> A few comments follow:
>
> > +    // Allow wildcard file
> > +    if(*addr_ == '*') {
> > +        addr_ = tempnam(NULL, NULL);
> > +    }
>
> Hmm this brings a race condition, between the moment when the
> availability of the file name is checked, and the moment the socket is
> created. I don't really know how to prevent this :/
>

Yep, that was my thought that it is possible - thought given this is
somewhat edgecase functionality it may be acceptable to have a chance of a
race - all that will happen is the socket will fail to bind, so a retry
will almost certainly work.


>
> > +        // Last socket endpoint URI
> > +        unsigned char last_endpoint [256];
> > +        size_t last_endpoint_size;
>
> Wouldn't it be better to use ZMQ_ENDPOINT_MAX here?
>

Yes.


>
> > +        //  Parse the port number (0 is not a valid port).
> > +        port = (uint16_t) atoi (port_str.c_str());
>
> I think it would be better and simpler to accept both * and 0
>

Agreed.

> +        // Store the address for retrieval by users using wildcards
> > +        bound_addr_len = sprintf(bound_addr, "tcp://%s:%d", host, port);
>
> You probably want to enclose the address within [ ] if it's IPv6.
>

Will do.

>
> Also, is it really necessary to use a bound_addr buffer? It seems to me
> that in get_address() you could directly call getsockname() on the
> socket file descriptor, and build the address string directly in the
> supplied buffer. Normally this could work with IPC sockets too.
>

Ah, nice idea, can't think of a reason not too. I'll take a look and update
the patch, thanks for your feedback!

Ian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20120209/e4d40b59/attachment.htm>