linux下非阻塞的tcp研究

flw

思一克也是对的，
只是思一克过于强调内核实现，
我认为应用层的事就是应用层的事，
虽然本帖标题是 Linux 下的 TCP，
但是相信很多人都在非 Linux 平台比如 BSD、Unix 等平台下有工作任务，
即使是 Linux 内核本身，它也是在进化当中，目前不才 2.x 嘛。
因此我不赞成将内核实现牵扯到本帖的讨论中来。

福瑞哈哥的意见也是对的。

feasword

应用层对tcp说，老兄，发1000个字节数据
对于阻塞的socket，
tcp说，ok，有地方，给我吧，你走先,send返回
或者
tcp说，我这没地方了，你等等，我腾个地方出来，send阻塞，直到收到前面某个afk，能清出空间放这1000字节数据。
假如tcp见到点数据就让应用层等回复，那tcp的n个k的缓冲区，tcp所谓流的n多算法，还有存在的必要么？

思一克

TCP的标准设计估计是帖子引用的那样。所以说send将数据COPY到buffer就返回了应该也没有问题。但是LINUX上的有些出入

我看了LINUX TCP代码，对于send ( tcp_sendmsg)有结论：
1）tcp_sendmsg 将数据COPY到buffer, 并不是（将发送任务交给TCP）立即返回。而是，根据情况判断，如果该发送了，自己启动网络设备发送，然后再返回。也就是说，TCP本身不是一个独立的消费者进程（象kblockd, aio那样，read/write路径将数据请求填充buffer, 然后就返回，等待它们读写磁盘完成）， 我前面帖子给出的调用路径说明了这一点。----- 为什么要这么做？而不是如同“标准”说的那样？我分析主要是考虑效率。你想，USER APP send了100个字节，如果你将100个字节拷贝到buffer就返回，返回前势必通知TCP（KENREL THREAD，如果有的话）发送。这就有进程切换（代价比100个字节处理要浪费的多），自己直接做是最快的。
那为什么kblockd（磁盘）这样实现？磁盘是机械设备读写非常慢，有切换的代价也值得。而网卡不是机械的东西，将数据给网卡比给磁盘快的多。

2）tcp_sendmsg要对网络状态做许多检查，如果不能发送了，就给send许多关于网络的错误信息返回。

3）tcp_sendmsg只要填充了buffer(说明目前网络还没有什么问题），就会返回成功的字节数目。也即使说，无论启动网络设备发送的结果如何，对返回没有影响。所以send返回成功，根本不代表数据发送到对方了，仅仅代表到本地buffer了，或者已经送本地网络设备了。

原帖由 benjiam 于 2007-7-31 17:41 发表
好像没什么意义啊！

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

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

关键在recv

[ 本帖最后由 思一克 于 2007-8-1 10:05 编辑 ]

benjiam

回一下，当时回的时候比较草率，抱歉。  其实还是有很多细节，我们并没有仔细检查过， 比如上次和我搭伙的一个java 代码因为网络处理有问题，我采用的是阻塞发生，结果出现了windows 为0 的情况。而我的线程就挂在send 上面。 其实这种非常细的问题太深入又点失去它的意义了。  一般在应用层面上都会有确认。 因为UNP 说的 即使对方真的recv 成功了，你也不能保证别人在处理的时候不崩溃。的确是这样的。
  但我认为send 争论的焦点在于， 阻塞成功了，是否会出现对方tcp 栈其实没有收到这种情况。因为在应用层协议不是很完善的情况下。很多时候，发送端靠发送成功作为某些流程的行进的一个标志。 但是目前看来 是会的。 概率很小，但是的确会. 某些特殊的情况下 会。

bical

mark

marco_hxj

delete by m

[ 本帖最后由 marco_hxj 于 2009-10-15 12:55 编辑 ]

cskyrain

问一下：有统一说法没

xzh_endless

看方法下原文的解说，有这么一句，
When  the message does not fit into the send buffer of the socket, send() normally blocks, unless the
       socket has been placed in non-blocking I/O mode.

kkndmammoth

好贴，mark.

酒饮微醉

原帖由 flw 于 2007-7-31 09:51 发表
【在阻塞模式下,send函数的过程是将应用程序请求发送的数据通过socket尽能力发送到对方接收缓存中(并非对方应用程),并返回成功发送的大小;】

这句话是错的吧？
我认为即使是在阻塞方式下，只要发送缓冲区还 ...

支持！！