What causes a recv syscall for a socket to sometimes return less than the request len?

What causes a recv syscall for a socket to sometimes return less than the request len?

[Daniel Ellis]

Howdy,

I understand that data fragmentation happens across TCP packets, and in my
case that is what is happening.  The packets I'm seeing usually run around
1450 in length, and are always cut into two packets at the 1400 mark.  This
works fine most of the time, since the call to recv is being passed a len
of 4096 (via Python's socket.recv, which I'm assuming is just a wrapper
around the system call).  But sometimes I'll get all of the data I request,
even across TCP packet boundaries (so the full 1450 bytes), and other
times, it stops at a single packet, at which point I need to make another
recv call.

This seems to be happening more when the box is under more load (both in a
network and CPU sense), but that might be a coincidence.  Are there some
internal buffers that I could be monitoring that would correlate with these
packets being flushed out quicker?

I've changed the underlying code to correctly call recv until all the data
has been received, but I am curious as to what's going on under the hood
that made this so sporadic (and a bit of a headache to track down).  Any
help would be appreciated!

Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20160921/a85315de/attachment.html 

What causes a recv syscall for a socket to sometimes return less than the request len?

[Andrey Utkin]

On Wed, Sep 21, 2016 at 05:20:30PM -0700, Daniel Ellis wrote:
> I've changed the underlying code to correctly call recv until all the data
> has been received, but I am curious as to what's going on under the hood
> that made this so sporadic (and a bit of a headache to track down).  Any
> help would be appreciated!

Splitting and merging of chunks may happen anywhere in the pipeline
between sending and receiving _applications_. Networking stacks of
operation systems of endpoints, as well as of intermediate nodes, are
free to do whatever they decide with these chunk boundaries, because
these boundaries are not part of TCP connection user interface. Again,
it is by design that you cannot rely on these boundaries. Just always
read up to complete message if you are using TCP, or use something other
than TCP - for example, UDP seems to preserve boundaries (however there
is even more headache with UDP).

What causes a recv syscall for a socket to sometimes return less than the request len?

[michi1 at michaelblizek.twilightparadox.com]

Hi!

On 17:20 Wed 21 Sep     , Daniel Ellis wrote:
> Howdy,
> 
> I understand that data fragmentation happens across TCP packets, and in my
> case that is what is happening.  The packets I'm seeing usually run around
> 1450 in length, and are always cut into two packets at the 1400 mark.  This
> works fine most of the time, since the call to recv is being passed a len
> of 4096 (via Python's socket.recv, which I'm assuming is just a wrapper
> around the system call).  But sometimes I'll get all of the data I request,
> even across TCP packet boundaries (so the full 1450 bytes), and other
> times, it stops at a single packet, at which point I need to make another
> recv call.

The recv() call currently returns:
- as soon as there is some data in the receive queue
- all the data which is in the queue, up your buffer size.

	-Michi
-- 
programing a layer 3+4 network protocol for mesh networks
see http://michaelblizek.twilightparadox.com