2

Look at this small basic python programs:

import socket

tcpsock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
tcpsock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
tcpsock.bind(("", 10000))

tcpsock.listen(10)
(sock, (ip, port)) = tcpsock.accept()

s = sock.recv(1024)
print(s)

Second program:

import socket
import time

sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.connect(('localhost', 10000))
time.sleep(1)
sock.sendall(b'hello world')

The first program is a socket server. It recv a message through the socket and display it on the console. The second program is a client which connects to the server and sends it a message.

As you can see, the server reads a 1024 bytes max length message. My client send a few bytes. My question is: How does the server knows the message ends after the 'd' char ?

I am working with sockets since years and i have always implemented a delimiter mechanism in order to know when the message stops. But it seems to work automaticly. My question is: How ? I know TCP car fragment messages. So what's happen if the paquet is trucated in the middle of my message ? Is it managed by OS ?

Thanks

Bob5421
  • 7,757
  • 14
  • 81
  • 175

1 Answers1

5

How does the server knows the message ends after the 'd' char ?

It does not. There is not even a concept of a message in TCP. recv simply returns what is there: it blocks if no data are available and returns what can be read up to the given size if data are available. "Data available" means that there are data in the sockets receive buffer, which are put by the OS kernel there. In other words: recv will not block until the requested number of bytes can be returned but it will already return when at least a single byte is in the sockets receive buffer.

For example if the client would do two send or sendall shortly after each other a single recv might return both "messages" together. This can be easily triggered by deferring the recv (add some sleep before it) so that both "messages" are guaranteed to be arrived at the client.

Steffen Ullrich
  • 114,247
  • 10
  • 131
  • 172
  • Thanks but i do not understand how recv takes decision to break after 11 chars in my case. There could be a 12th or 13th chars ? Is there a timeout ? Thanks – Bob5421 Oct 06 '19 at 13:35
  • 4
    Recv just returns as much already-received data as it can fit into your buffer. Eg If there were 11 bytes in the tcp stack’s incoming-data-buffer for your socket, and your buffer is at least 11 bytes long, then it returns 11 bytes. The number of bytes present in the tcp stack’s incoming-data-buffer will depend on how many tcp packets were received before you called recv(), and how much data each of them contained — and that will depend on the performance characteristics of the network and the (rather elaborate) algorithm tcp uses to maximize throughput in response to network behavior. – Jeremy Friesner Oct 06 '19 at 13:54