(Socket programming newbie here...)

So, for learning purposes I've just started developing a chat server and client in Python, and I was wondering how it is usually implemented.

When someone connects to the server, does the socket stay alive until the whole client is closed (All messages are sent through it), or is a new socket created for each new message?

If the second case is true, then what I've imagined by "connection" was always wrong (Since by each message a new connection is made). How does it work?


2 Answers 2


I don't know how they usually work, but when I implemented one, I chose your first approach and it worked ok. That's also how IRC works, so it can clearly scale to a reasonable number of users.

If you're opening a new socket for each message, there would be a problem in terms of how the server sends messages to the clients, who may be behind firewalls and unable to accept incoming confections. Polling is possible, and I know some early web chat clients did this, but I believe this approach is now very rare.

A third option is using UDP, where the cost of maintaining an open socket is lower (because there's no connection whose state must be maintained). I don't know if any popular chat systems do this, however.

  • Regarding the question TCP vs. UDP: You usually use UDP when you need low latency but don't need 100% reliability. Both is usually not the case with a chat system. Even a latency of a few seconds is not noticeable, but dropped messages can be very problematic. That's why most chat systems use TCP. The only situation where I would build an UDP-based chat system is as a side-feature of an UDP-based application, like a chat system in an action-oriented multiplayer game.
    – Philipp
    Oct 7, 2015 at 9:12

An image from IBM, where you can also find useful information:

Socket Connection Diagram

Below is a simple explanation of how sockets work (thus a lot more is happening during but I only figure out the basic parts)

A server defines a socket and binds an IP address and port to it. If binding is successful, then it starts to listen to that socket for incoming connections. A client sends a connection request to related IP and port and the socket server listening to that port accepts it. After the server accepts a client request, a connection is established.

You can send and receive data through that connection (step 5, 6) while the connection is active. If the client connection is closed, the Server should accept it again (step 4). accept step is done once for each new connection and that connection do not needed to be accepted again while it was active.

A server should have a specific IP and port so the client can connect it. A server could not connect to a client since client does not have any socket bound to a specific IP and port for listening incoming connections.

------------        ----------       ------------
| Client 1 | -----> | Server | <---  | Client 2 |
------------        ----------       ------------

Client 1 sends a message, the message should be received by the server since only servers can accept connections (thus, a client can not establish a connection to another client since another client can not accept any incoming connection). Server receives the message and sent it to client 2 Since a server could not establish a connection to a client, Client 2 should be already connected. Otherwise the server should wait for the client 2 to establish a connection so it can send data.

From that point of view, all clients should be connected to the server and keep those connections alive. A Client may have an active connection while it was communicating, and close that connection a while after it was idle for a specific time. But the client should establish connections to server and checks if it has any data waiting to be transferred to himself. So keeping the connection alive looks like a better approach.

There are protocols like TCP and UDP and you define the socket as a TCP socket or a UDP socket. But these protocols have many details and for simplicity, I can mention that TCP protocol is error-checked and controls if sent data is received by the receiver application (Instant messaging services told you whether your message sent is successful or not, so this is TCP). UDP have no error-check mechanism (So you just send the package but do not be confirmed whether it is delivered or not).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.