On Tue, Feb 7, 2017 at 8:55 PM, Darren Smith <darre...@gmail.com> wrote: > Hi Ben, > > Thanks for the detailed reply. > > Ultimately what I'm trying to accomplish is to minimise the occurrences of > TIME_WAIT socket states on the server, and so to do that, I have to get the > client to call the close(). > > Currently this is achieved by the server sending a disconnect application > message to the client, which will react by calling close(). However there > is always the case of an uncooperative client to consider, i.e., one which > does not call close(), and instead keeps the connection open. In such cases > the server, after some time delay, will cause close(); but now it ends up > with the TIME_WAIT. So I'm trying to find a route around that TIME_WAIT > case. So I thought a server side reset could work, i.e. only perform reset > if a client has failed to call close(), and it does seem to work on my linux > box, but perhaps this relies too much on variable features of the TCP stack. > > Darren
Hi Darren, I believe what you want can for the most part be accomplished by: 1. first calling uv_shutdown(), then 2. waiting a few milliseconds to read any outstanding data and receive the EOF (in case of a cooperating client), and 3. finish by calling uv_close(). You probably cannot completely avoid TIME_WAIT that way, though. A client that simply stops replying at the TCP level because of (e.g.) a network error could still get stuck in that state. I think in that specific case it would make sense to set SO_LINGER to zero before closing the socket. If you want to pursue this, can you file an issue in the bug tracker? -- You received this message because you are subscribed to the Google Groups "libuv" group. To unsubscribe from this group and stop receiving emails from it, send an email to libuv+unsubscr...@googlegroups.com. To post to this group, send email to libuv@googlegroups.com. Visit this group at https://groups.google.com/group/libuv. For more options, visit https://groups.google.com/d/optout.
