Discover Top Posts Tagged with #tcpip

I wanna share my IP address with you.

Ping me so fucking hard all night long.

Pull my ethernet cables and make me go beep.

Beginner Problems With TCP & The socket Module in Python

This is important information for beginners, and it came up in Discord three times already, so I thought I’d write it up here.

The Python socket module is a low-level API to your operating system’s networking functionality. If you create a socket with socket.socket(socket.AF_INET, socket.SOCK_STREAM), it does not give you anything beyond ordinary TCP/IP.

TCP is a stream protocol. It guarantees that the stream of bytes you send arrives in order. Every byte you send either arrives eventually, unless the connection is lost. But if a TCP packet of data goes missing, it is sent again, and if TCP packets arrive out of order, the data stream is assembled in the right order on the other side. That’s it.

If you send data over TCP, it may get fragmented into multiple packets. The data that arrives is re-assembled by the TCP/IP stack of the operating system on the other side. That means that, if you send multiple short strings through a TCP socket, they may arrive at once, and the reader gets one long string. TCP does not have a concept of “messages”. If you want to send a sequence of messages over TCP, you need to separate them, for example through a line break at the end of messages, or by using netstrings. More on that later in this post!

If you don’t do that, then using sockets in Python with the socket module will be painful. Your operating system will deceive you and re-assemble the string you sock.recv(n) differently from the ones you sock.send(data). But here is the deceptive part. It will work sometimes, but not always. These bugs will be difficult to chase. If you have two programs communicating over TCP via the loopback device in your operating system (the virtual network device with IP 127.0.0.1), then the data does not leave your RAM, and packets are never fragmented to fit into the maximum size of an Ethernet frame or 802.11 WLAN transmission. The data arrives immediately because it’s already there, and the other side gets to read via sock.recv(n) exactly the bytestring you sent over sock.send(data). If you connect to localhost via IPv6, the maximum packet size is 64 kB, and all the packets are already there to be reassembled into a bytestream immediately! But when you try to run the same code over the real Internet, with lag and packet loss, or when you are unlucky with the multitasking/scheduling of your OS, you will either get more data than you expected, leftover data from the last sock.send(data), or incomplete data.

Example

This is a simplified, scaled-down example. We assume that data is sent in packets of 10 bytes over a slow connection (in real life it would be around 1.5 kilobytes, but that would be unreadable). Alice is using sock.sendall(data) to send messages to Bob. Bob is using sock.recv(1024) to receive the data. Bob knows that messages are never longer than 20 characters, so he figures 1024 should be enough.

Alice sends: "(FOO)" Bob receives: "(FOO)"

Seems to work. They disconnect and connect again.

Alice sends: "(MSG BAR BAZ)" Bob receives: "(MSG BAR B" - parsing error: unmatched paren

How did that happen? The maximum packet size supported by the routers of the connection (called path MTU) between Alice and Bob is just 10 bytes, and the transmission speed is slow. So one TCP/IP packet with the first ten bytes arrived first, and socket.recv(1024) does not wait until at least 1024 bytes arrive. It returns with any data that is currently available, but at most 1024 bytes. You don’t want to accidentally fill all your RAM!

But this error is now unrecoverable.

Alice sends: "(SECOND MESSAGE)" Bob receives: "AR)(SECOND ME" - parsing error: expected opening paren

The rest of the first message arrived in the mean time, plus another TCP packet with the first part of another message.

Alice and Bob stop their programs and connect again. Their bandwidth and path MTU are now higher.

Alice sends: "(FOOBAR)" This time Bob’s PC lags behind. The Java update popup hogs all the resources for a second. Alice sends: "(SECOND MESSAGE)" Bob receives "(FOOBAR)(SECOND MESSAGE)" - parsing error: extra data after end of message

If Bob had tried to only read 20 bytes with sock.recv(20) - because a message can never be longer than 20 bytes - he would have gotten "(FOOBAR)(SECOND MESS”.

And the same code would have run without a hitch when connected to localhost!

Additionally, the sock.send(data) method might not send all the data you give to it! Why is that? Because maybe you are sending a lot of data, or using a slow connection, and in that case send() just returns how much of the data you gave it could be sent, so your program can wait until the current data in the buffer has been sent over the network. This is also a kind of bug that is hard to track down if you’re only connecting to localhost over the loopback device, because there you have theoretically infinite bandwidth, limited only by the allocated memory of your OS and the maximum size of an IP packet. If you want all your data to be sent at once, guaranteed, you need to use sock.sendall(data), but sendall will block, that means your program will be unresponsive until all the data has been sent. If you are writing a game, using sendall on the main thread will make your game lag - this might not be what you want.

Solutions

You can use socketfile=socket.makefile() and use socketfile.readline() on that object. This is similar to java.io.BufferedReader in java: f.readline() gives you one line, it blocks until all the data until the next linebreak is received, and it saves additional data for the next call to readline. Of course, you also have to delimit the data you send by appending "\n" at the end of your message.

You can also use netstrings. Netstrings encode data by prepending the length of the incoming data to a message. The pynetstring module with the pynetstring.Decoder wrapper gives you a simple interface similar to readline.

If you want to send individual short messages, and don’t care if some of them get lost, you might want to look into UDP. This way, two messages will never get concatenated. Why would you want to send individual packets that might get lost? Imagine a multiplayer game where your client sends the current position of the player to the server every frame, delimited by commas and linefeeds like this “123.5,-312\n“. If a TCP packet gets lost, it is re-sent, but by that time, the player is already somewhere else! The server has to wait until it can re-assemble the stream in the right order. And the server will only get the latest position from the client after the earlier position, which is now outdated, has been re-sent. This introduces a lot of lag. If you have 5% packet loss, but you send a UDP packet with the player position every frame, you can just add time current frame number to the message, e.g. “5037,123.5,-312\n“ if that message gets lost or takes along time to deliver, and the next message is “5038,123.5,-311.9\n“, the server just updates to the newest coordinates. If a package with a timestamp older than the newest known timestamp arrives, it is ignored.

Lastly, you could do a request-response protocol, where the server responds with “OK\n“ or something like that whenever it has processed a message, and the client waits to send additional data until an OK is received. This might introduce unacceptable round-trip lag in real-time games, but is fine in most other applications. It will make bi-directional communication more difficult, because you cannot send messages both ways, otherwise both sides can send a message at the same time, expect to get an OK response, but receive something that is not an OK response instead.

#tcpip

Trending Tags

Recently Viewed Tags

#tcpip