linux下非阻塞的tcp研究

baohuaihuai

原帖由 yulc 于 2007-7-31 17:01 发表



time3过后,发送缓存中为0,因为得到了接收端的ack了.

可是接收缓存已经满了啊

icydancer

原帖由 yulc 于 2007-7-31 17:00 发表



我认为这个是不可确定的..

这个在linux系统还好说点，看内核里的send函数什么情况下返回。是将数据放到tcp的窗口buffer中，还是，直接调用tcp层的函数发送。
在windows里就没法证明了。

看有没有什么标准对send有规定。

ps:说道这我感觉flw说的可能是正确的，可能。。。

思一克

这是一个send()的内核调用跟踪。


15826 "telnet" d590c034 {  S} | qdisc_restart | dev_queue_xmit | neigh_resolve_output | ip_finish_output | ip_output | ip_dst_output | ip_queue_xmit | tcp_transmit_skb | tcp_write_xmit | __tcp_push_pending_frames | tcp_sendmsg | inet_sendmsg | sock_sendmsg | sys_sendto | sys_send | sys_socketcall

bluster

flw应该是对的。。。

benjiam

好像没什么意义啊！

所谓的拔网线测试更是奇怪了。 没有意义。

在阻塞和非阻赛的时候 send 没什么区别的， 都是copy 栈里面。 就返回了。 没什么区别

关键在recv

caijimin

下面是从UNIX网络编程（卷I 第3版）2.11 TCP Output摘出来的一段

The kernel will not return from the write until the final byte in the application buffer has been copied into the socket send buffer. Therefore, the successful return from a write to a TCP socket only tells us that we can reuse our application buffer. It does not tell us that either the peer TCP has received the data or that the peer application has received the data.

xiaxueyi

你们讨论得这么复杂，我问个简单的问题
在非阻塞的情况下，应用程序调用send发送数据后返回，在不与接收端再次通讯的情况下，如何知道内核有没有把发送端缓冲区的数据发出去？如果没有，如何知道错误原因？

trulyliu

TCP缓冲区防止阻塞的优化算法呢？
怎么没有提到？

yulc

原帖由 baohuaihuai 于 2007-7-31 17:10 发表

可是接收缓存已经满了啊

sorry,我不够仔细,我没有看到你所设的接收缓存是8k
这样的话,我想情况会是这样的:
由于第一次过后,缓存中还有2k的空间,所以会在ack包中告诉发送端我的滑动窗口大小为2048bytes,
这时,发送端会发一个约为1500(假设MTU为1500)大小的包过来,然后再是一个500字节的包.
这时候,如果接收应用程序还没有调用recv来获取缓存中的数据,
那么接收端会在ack中通知发送端滑动窗口已为0,需要它暂停发送.

yulc

原帖由 xiaxueyi 于 2007-7-31 17:57 发表
你们讨论得这么复杂，我问个简单的问题
在非阻塞的情况下，应用程序调用send发送数据后返回，在不与接收端再次通讯的情况下，如何知道内核有没有把发送端缓冲区的数据发出去？如果没有，如何知道错误原因？

在程序中我不知道如何得到,哪位知道,请告诉我.
我只会用netstat -a 查看, Send-Q 那列就是.