Sockets Tutorial with Python 3 part 1 - sending and receiving data

A basic TCP socket setup in Python can reliably send and receive messages, but it also exposes a key reality of networking: TCP delivers a byte stream, not discrete “messages.” That difference drives the need for buffering logic and—eventually—protocol design (like sending a header that tells the receiver how much data to expect).

The walkthrough starts by creating two files, server.py and client.py, using Python’s built-in socket library. On the server side, it creates a TCP streaming socket with socket.AF_INET (IPv4) and socket.SOCK_STREAM (TCP). The server binds to a host/port tuple—using socket.gethostname() and port 1234—then calls listen(5) to queue up to five incoming connection attempts. In an infinite loop, it accepts a connection via accept(), which returns a new client socket object plus the client’s address. After printing a connection-established message, the server sends a UTF-8 encoded payload (“welcome to the server”) using client_socket.send(...).

On the client side, the same socket type is created, but instead of binding it calls connect((host, port)). With the connection established, the client receives bytes using recv(1024), then decodes them as UTF-8 and prints the resulting text. Running server.py and then client.py demonstrates the simplest case: the client receives the message and exits. The immediate disconnect behavior is treated as a limitation of the minimal example rather than a full “long-lived” chat-style design.

The tutorial then highlights the practical buffering problem. Because TCP is a stream, recv() reads up to a fixed buffer size; if the incoming data exceeds that size, the receiver may only get part of the payload. The example changes the buffer size down to 8 bytes, reruns the client, and shows that only a fragment (“welcome”) arrives unless the client keeps reading. Adding a while True loop to repeatedly call recv() allows the client to accumulate the full message into a full_message string by decoding each chunk and appending it.

However, the stream doesn’t end just because the message “feels complete.” Without a clear termination condition, the client can hang waiting for more bytes. The walkthrough points out that the connection remains open, so the loop never naturally stops. The fix demonstrated is to rely on connection closure as the end signal: when the server sends the message and the client reads until the stream ends, the client can break and print the full message. The takeaway is that real socket applications typically avoid guessing by defining a protocol—often sending a header that specifies payload length—so the receiver knows exactly how much data to read.

The next installment is teased as the place where buffering and keeping the stream open are handled more robustly, likely with a clearer message framing approach.