2014-04-06 22:01 GMT+02:00 Lindley French <[email protected]>: > 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. Ok, but in this special case no connection has been established and I'm trying to use an endpoint *immediately* after closing the previous socket. That works within a few cpu cycles (not minutes). After all, I'm unsure when this "lingering" actually happens. When toying around with my test code to test server failure I'm always able to restart the simplified server using the same port as before. Regards, Matthias > 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
