1

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

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

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

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

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

4

3 回答 3

1

我给你的唯一建议是：选择最清晰的风格。

由于无法测量的速度差异而消除整个语言功能还为时过早。方法调用/委托调用的成本极不可能成为代码中的瓶颈。当然，您可以对一个与另一个的相对成本进行基准测试，但如果您的程序仅花费 1% 的设置方法调用，那么即使是巨大的差异也不会真正影响您的程序。

如果你真的想给你的服务器加汁，我给你的最好建议是确保你所有的 IO 都是异步发生的，并且永远不要在线程池中运行长时间运行的任务。.net4.5 async/await 确实简化了所有这些...考虑将其用于更易于维护的代码。

于 2012-08-17T02:18:43.413 回答
1

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

对于事件，它们可以被多播。这意味着多次回调调用——所以这会更昂贵，因为你调用了多个方法。但是，如果您正在这样做，您可能需要这样做——另一种方法是拥有多个代表并手动调用它们。所以，不会有真正的好处。事件通常可以包括 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委托仍然是在幕后创建的。

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

于 2012-08-17T03:13:23.980 回答
0

我使用过使用套接字和两种方式的主动消息传递的实时投注系统。使用框架来处理像 WCF P2P 这样的套接字层确实更容易。它为您处理所有连接问题，您可以专注于您的业务逻辑。

于 2012-08-17T02:38:04.963 回答