On Sat, Jan 12, 2013 at 3:33 PM, Chris Laws clawsi...@gmail.com 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
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
