This is normal TCP behavior. TCP Sockets will "linger" for a minute or two after being closed, and during that time the port is unusable.
Depending on your app, you can either loop until the port becomes available, dynamically choose a different port when the normal one is blocked, or just error out. On Sun, Apr 6, 2014 at 2:54 PM, Matthias Kluwe <[email protected]> wrote: > 2014-04-05 15:37 GMT+02:00 Pieter Hintjens <[email protected]>: > > It's not reusing the closed socket, so much as trying to bind to an > > endpoint that's not (yet) free. Depending on the case (especially if > > you have clients still connected), or if you are trying very rapidly > > (as in this case), TCP has not yet freed the endpoint. > > > > In this case I suspect it's because zmq_close is asynchronous and you > > aren't giving the system any time to process that. Hence looping will > > eventually "fix" the issue. > > Yes, that's very rapid and might not appear in the wild. I stumbled > upon that while tinkering with some example code. > > Asynchronous means that zmq_close does not block and the actual > operations on the OS socket are done by the background thread? Perhaps > this situation is too unusual to be mentioned by the zmq_close man > page. > > Regards, > Matthias > _______________________________________________ > 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
