CODEWITHSUNDEEP
pythonsocketsnetwork-programming
applecider
applecider

Reputation: 303

Python socket recv function

In the python socket module recv method socket.recv(bufsize[, flags]) docs here , it states:

Receive data from the socket. The return value is a bytes object representing the data received.
The maximum amount of data to be received at once is specified by bufsize.

I'm aware that bufsize represents the MAX amount of data received at once, and that if the amount of data received is LESS than bufsize, that means that the number of bytes sent by socket on the other end is less than bufsize

Is it possible that the data returned from the 1st call to socket.recv(bufsize) is < bufsize but there is still data left in the network buffer?

Eg.

data = socket.recv(10)
print(len(data))       # outputs 5
data = socket.recv(10) # calling `socket.recv(10)` returns more data without the
                       # socket on the other side doing `socket.send(data)`

Can a scenario in the example ever occur and does this apply for unix domain sockets as well as regular TCP/IP sockets?

Upvotes: 0

Views: 10268

Answers (2)

applecider
applecider

Reputation: 303

Found a similar post that follows up on this: How can I reliably read exactly n bytes from a TCP socket?

Basically use socket.makefile() to return a file object and call read(num_bytes) to return exactly the amount requested, else block.

fh = socket.makefile(mode='b')
data = fh.read(LENGTH_BYTES)

Upvotes: 1

Serge Ballesta
Serge Ballesta

Reputation: 148965

The real problem in network communication is that the receiver cannot control when and how the network delivers the data.

If the size of the data returned by recv is less than the requested size, that means that at the moment of the recv call, no more data was available in the local network buffer. So if you can make sure that:

  • the sender has stopped sending data
  • the network could deliver all the data

then a new revc call will block.

The problem is that in real world cases, you can never make sure of the two above assumptions. TCP is a stream protocol, which only guarantees that all sent bytes will go to the receiver and in correct order. But if offers no guarantee on the timing, and sent packets can be fragmented or re-assembled by the network (starting from the network TCP stack on the sender and ending at the reciever TCP stack)

Upvotes: 2

Related Questions