0

I got a snippet from internet for send data through a socket .

Here is the code .

u32_t nLength = 0; u32_t nOffset = 0; do { nLength = nFullLength - nOffset; status = Socket->Send(((u8_t*) buff) + nOffset, &nLength); if (status != ERROR_SUCCESS) { break; } nOffset += nLength; } while (nOffset < nFullLength); 

My doubts are :

When send(sock_fd, buf+bytes, buflen-bytes, flags); function running , it will send the entire data ?

Let's assume i have a buff with 45 byte length . So it will send like

send(buf+0, 45-0) = send(buf+0, 45); 

So it will send complete data with length 45 ? what is the use of length here ? initially it will 45 . Isn't ?

7
  • What is Socket? What is the implementation of Send()? Without those, it's impossible to be certain any answer is correct. And are you sure this is C code? It looks a lot like C++. Commented Mar 30, 2017 at 12:18
  • This is same as normal socket -- send(sockfd , buf , buf_len ) Commented Mar 30, 2017 at 12:20
  • Why do you have a loop there? In the first iteration itself nLength becomes equal to nFullLength and entire data is sent if possible and loop exits!! Commented Mar 30, 2017 at 12:23
  • 1
    @prashanthns In the first iteration itself nLength becomes equal to nFullLength and entire data is sent if possible and loop exits!! Because the entire data may not be sent. Read the standard for send(). Commented Mar 30, 2017 at 12:26
  • 1
    @prashanthns nLength will be modified by Send() to the count of bytes written. So nOffset will be incremented by bytes written. Commented Mar 30, 2017 at 13:15

2 Answers 2

1

Well, no. There's no guarantee that it will send all the data you ask it to send, that's why the code looks the way it does.

The manual page for send() states this pretty clearly:

Return Value

On success, these calls return the number of characters sent. On error, -1 is returned, and errno is set appropriately.

The same is true for e.g. a regular write() to a local file, by the way. It might never happen, but the way the interface is designed you're supposed to handle partial sends (and writes) if they do happen.

Sign up to request clarification or add additional context in comments.

Comments

1

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.

1 Comment

Thanks @Remy Lebeau for your valuable suggestion

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.