[nanomsg] Re: How to bind on a random port?
- From: Matt Howlett <matt.howlett@xxxxxxxxx>
- To: nanomsg <nanomsg@xxxxxxxxxxxxx>
- Date: Sat, 15 Nov 2014 07:51:25 +0700
The behavior of nn_bind was also unexpected me. My work-around is to find a
free port outside of nanomsg, then immediately bind to it. I stagger the
start up of my workers (~1 worker per core per machine) so in practice I
never get a race condition. Not ideal, but it works. If you can control
when all of the processes that bind to random ports start up on each node,
you can do the same thing, though it sounds like your situation might be
more difficult.
On Fri, Nov 14, 2014 at 10:30 PM, xreborner (Shixi Chen) <
xreborner@xxxxxxxxx> wrote:
> Unfortunately, I'm running a distributed computation application on a
> cluster with thousands of machines, in each machine there could be multiple
> tasks are running in background and have occupied some random ports. If I
> just choose a random port (in fact, i use not only one port) and use it,
> there are roughly 1% probability to fail in one machine. If my application
> is running on 200 machines, then it almost always fail.
>
> On Fri, Nov 14, 2014 at 11:05 PM, Martin Sustrik <sustrik@xxxxxxxxxx>
> wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 14/11/14 15:55, xreborner (Shixi Chen) wrote:
>> > So, if i don't know any port numbers that are available, it is
>> > impossible to use nanomsg?
>>
>> Yes. Although on a typical machine, almost all ports are unused, so
>> just picking one and using it tends to work.
>>
>> > My program is to be run on a remote cluster, where no port numbers
>> > are known to be reserved. I was using zeromq and my solution was to
>> > repeat calling zmq_bind. I'm considering to switch to nanomsg since
>> > it looks better (and also due to some problems in zeromq). Is there
>> > any plan to solve this problem in the future?
>>
>> I was thinking of implementing tcpmux (RFC 1) but it's not coming any
>> time soon.
>>
>> Martin
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.11 (GNU/Linux)
>>
>> iQEcBAEBAgAGBQJUZho9AAoJENTpVjxCNN9YouMH/RI/d9AismH7RuEH7aY6oOQV
>> snl5ad/wZsupguf5uGtYfomnJOMtMrwLo+qEHK+u5JCWmBN73VikfJuJtwZs/lsg
>> umD1xt6tGvOyxmI1V1bzXkNASyUktPpjedA0xgbBXlw8KwsDTTKIRaVCwNQt+FND
>> tKKMHIQKJ9B0qmD8UrlT8fg1qwLsG/HUgr1JrkVw1+yLnaGXzwCdxWO49F3X+dEl
>> aXwIO1cZrcpB+hPb7lemn4pWQDa//JiIbE4wbg7aT4ecgIWFd4UheHQfSBr8ZniH
>> XjeGlJcJ4IDos9DzfNTKgj07lgGoMB+lt/7M+qr+Mh4AjJZTgYM11nGyp0ljpQg=
>> =jgr1
>> -----END PGP SIGNATURE-----
>>
>>
>
Other related posts:
