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
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
