c# - .Net Socket Service::通过事件传递套接字请求对于大规模服务来说是一个愚蠢的想法吗？

Question

大多数人似乎构建了一个监听器套接字，并将包含要调用以进行处理的“事件”。 EG:SocketConnected，DataReceived。程序员初始化一个监听器并绑定(bind)到“事件”方法以接收套接字事件以构建服务。

我觉得在大规模实现中，避免在监听器中使用委托(delegate)会更有效。并在回调方法中完成所有处理。可能基于知道接下来会出现什么命令的知识，使用不同的回调来接收数据。 (这是我的消息框架结构的一部分)

我四处寻找高度可扩展的示例，但我只找到了用于异步套接字的标准 MSDN 实现或其他程序员复制 MSDN 示例的变体。

有没有人有任何好的经验可以为我指明正确的方向？

注意> 该服务将拥有数千个客户端，并且在大多数情况下，客户端保持连接并且服务接收到的更新将发送给所有其他连接的客户端。它是面向对象数据库的同步 P2P 类型系统。

Answer 1

事件调用和回调之间的区别可以忽略不计。回调只是委托(delegate)(或函数指针)的调用。你不能在没有某种回调的情况下进行异步操作，并期望得到任何类型的结果。

对于事件，它们可以被多播。这意味着多次回调调用——所以这会更昂贵，因为你调用了多个方法。但是，如果您这样做，您可能需要这样做——另一种方法是拥有多个代表并手动调用它们。所以，不会有真正的好处。事件通常可以包括 sender/eventargs；所以，你得到了那个额外的对象和 eventargs 实例的创建；但我从未见过影响性能的情况。

就个人而言，我不使用基于事件的异步模式——我发现(在 .NET 4.5 之前)异步编程模型更加普遍。在 .NET 4.5 中，我更喜欢任务异步模式(以 Async 结尾的单个方法，而不是两种方法，一种以 Begin 开头，一种以 End 开头)，因为它们可以与 async/await 一起使用，而且不那么冗长。

现在，如果问题是 new AsyncCallback(Async_Send_Receive.Read_Callback) 之间的区别例如。:

s.BeginReceive(so.buffer, 0, StateObject.BUFFER_SIZE, 0, 
                                     new AsyncCallback(Async_Send_Receive.Read_Callback), so);

只是 Async_Send_Receive.Read_Callback例如。:

s.BeginReceive(so.buffer, 0, StateObject.BUFFER_SIZE, 0, 
                                     Async_Send_Receive.Read_Callback, so);

第二个只是第一个的简写； AsyncCallback委托(delegate)仍然在幕后创建。

但是，与大多数事情一样；即使普遍认为在性能、测试和测量方面没有明显差异。如果一种方式比另一种方式有更多好处(包括性能)，请使用该方式。