On Sat, Jan 12, 2013 at 3:33 PM, Chris Laws <[email protected]> wrote:
> Hi, > > I am trying to use a wildcard port in an effort to let the OS assign an > ephemeral port. I then try to ascertain the actual endpoint by using the > LAST_ENDPOINT socket option so that I can inform other apps of the real > endpoint. > > This is along the lines of the suggestion here: > http://lists.zeromq.org/pipermail/zeromq-dev/2012-October/018915.html > > A simple script which demonstrates the problem is located in this gist: > https://gist.github.com/4520939 > > The output I get when I run the script: > > Python version: 2.7.2 (default, Jun 20 2012, 16:23:33) [GCC 4.2.1 > Compatible Apple Clang 4.0 (tags/Apple/clang-418.0.60)] > zmq version: 3.2.2 > pyzmq version: 2.2dev > Endpoint is tcp://192.168.1.2:* > Traceback (most recent call last): > File "zmq_test.py", line 38, in <module> > router.getsockopt(zmq.LAST_ENDPOINT) > File "socket.pyx", line 394, in zmq.core.socket.Socket.getsockopt > (zmq/core/socket.c:3915) > zmq.core.error.ZMQError: Invalid argument > > zmq.LAST_ENDPOINT is an option listed in the constants module. > > Am I doing something wrong? Is there a better way to find the actual > endpoint used when providing a wildcard port in the endpoint string to bind? > Running your script, I get: Python version: 2.7.2 (default, Jun 20 2012, 16:23:33) [GCC 4.2.1 Compatible Apple Clang 4.0 (tags/Apple/clang-418.0.60)] zmq version: 3.2.2 pyzmq version: 2.2dev Endpoint is tcp://192.168.1.193:* So my guess is you just need to recompile pyzmq, and/or make sure it's up to date. Also, it looks like ZMQ_LAST_ENDPOINT doesn't actually do what you want it to. Perhaps this should be considered a libzmq bug? > > I am aware that pyzmq has the bind_to_random_port function but that does > not really fit my need exactly as that could potentially block for some > extended period of time. > In most cases it would likely be very short but I am trying to integrate > ZMQ and Twisted together so I am trying to implement a solution that avoids > blocking where ever possible. > How long do you think bind_to_random_port can block? 1ms would be an unusually long time for that method to take (I've never seen it happen). I would just use bind_to_random_port, rather than trying to fix a problem that probably won't come up. Two reasons: 1. bind will not take more than 1ms unless there are other, much more severe performance issues going on 2. bind is a relatively rare call, so even if it were slow it generally doesn't matter -MinRK > > > Regards, > Chris > > > > > > > > > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > >
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
