问题描述
挂起的异步操作都应该谨慎使用precious资源？
Are pending asynchronous operations are precious resource that should be used sparingly?
我有，我不是从预期的输入连接TcpClients的转换，但以防万一一个是行为不端，我需要保持输入缓冲器空。如果我有一个的BeginRead（）的，只是保持打开状态无限期每个连接的客户端，有什么危害？回调将被调用时，客户最终被关闭，我可以返回它，如果！asyncResult.IsCompleted。
I have a slew of connected TcpClients that I'm not expecting input from, but just in case one is misbehaving, I need to keep the input buffers empty. If I have a BeginRead() for each connected client that just stays open indefinitely, is there any harm? The callback will be called when the client is eventually closed and I can just return out of it if !asyncResult.IsCompleted.
我不知道有多少字节开始读，但我相信我可以分享一个缓冲区。输入至该缓冲区的限制可能只是坐在流中，未读。有没有更好的方式来有效地丢弃，不允许，或者在流等待数据的可用性？
I wouldn't know how many bytes to begin reading, though I believe I could share one buffer. Input up to that buffer limit could just sit in the stream, unread. Is there a better way to efficiently discard, disallow, or WAIT on the availability of data in a stream?
否则我需要轮询可用的数据。
Otherwise I need to poll for data available.
谢谢！
推荐答案
这取决于你的......正在运行的操作系统
It depends on the operating system that you're running on...
一个悬而未决的recv会使用一些非分页池，这将导致被锁定I / O的一些页面的内存。
A pending recv will use some non-paged pool and it will cause some pages of memory to be locked for I/O.
在Windows Vista之前，非分页池是pretty的恐慌，这是一个计算机范围的商品从而导致设计不当的驱动，如果它运行崩溃...所以在pre-Vista操作系统的你可能会得到ENOBUFS从底层重叠I / O系统由于缺乏非分页池错误。在这里看到： HTTP：// WWW。 lenholgate.com/blog/2009/03/excellent-article-on-non-paged-pool.html 对非分页池限制一些更多的细节。
Prior to windows Vista, non-paged pool was pretty scare, and it's a machine wide commodity which can cause poorly designed drivers to crash if it runs out... So on pre-Vista OS's you may get 'ENOBUFS' errors from the underlying overlapped I/O system due to lack of non-paged pool. See here: http://www.lenholgate.com/blog/2009/03/excellent-article-on-non-paged-pool.html for some more details on the non-paged pool limits.
这是用来给悬而未决的recv其他资源是内存中的一个或多个页面被锁定的I / O，而操作挂起。还有最重要的是可以锁定，因此，再一次，你可能会得到来自底层的I / O系统中的ENOBUFS在某些情况下页面的数量是有限的限制。
The other resource that is used by a pending recv is one or more pages of memory are locked for i/o whilst the operation is pending. There's a finite limit on the number of pages that CAN be locked and so, once again, you might get an 'ENOBUFS' from the underlying I/O system in certain circumstances.
当然，这取决于你有多少的连接必须为这些限制是否会影响你与否。
Of course it depends on how many connections you have as to whether these limits affect you or not.
处理锁定I / O页面的标准方式限制在非托管code是后零字节读取，即读取具有缓冲这实际上是0字节长。这意味着，没有缓冲空间被锁定，同时读取正在等待它完成时，你只需发布一个正常的读或读同步。
The 'standard' way of dealing with the locked I/O pages limit in unmanaged code is to post zero byte reads, that is reads which have buffers which are actually 0 bytes long. This means that no buffer space is locked whilst the read is pending and when it completes you simply post a normal read, or read synchronously.
这篇关于.NET异步套接字操作限制？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！