views:

36

answers:

1

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?

A: 

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.

bdonlan