16,472
社区成员
发帖
与我相关
我的任务
分享socket接收缓冲区的大小问题
一.这里的接收缓冲区是指
调用recv(buff)时传递的参数buff,我问题是:
1.采用TCP,那么发送端发送的数据包大小是不确定的,那么接收端如何来设置这个buff的大小,因为太小了,要多次调用recv才能
接收完整.
2.采用UDP,如果这个buff的大小,会丢失数据.
3.还有一个问题,如果采用UDP,而且有几十台机子会像这个UDP来发送数据,而且有可能是几乎同时发送,那么udp协议好像没有缓冲区(指协议中的底层那个缓冲区)来存储数据包,那么接收端是否会丢失数据,要怎么处理??
调用recv(buff)时传递的参数buff,我问题是:
1.采用TCP,那么发送端发送的数据包大小是不确定的,那么接收端如何来设置这个buff的大小,因为太小了,要多次调用recv才能
接收完整.
2.采用UDP,如果这个buff的大小,会丢失数据.
3.还有一个问题,如果采用UDP,而且有几十台机子会像这个UDP来发送数据,而且有可能是几乎同时发送,那么udp协议好像没有缓冲区(指协议中的底层那个缓冲区)来存储数据包,那么接收端是否会丢失数据,要怎么处理??
...全文
请发表友善的回复…
发表回复
Kuntakimp 2009-02-20
- 打赏
- 举报
学习学习
ggmfc 2009-02-20
- 打赏
- 举报
UP!学习了！
yupengchen951124 2009-02-20
- 打赏
- 举报
setsockopt()
该昵称不能识别 2009-02-19
- 打赏
- 举报
[Quote=引用楼主 czcwzw 的帖子:]
一.这里的接收缓冲区是指
调用recv(buff)时传递的参数buff,我问题是:
1.采用TCP,那么发送端发送的数据包大小是不确定的,那么接收端如何来设置这个buff的大小,因为太小了,要多次调用recv才能
接收完整.
可以尽量设置大一点,比如2M或4M,如果一次发送的内容更大的话,还是得用多次recv
2.采用UDP,如果这个buff的大小,会丢失数据.
一般采用64KB,因为UDP不能大于64KB
3.还有一个问题,如果采用UDP,而且有几十台机子会像这个UDP来发送数据,而且有可能是几乎同时发送,那么udp协议好像没有缓冲区(指协议中的底层那个缓冲区)来存储数据包,…
如果接收端来不及处理,UDP包会被自动丢掉
[/Quote]
一.这里的接收缓冲区是指
调用recv(buff)时传递的参数buff,我问题是:
1.采用TCP,那么发送端发送的数据包大小是不确定的,那么接收端如何来设置这个buff的大小,因为太小了,要多次调用recv才能
接收完整.
可以尽量设置大一点,比如2M或4M,如果一次发送的内容更大的话,还是得用多次recv
2.采用UDP,如果这个buff的大小,会丢失数据.
一般采用64KB,因为UDP不能大于64KB
3.还有一个问题,如果采用UDP,而且有几十台机子会像这个UDP来发送数据,而且有可能是几乎同时发送,那么udp协议好像没有缓冲区(指协议中的底层那个缓冲区)来存储数据包,…
如果接收端来不及处理,UDP包会被自动丢掉
[/Quote]
hityct1 2009-02-19
- 打赏
- 举报
1）自己可以实测估计一个值。尤其在非阻塞模式下，调用一次recv接收到的数据未必是一个数据包，多个，半个，0.3个，2.8个都有可能。
2）可以看看这个
http://topic.csdn.net/t/20041227/15/3679599.html#
3）UDP不可靠，丢失了重发
2）可以看看这个
http://topic.csdn.net/t/20041227/15/3679599.html#
3）UDP不可靠，丢失了重发
cnzdgs 2009-02-19
- 打赏
- 举报
1、如果大量传输数据，可以另建新连接来处理。
3、感觉500B以下应该基本不会有丢包的情况。
3、感觉500B以下应该基本不会有丢包的情况。
czcwzw 2009-02-19
- 打赏
- 举报
1.我的程序在大部分时间处理的数据包不大,会小于2048,不过有时候需要处理比较大的数据包.
3.多台主机同时向一个目标发送数据,这个是没法避免了,但是他们每次发的数据包都很小,500B以下.
如果接收缓冲区设大一点行不行
3.多台主机同时向一个目标发送数据,这个是没法避免了,但是他们每次发的数据包都很小,500B以下.
如果接收缓冲区设大一点行不行
cnzdgs 2009-02-19
- 打赏
- 举报
1、如果你的程序每次要处理的数据长度是2048或者小于2048，可以这样定。
2、我说的最大可能长度是指你的程序发出的所有包中长度的最大值，不一定是64KB。
3、如果要减少这种情况的发生几率，最好还是设法避免多台主机同时向一个目标发送数据。
2、我说的最大可能长度是指你的程序发出的所有包中长度的最大值，不一定是64KB。
3、如果要减少这种情况的发生几率，最好还是设法避免多台主机同时向一个目标发送数据。
czcwzw 2009-02-19
- 打赏
- 举报
1.我是这么想的:刚开始设置2048,然后记录每10次使用的结果,之后在求10次的平均值,重新调整大小,
这样有时候需要多次调用,一下子设置为最大不太好吧,因为有的数据包很小,而且如果大部分都很小,
少部分的很大,那你设很大就滥费.只不过看看大家有没有什么方法.
2.可能控制包大小不要超过数据包的最大可能长度比较好.
3."如单独开一个线程专门接收数据，处理使用另外的线程处理，使用固定长度队列，避免使用资源抢占（如加锁） "
4楼的方法倒是可以考虑
这样有时候需要多次调用,一下子设置为最大不太好吧,因为有的数据包很小,而且如果大部分都很小,
少部分的很大,那你设很大就滥费.只不过看看大家有没有什么方法.
2.可能控制包大小不要超过数据包的最大可能长度比较好.
3."如单独开一个线程专门接收数据，处理使用另外的线程处理，使用固定长度队列，避免使用资源抢占（如加锁） "
4楼的方法倒是可以考虑
homesos 2009-02-19
- 打赏
- 举报
UDP也有重发机制，但只是重发仍在缓冲区中的数据包，如果缓冲区中没有则不重发。
楼主可以先把发送端缓冲区设置大一点试试，如果效果不好，直接把发送缓冲区设置为0，再看看效果。
楼主可以先把发送端缓冲区设置大一点试试，如果效果不好，直接把发送缓冲区设置为0，再看看效果。
homesos 2009-02-19
- 打赏
- 举报
1.把客户端接收缓冲区设置大一些 调用setsockopt()进行设置
2.使用UDP很容易导致IP分片,在一个以太网上，数据帧的最大长度是1500字节，其中1472字节留给数据，其余28字节的填充为IP、UDP信息，所以发送的数据包最好不要大于这个值。
3.同第一点，把客户端接收缓冲区设置大一些 设置为几M，并尽量加快客户端处理，如单独开一个线程专门接收数据，处理使用另外的线程处理，使用固定长度队列，避免使用资源抢占（如加锁）
2.使用UDP很容易导致IP分片,在一个以太网上，数据帧的最大长度是1500字节，其中1472字节留给数据，其余28字节的填充为IP、UDP信息，所以发送的数据包最好不要大于这个值。
3.同第一点，把客户端接收缓冲区设置大一些 设置为几M，并尽量加快客户端处理，如单独开一个线程专门接收数据，处理使用另外的线程处理，使用固定长度队列，避免使用资源抢占（如加锁）
cnzdgs 2009-02-19
- 打赏
- 举报
1.采用TCP,那么发送端发送的数据包大小是不确定的,那么接收端如何来设置这个buff的大小,因为太小了,要多次调用recv才能接收完整.
buff的大小应该根据具体应用而定，例如你的程序中每接收1MB数据做一次处理，那就把buff定为1MB。无论buff大小，都需要根据recv的返回值来确定实际接收到多少数据，需要时调整buff指针再次接收。
2.采用UDP,如果这个buff的大小,会丢失数据.
buff应定为数据包的最大可能长度。
3.还有一个问题,如果采用UDP,而且有几十台机子会像这个UDP来发送数据,而且有可能是几乎同时发送,那么udp协议好像没有缓冲区(指协议中的底层那个缓冲区)来存储数据包,那么接收端是否会丢失数据,要怎么处理??
UDP丢包是很常见的，自己设计应答/重发机制。
buff的大小应该根据具体应用而定，例如你的程序中每接收1MB数据做一次处理，那就把buff定为1MB。无论buff大小，都需要根据recv的返回值来确定实际接收到多少数据，需要时调整buff指针再次接收。
2.采用UDP,如果这个buff的大小,会丢失数据.
buff应定为数据包的最大可能长度。
3.还有一个问题,如果采用UDP,而且有几十台机子会像这个UDP来发送数据,而且有可能是几乎同时发送,那么udp协议好像没有缓冲区(指协议中的底层那个缓冲区)来存储数据包,那么接收端是否会丢失数据,要怎么处理??
UDP丢包是很常见的，自己设计应答/重发机制。
