linux下非阻塞的tcp研究

yulc

原帖由 cookis 于 2007-7-31 12:20 发表
各位大师..讨论之余能否给一些经验值...在视频传输应用中,非阻塞的情况下sendbuf_len or recvbuf_len 在TCP UDP下通常设为多大

这个要看你的网络情况以及服务器的负载情况而定.
你用默认的数值试试,如果哪方面不满意,再去做优化.

醉卧水云间

原帖由 福瑞哈哥 于 2007-7-31 12:49 发表
在阻塞模式下，如果发送包大于缓冲区长度，那中间肯定有一次要把发送端缓冲区的数据通过网络传送到接受端缓冲区。如果这时网络或者对端有问题，send会失败。

还有在发送端已知对方关闭或连接断掉的情况，sen ...

把缓冲设置为0所有send都是被对方确认的。因为有缓冲，所以才出现这种情况。

福瑞哈哥

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



把缓冲设置为0所有send都是被对方确认的。因为有缓冲，所以才出现这种情况。

是的，你把缓冲设置成比发送包大就不用等待确认了。

醉卧水云间

所来说去，buffer在这里起重要作用。

阻塞send本意是要发到对方确认的，但唯独buffer能容纳的那部分它不会被立刻发出确认。但它的主意很显然是一个需要对方确认的发送。

醉卧水云间

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

是的，你把缓冲设置成比发送包大就不用等待确认了。

是已经确认了，但刨掉还在buf内的那部分，有时可能会全发出去，有时可能会留下部分直接返回全部字节。

醉卧水云间

原帖由 思一克 于 2007-7-31 10:43 发表
send后，KERENL回立即启动dev发送.
write/send不会等待数据是否成功到达对方。
即使返回成功也不代表数据成功到达。
但返回错误却代表数据没有到达。

还是要等的，特例是buf能放下这些字节。

福瑞哈哥

原帖由 醉卧水云间 于 2007-7-31 13:14 发表
所来说去，buffer在这里起重要作用。

阻塞send本意是要发到对方确认的，但唯独buffer能容纳的那部分它不会被立刻发出确认。但它的主意很显然是一个需要对方确认的发送。

还不如把阻塞send理解为「尽量发送全部数据，如果缓冲区满就先想办法清空缓冲区」更好一些。

醉卧水云间

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


还不如把阻塞send理解为「尽量发送全部数据，如果缓冲区满就先想办法清空缓冲区」更好一些。

我觉得这样更好一些：

阻塞send是可靠的发送，但为了发送的效率，最后一部分buf能容纳的数据不会要求对方确认，而是假设这部分包将来会成功发送到对方，因为短期内我们预期网络连接不会存在问题，这部分包将少后0.x秒发送出去，因为有这部分数据的存在，我们建议你不要信任send返回值，如果你依赖于这个返回值，比如发完数据检查返回正常立即关闭连接，则把发送缓冲设置为0会更稳妥。

yulc

原帖由 醉卧水云间 于 2007-7-31 13:27 发表 我觉得这样更好一些：

阻塞send是可靠的发送，但为了发送的效率，最后一部分buf能容纳的数据不会要求对方确认，而是假设这部分包将来会成功发送到对方，因为短期内我们预期网络连接不会存在问题，这部分包将少后0.x秒发送出去，因为有这部分数据的存在，我们建议你不要信任send返回值，如果你依赖于这个返回值，比如发完数据检查返回正常立即关闭连接，则把发送缓冲设置为0会更稳妥。

概括得比我要好..
我原来的理解是错的,我更改一下贴子.

福瑞哈哥

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


我觉得这样更好一些：

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

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