[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: > > > > > Is it possible that this API should simply be on a different calls, a > > > zmq_bind_assign or similar, to avoid this clash? This could then work with > > > all transports: > > > > > > tcp/pgm: bind to random port > > > ipc: bind to random free name in system tmp > > > inproc: bind to random free name > > > > That would work, but so would a less surprising zmq_bind plus a > > getsockopt with return value depending on transport type. > > 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. 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 :-) -mato _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
