in reply to Re: syswrite and closed sockets
in thread syswrite and closed sockets

Actually I shutdown the server process, to which my socket was connected. Even so, the syswrite returned true, i.e the write succeeded.

Here is the background: my test script opens a socket to the server and sleeps for 10 seconds, followed by a syswrite on the socket. During this 10 second window, I shutdown the server process (which takes around 3 seconds). I noticed even when the server process is not there anymore, the syswrite succeeds.

Replies are listed 'Best First'.
Re^3: syswrite and closed sockets (shutdown)
by tye (Sage) on Aug 11, 2006 at 17:48 UTC

    Have the server use shutdown to make the closing of the connection be more explicit to the clients.

    I consider it a bug or design flaw that some TCP network stacks don't appear to do the equivalent of shutdown when a socket is closed, which means that the client won't know about the closure until it tries to send more data and waits a short while for the reply to that data to show up and tell it that the connection is no longer valid.


    See also (tye)Re: shutdown vs. close on INET sockets.

    If you don't have control over the server, then you can change your test to have the client:

    1. Open the socket to the server
    2. Wait 10 seconds while you stop the service
    3. Write to the socket hoping for failure
    4. If no failure, wait 10 more seconds
    5. Write to the socket again

    It shouldn't take very long for the response to a write to a closed socket to make it back to the client. However, if you shut off the server computer or break the network connection to it, then it may take 8 minutes before the client is willing to give up on the server.

    - tye        

      Thanks for the tip. Yes, my test script was able to detect the server shutdown, on syswrite, after 10 seconds sleep. This insight helped me build a workaround. Thanks.