On Thu, Jan 26, 2012 at 03:57:37PM +0100, Martin Lucina wrote:
> [email protected] said:
> > On Thu, Jan 26, 2012 at 07:53:06AM -0600, Pieter Hintjens wrote:
> > > On Thu, Jan 26, 2012 at 2:17 AM, Ian Barber <[email protected]>
> > > wrote:
> > Forgive me if I'm being dense, but couldn't the N case work if you
> > made sure to do the getsockopt() call after each zmq_bind()?
> >
> > zmq_bind(foo, "tcp://XXXX:0") zmq_getsockopt(foo,
> > GET_LAST_BOUND_PORT, &port1, sizeof(port1)) zmq_bind(foo,
> > "tcp://YYYY:0") zmq_getsockopt(foo, GET_LAST_BOUND_PORT, &port2,
> > sizeof(port2))
>
> Yup, that would work. Sorry for missing the point about zmq_bind()
> being synchronous.
>
> Ian also made a great point that this can be extended to "bind to
> unnamed endpoint" (for want of a better name) for all transports. So,
> what I think we want is that the getsockopt API should return a string
> (so as to be usable for multiple transports, plus returning a
> different-data-type-per-transport is a PITA).
>
> It'd also be nice to define a consistent way to specify this "unnamed
> endpoint" for all transports that might want to provide such
> functionality. ":0" happens to work for the tcp:// case, but does not
> really make sense for inproc:// or ipc://.
>
> This leaves us with something like this proposal:
>
> zmq_bind(foo, "tcp://XXXX:*"); // "tcp://*:*" if you want
> INADDR_ANY char endpoint [ZMQ_ENDPOINT_MAX]; zmq_getsockopt(foo,
> ZMQ_GET_ENDPOINT, endpoint, sizeof endpoint);
>
> => endpoint is filled as "tcp://XXXX:12345".
>
> zmq_bind(foo, "ipc://*"); char endpoint [ZMQ_ENDPOINT_MAX];
> zmq_getsockopt(foo, ZMQ_GET_ENDPOINT, endpoint, sizeof endpoint);
>
> => endpoint is filled as "ipc:///tmp/Xyz358hfA7".
>
> inproc:// semantics would be identical to ipc:// (w/o the /tmp/ prefix
> obviously).
>
> The use of "*" seems fairly uncontroversial -- note that this means an
> ipc:// endpoint cannot therefore contain "*" which is an (albeit
> niche) backward-incompatible change.
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?
> Thoughts? I'll ping Martin Sustrik tomorrow to see if he thinks
> there's any reason why this wouldn't work; I believe he's ignoring
> this thread as TL;DR :-)
Thanks,
--
AJ Lewis
Software Engineer
Quantum Corporation
Work: 651 688-4346
----------------------------------------------------------------------
The information contained in this transmission may be confidential. Any
disclosure, copying, or further distribution of confidential information is not
permitted unless such privilege is explicitly granted in writing by Quantum.
Quantum reserves the right to have electronic communications, including email
and attachments, sent across its networks filtered through anti virus and spam
software programs and retain such messages in order to comply with applicable
data security and retention requirements. Quantum is not responsible for the
proper and complete transmission of the substance of this communication or for
any delay in its receipt.
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
