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