linux下非阻塞的tcp研究

思一克

你们说的发送缓冲区是setsockopt 的 SO_SNDBUF吗？

原帖由 醉卧水云间 于 2007-7-31 13:27 发表


我觉得这样更好一些：

阻塞send是可靠的发送，但为了发送的效率，最后一部分buf能容纳的数据不会要求对方确认，而是假设这部分包将来会成功发送到对方，因为短期内我们预期网络连接不会存在问题，这部分 ...

思一克

TCP阻塞send是可靠发送，意思是如果连续send成功返回，那么本次send之前的是可靠发送了的。而刚才（本次）的还是不知道。

拔NIC电缆的实验已经证明了。

还有KENREL中其实没有一个专门为了缓冲发送内容的的很大的buffer（比如8192）。有的是skb在内核中的数据。其目的也不是为了缓存，而是为了实现网络功能的数据结构------没有它不可以。如果是缓存，那么就可以没有（比如文件系统的缓存，DIRECT-IO就可以使其根本不起作用）。但skb不行。

还有SO_SNDBUF最小2048，不可能为0。因为它本来不是做cache/buffer的意义。

原帖由 醉卧水云间 于 2007-7-31 13:27 发表


我觉得这样更好一些：

阻塞send是可靠的发送，但为了发送的效率，最后一部分buf能容纳的数据不会要求对方确认，而是假设这部分包将来会成功发送到对方，因为短期内我们预期网络连接不会存在问题，这部分 ...

福瑞哈哥

原帖由 思一克 于 2007-7-31 14:17 发表
TCP阻塞send是可靠发送，意思是如果连续send成功返回，那么本次send之前的是可靠发送了的。而刚才（本次）的还是不知道。

事实上，本次之前send也不能保证就是可靠发送了的。

思一克

也有可能
你实验看，拿出验证方法。

原帖由 福瑞哈哥 于 2007-7-31 14:30 发表

事实上，本次之前send也不能保证就是可靠发送了的。

福瑞哈哥

原帖由 思一克 于 2007-7-31 14:35 发表
也有可能
你实验看，拿出验证方法。

在我的系统上，先连接上服务端。然后断掉网线，接着连续发送两次4K的数据，两次都是成功的返回4K。

icydancer

哦？没有buffer?只有sk_buff?不解！
1.skb的确是个管理结构，但是它也有指向数据buffer的指针
2.buffer是的确存在的。要不tcp窗口管理的是什么？
3.据我所知，每个skb结构只管理一个包。（不考虑分片）跟buffer没什么关系吧。
希望您解释下，谢谢 （别说让我看内核源码去）

思一克

我是说没有专门为了缓存（提高速度）的buffer. sk_buf是个管理结构，数据必须在其中。和FILE/IO的buffer是不同的。

比如skb的buffer你必须要，否则网络不会工作的。
而专门为了缓存设计的buffer是可以不要的---如果不想缓存的话。

你的理解是对的。skb有buffer的指针。指向的是数据的buffer.

原帖由 icydancer 于 2007-7-31 14:42 发表
哦？没有buffer?只有sk_buff?不解！
1.skb的确是个管理结构，但是它也有指向数据buffer的指针
2.buffer是的确存在的。要不tcp窗口管理的是什么？
3.据我所知，每个skb结构只管理一个包。（不考虑分片）跟buf ...

醉卧水云间

原帖由 思一克 于 2007-7-31 14:17 发表
TCP阻塞send是可靠发送，意思是如果连续send成功返回，那么本次send之前的是可靠发送了的。而刚才（本次）的还是不知道。

拔NIC电缆的实验已经证明了。

还有KENREL中其实没有一个专门为了缓冲发送内容的的 ...

我记得win下可以设置缓冲为0，不过也不敢肯定，还真没这么设置过，能不能设置为0和系统实现有关，逻辑上没有一点问题，没有缓冲你就直接发应用程序里的数据嘛。如果linux不允许0缓冲，那可能是没考虑给用户这样设置的自由。

醉卧水云间

原帖由 福瑞哈哥 于 2007-7-31 13:31 发表


如果要确认对方收到，还是前面朋友说的在应用层返回确认消息比较好。

常见的http就是发完关闭连接，再加一个应用层确认就烦琐了，简单的处理还是要依靠send返回值来确定是否发完数据。

福瑞哈哥

原帖由 醉卧水云间 于 2007-7-31 15:03 发表


常见的http就是发完关闭连接，再加一个应用层确认就烦琐了，简单的处理还是要依靠send返回值来确定是否发完数据。

不确认对方是否收到不是什么大事，也不是设计错误，我自己就经常这么干。没问题。