18,356
社区成员
发帖
与我相关
我的任务
分享完成端口投递接收消息WSARecv总会收到WSAENOBUFS
当发送和接收发送消息得比较频繁时很容易获得这个错误，当稍微慢一点，错误来得也晚一些，不知道是为什么
可以保证的是当获得这个错误的时候客户端根本就还没有发送消息
可以保证的是当获得这个错误的时候客户端根本就还没有发送消息
...全文
请发表友善的回复…
发表回复
leaber 2005-05-26
- 打赏
- 举报
其实是上面所说的只发送一个WSARECV OR WSASEND是不能解决这个问题的。
leaber 2005-05-26
- 打赏
- 举报
再申请一个重叠结构不就行了！
ZHENG017 2005-05-26
- 打赏
- 举报
sorry.那在wsasend之前最好先cancelio掉先前调用的wsarecv.
ZHENG017 2005-05-26
- 打赏
- 举报
解决办法三:对于同一个socket,最多只允许有一个wsarecv,当然这得仔细设计程序框架及流程.如果需要同时wsasend和wsarecv,那在wsasend之前最好先cancelio掉先前调用的wsasend.
「已注销」 2005-05-25
- 打赏
- 举报
记
flashboy 2005-05-21
- 打赏
- 举报
我最近翻译了一篇文档，里面就有这个解决方案 ：（翻译的不好，请多包涵）
一、 WSAENOBUFS 错误问题。
这个问题通常很难靠直觉发现，因为当你第一次看见的时候你或许认为是一个内存泄露错误。假定已经开发完成了你的完成端口服务器并且运行的一切良好，但是当你对其进行压力测试的时候突然发现服务器被中止而不处理任何请求了，如果你运气好的话你会很快发现是因为WSAENOBUFS 错误而影响了这一切。
每当我们重叠提交一个send或receive操作的时候，其中指定的发送或接收缓冲区就被锁定了。当内存缓冲区被锁定后，将不能从物理内存进行分页。操作系统有一个锁定最大数的限制，一旦超过这个锁定的限制，那么就会产生WSAENOBUFS 错误了。
如果一个服务器提交了非常多的重叠的receive在每一个连接上，那么限制会随着连接数的增长而变化。如果一个服务器能够预先估计可能会产生的最大并发连接数，服务器可以投递一个使用零缓冲区的receive在每一个连接上。因为当你提交操作没有缓冲区时，那么也不会存在内存被锁定了。使用这种办法后，当你的receive操作事件完成返回时，该socket底层缓冲区的数据会原封不动的还在其中而没有被读取到receive操作的缓冲区来。此时，服务器可以简单的调用非阻塞式的recv将存在socket缓冲区中的数据全部读出来，一直到recv返回 WSAEWOULDBLOCK 为止。
这种设计非常适合那些可以牺牲数据吞吐量而换取巨大并发连接数的服务器。当然，你也需要意识到如何让客户端的行为尽量避免对服务器造成影响。在上一个例子中，当一个零缓冲区的receive操作被返回后使用一个非阻塞的recv去读取socket缓冲区中的数据，如果服务器此时可预计到将会有爆发的数据流，那么可以考虑此时投递一个或者多个receive来取代非阻塞的recv来进行数据接收。（这比你使用1个缺省的8K缓冲区来接收要好的多。）
总结：
解决方法一：
投递使用空缓冲区的 recevie操作，当操作返回后，使用非阻塞的recv来进行真实数据的读取。因此在完成端口的每一个连接中需要使用一个循环的操作来不断的来提交空缓冲区的receive操作。
解决方法二：
在投递几个普通含有缓冲区的recevie操作后，进接着开始循环投递一个空缓冲区的recevie操作。这样保证它们按照投递顺序依次返回，这样我们就总能对被锁定的内存进行解锁。
一、 WSAENOBUFS 错误问题。
这个问题通常很难靠直觉发现，因为当你第一次看见的时候你或许认为是一个内存泄露错误。假定已经开发完成了你的完成端口服务器并且运行的一切良好，但是当你对其进行压力测试的时候突然发现服务器被中止而不处理任何请求了，如果你运气好的话你会很快发现是因为WSAENOBUFS 错误而影响了这一切。
每当我们重叠提交一个send或receive操作的时候，其中指定的发送或接收缓冲区就被锁定了。当内存缓冲区被锁定后，将不能从物理内存进行分页。操作系统有一个锁定最大数的限制，一旦超过这个锁定的限制，那么就会产生WSAENOBUFS 错误了。
如果一个服务器提交了非常多的重叠的receive在每一个连接上，那么限制会随着连接数的增长而变化。如果一个服务器能够预先估计可能会产生的最大并发连接数，服务器可以投递一个使用零缓冲区的receive在每一个连接上。因为当你提交操作没有缓冲区时，那么也不会存在内存被锁定了。使用这种办法后，当你的receive操作事件完成返回时，该socket底层缓冲区的数据会原封不动的还在其中而没有被读取到receive操作的缓冲区来。此时，服务器可以简单的调用非阻塞式的recv将存在socket缓冲区中的数据全部读出来，一直到recv返回 WSAEWOULDBLOCK 为止。
这种设计非常适合那些可以牺牲数据吞吐量而换取巨大并发连接数的服务器。当然，你也需要意识到如何让客户端的行为尽量避免对服务器造成影响。在上一个例子中，当一个零缓冲区的receive操作被返回后使用一个非阻塞的recv去读取socket缓冲区中的数据，如果服务器此时可预计到将会有爆发的数据流，那么可以考虑此时投递一个或者多个receive来取代非阻塞的recv来进行数据接收。（这比你使用1个缺省的8K缓冲区来接收要好的多。）
总结：
解决方法一：
投递使用空缓冲区的 recevie操作，当操作返回后，使用非阻塞的recv来进行真实数据的读取。因此在完成端口的每一个连接中需要使用一个循环的操作来不断的来提交空缓冲区的receive操作。
解决方法二：
在投递几个普通含有缓冲区的recevie操作后，进接着开始循环投递一个空缓冲区的recevie操作。这样保证它们按照投递顺序依次返回，这样我们就总能对被锁定的内存进行解锁。
scxy 2005-05-17
- 打赏
- 举报
如果出现这个错误的时候可否获得它到底需要多大的缓冲区
fisker0303 2005-05-17
- 打赏
- 举报
WSAENOBUFS ：无可用缓冲区空间。
Dynamic 2005-05-16
- 打赏
- 举报
从字面上来看是缓冲区不够, 设大点试试
jerry 2005-05-16
- 打赏
- 举报
投递消息 缓冲 没设置好?
scxy 2005-05-16
- 打赏
- 举报
在获得这个错误的时候，我们除了关闭连接外是否还有其他什么办法
或者是否可以避免出现这样的错误
或者是否可以避免出现这样的错误
