TCP is a byte stream. There is no guarantee that a given send() operation will accept all of the bytes given to it at one time. It depends on the available kernel buffer space, the I/O mode of the socket (blocking vs non-blocking), etc. send() returns the number of bytes it actually accepted and put into the kernel buffer for subsequent transmission.

In the code example shown, that return value is presumably is being returned to the caller in the nLength variable. The code is looping in case send() returns fewer bytes accepted, so the code can call send() again with the remaining unsent bytes, potentially many times until the full number of bytes has finally been sent.

This is typical coding practice for TCP programming, given the streaming nature of TCP.

TCP is a streaming transport. There is no guarantee that a given send() operation will accept all of the bytes given to it at one time. It depends on the available kernel buffer space, the I/O mode of the socket (blocking vs non-blocking), etc. send() returns the number of bytes it actually accepted and put into the kernel buffer for subsequent transmission.

In the code example shown, it appears that Socket->Send() expects nLength to be initially set to the total number of bytes to sent, and it will then update nLength with the number of bytes actually sent. The code is adjusting its nOffset variable accordingly, looping just in case send() returns fewer bytes than requested, so it can call send() as many times as it takes to send the full number of bytes.

So, for example, lets assume the kernel accepts up to 20 bytes at a time. The loop would call send() 3 times:

send(buf+0, 45-0) // returns 20 send(buf+20, 45-20) // returns 20 send(buf+40, 45-40) // returns 5 // done 

This is typical coding practice for TCP programming, given the streaming nature of TCP.