Closing clients sockets after server has exited

Question

I am writing a simple client/server socket program where clients connect with server and communicate and then they send exit msg to server and then server closes the connection. The code looks like below.

server.py

import socket
import sys
from threading import Thread

try:
    sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

    # This is to prevent the socket going into TIME_WAIT status and OSError
    # "Address already in use"
    sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
except socket.error as e:
    print('Error occured while creating the socket {}'.format(e))

server_address = ('localhost', 50000)
sock.bind(server_address)

print('**** Server started on {}:{} ****'.format(*server_address))

sock.listen(5)


def client_thread(conn_sock, client_add):
    while True:
        client_msg = conn_sock.recv(1024).decode()
        if client_msg.lower() != 'exit':
            print('[{0}:{1}] {2}'.format(*client_add, client_msg))
            serv_reply = 'Okay ' + client_msg.upper()
            conn_sock.send(bytes(serv_reply, 'utf-8'))
        else:
            conn_sock.close()
            print('{} exitted !!'.format(client_add[0]))
            sys.exit()


try:
    # Keep the server until there are incominmg connections
    while True:
        # Wait for the connctions to accept
        conn_sock, client_add = sock.accept()
        print('Recieved connection from {}:{}'.format(*client_add))
        conn_sock.send(
            bytes('***** Welcome to {} *****'.format(server_address[0]), 'utf-8'))
        Thread(target=client_thread, args=(
            conn_sock, client_add), daemon=True).start()

except Exception as e:
    print('Some error occured \n {}'.format(e))
except KeyboardInterrupt as e:
    print('Program execution cancelled by user')
    conn_sock.send(b'exit')
    sys.exit(0)

finally:
    sock.close()

client.py

import socket
import sys

sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
server_address = ('localhost', 50000)
print('Connecting to {} on {}'.format(*server_address))
sock.connect(server_address)


def exiting(host=''):
    print('{} exitted !!'.format(host))
    sys.exit()


while True:
    serv_msg = sock.recv(1024).decode()
    if serv_msg.lower() != 'exit':
        print('{1}: {0}'.format(serv_msg, server_address[0]))
        client_reply = input('You: ')
        sock.send(bytes(client_reply, 'utf-8'))

        if client_reply.lower() == 'exit':
            exiting()
    else:
        exiting('Server')

What I want is in case server exits either through ctrl-c or any other way I want all client sockets to be closed and send msg to clients upon which they should close their socket as well.

I am doing below in except section but for some reason the msg sent by server is not being received by the client.

except KeyboardInterrupt as e:
print('Program execution cancelled by user')
conn_sock.send(b'exit')
sys.exit(0)

Surprisingly if I send the 'exit' msg from client_thread as srvr_reply, the client accepts the msg and exit the client socket at its end just fine. So I am not sure as to why the server is not able to send the same message in except section of the code as mentioned above.

Answer 1

I'm sorry to say that abnormal termination of TCP/IP connections is undetectable unless you try to send data through the connection.

This is known as a "Half Open" socket and it's also mention in the Python documentation.

Usually, when a server process crashes, the OS will close TCP/IP sockets, signaling the client about the closure.

When a client receives the signal, the server's termination can be detected while polling. The polling mechanism (i.e. poll / epoll / kqueue) will test for the HUP (hung up) event.

This is why "Half Open" sockets don't happen in development unless the issue is forced. When both the client and the server run on the same machine, the OS will send the signal about the closure.

But if the server computer crashes, or connectivity is lost (i.e. mobile devices), no such signal is sent and the client never knows.

The only way to detect an abnormal termination is a failed write attempt read will not detect the issue (it will act as if no data was received).

This is why they invented the ping concept and this is why HTTP/1.1 servers and clients (that don't support pings) use timeouts to assume termination.

There's a good blog post about Half Open sockets here.

---

EDIT (clarifications due to comments)

How to handle the situation:

I would recommend the following:

• Add an explicit Ping message (or an Empty/NULL message) to your protocol (the messages understood by both the clients and the server).

• Monitor the socket for inactivity by recording each send or recv operation.

• Add timeout monitoring to your code. This means that you will need to implement polling, such as select (or poll or the OS specific epoll/kqueue), instead of blocking on recv.

• When connection timeout is reached, send the Ping / empty message.

• For an easy solution, reset the timeout after sending the Ping.

  The next time you poll the socket, the polling mechanism should alert you about the failed connection. Alternatively, the second time you try to ping the server/client you will get an error message.

Note that the first send operation might succeed even though the connection was lost.

This is because the TCP/IP layer sends the message but the send function doesn't wait for the TCP/IP's ACK confirmation.

However, by the second time you get to the ping, the TCP/IP layer would have probably realized that no ACK is coming and registered the error in the socket (this takes time).

Why the send failed before exiting the server

The comment I left about this issue is wrong (in part).

The main reason the conn_sock.send(b'exit') failed is because conn_sock is a local variable in the client thread and isn't accessible from the global state where the SIGINT (CTRL+C) is raised.

This makes sense, as what would happen if the server has more than a single client?

However, it is true that socket.send only schedules the data to be sent, so the assumption that the data was actually sent is incorrect.

Also note that socket.send might not send the whole message if there isn't enough room in the kernel's buffer.