C# 非阻塞套接字vs BeginXXX vs SocketAsyncEventArgs

有人能告诉我当前的.NET套接字技术吗

非阻塞套接字

如果我设置Socket.Blocking=false并使用异步操作，会发生什么

除了Socket.select（）之外，还有什么方法可以轮询多个非阻塞套接字，而不是逐个检查它们的可用性（比如琐碎的select（）或任何其他机制，可能与某些IOCP相关）

BeginXXX和SocketAsyncEventArgs

他们是在引擎盖下的阻塞插座上操作，只是隐藏线程创建

手动创建线程是否等同于使用BeginXXX方法

除了SocketAsyncEventArgs允许创建套接字池和与之相关的所有内容之外，使用SocketAsyncEventArgs还有其他优点吗

---

还有最后一个问题：如果应用程序是作为某种重载二进制代理工作的，并且大多数逻辑都是在单线程中完成的，那么什么提供了更好的可伸缩性：非阻塞方法还是异步操作？

1:

Socket.Select应该这样做，尽管我个人并不倾向于使用这种方法；特别是那些
IList
在高容量时变得烦人

2：不，换一种方式；阻塞操作基本上是在后台使用非阻塞，但带有门。不，它们不会在引擎盖下创建线程——除非在有东西入站时计算回调。我这里有一个例子，它使用
SocketAsyncEventArgs
为12k个连接提供服务-线程数大约为20。
SocketAsyncEventArgs
的目的之一是：


有效地进行池处理要容易得多，而无需在每次操作中创建/收集大量对象
您可以非常高效地处理“数据现在可用”场景，而无需回调（如果该方法返回false，则意味着您要立即处理数据-不会出现回调）

对于可伸缩性：async
我更关心Socket.Select（）的性能（处理列表的难度比处理异步代码要小）。BeginXXX在其他线程中调用回调（到目前为止我已经看到）。我猜SocketAsyncEventArgs只是提供了限制线程数爆炸的机制，所以您不会得到比实际预期更多的线程数，或者我错了吗？事实上，BeginXXX会在另一个线程上回调；我上一个要点实际上有助于减少这一点，允许您使用异步API，但如果数据现在可用，则可以做出适当的反应；对于其他一切：信号量；对我来说，SAEA的一个主要问题是它需要处理正确的recv/send任务顺序，这样就不会有两个异步操作挂起在一个套接字上。由于我的应用程序中的大多数逻辑都在单线程中运行（以避免锁定），因此我必须将异步操作的控制权返回给这个主线程thread@Aquilae然后，您将需要某种缓冲层，这样即使套接字已经存在，您也可以在某个地方放置数据sending@R1PFake我本来可以用更好的措辞；您不能有多个发送或多个接收；不过，您可以同时拥有其中一个