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)) -- 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
