CODEWITHSUNDEEP
socketsnetwork-programmingtcpsend
ylzhang
ylzhang

Reputation: 1108

When send() returns in socket programming, what does that mean?

when send() returns, there are three possibilities:

1. the data to sent has been copied to the kernel buffer

2. the data to sent has been sent to peer

3. the data to sent has been sent to peer and received its ack

Being really confused, I read some pieces of code about TCP/IP stack in Linux source, and I found the path of the data stream:

when we use send() function, it invokes underlying sys_sendto() function, and sys_sendto() function use send_msg() to do the work, while send_msg() turns to __send_msg() and finally __send_msg() invokes scm_send() which again uses its underlying __scm_send() function.

In the whole, the data stream runs in such path:

send() ==> sys_sendto() ==> send_msg() ==> __send_msg() ==> scm_send() ==> __scm_send()

In __scm_send() function, It copies the data to the kernel's buffer.

so it seems that the first assumption is proved, is that correct, or maybe I missed some detailed or misunderstand?

Upvotes: 4

Views: 894

Answers (1)

bdonlan
bdonlan

Reputation: 231471

In general, all it guarantees is that the data has been copied to the kernel buffer. The kernel may or may not immediately initiate transmission. Indeed, there are some cases where due to TCP windowing, it may not be possible to transmit immediately.

Of course, it's possible that, immediately after copying to the kernel buffer, a context switch might occur, and by the time your process gets to run again, the packet may have been received by the peer - but this is highly unlikely.

Upvotes: 4

Related Questions