我正在使用服务器和一些客户端（不超过60个）在C＃中进行应用程序，我希望能够独立处理每个客户端。服务器和客户端之间的通信很简单，但我必须等待一些确认，我不想阻止任何查询。
到目前为止，我已经完成了服务器端的两个版本，其中一个基于此：
http://aviadezra.blogspot.com.es/2008/07/code-sample-net-sockets-multiple.html
在另一个中，我基本上为每个客户端创建一个新线程。两个版本都运行良好......但我想知道这两种方法的优缺点。
在这种情况下要遵循的任何编程模式？
答案 0 :(得分：1)
回答你的问题。您在这些线程中运行了线程和类。无论您使用WCF，异步，套接字还是其他任何东西，您都将在一个线程中运行一些对象（或者像使用异步一样在线程池中运行）。使用WCF，你可以c onfigure the concurrency model，如果你必须等待ack或其他确认，你最好将它设置为多个线程，这样你就不会阻止其他请求。
在链接到作者的示例中，使用AsyncCallback作为告诉您套接字有数据的机制。但是，从MSDN你可以看到：
使用AsyncCallback委托在单独的线程中处理异步操作的结果
所以对于小规模的应用程序来说真的没有什么不同。像这样使用async可以帮助您避免为每个线程分配堆栈空间，如果您要执行大型应用程序，则这很重要。但对于一个小应用程序，我认为它只会增加复杂性。 C＃4.5+和F＃使用异步做一个更干净的工作，所以如果你可以使用类似的东西，那么也许可以去做。
按照您的方式进行操作，您有一个负责套接字管理的线程。它会坐下来接受新的联系。当它收到请求时，它将该套接字交给新的专用线程，然后该线程将坐在该套接字上并从中读取。此线程是您的客户端连接。我喜欢将套接字客户端读取封装到可以执行所需的低级别的基类中，然后充当请求的路由器。即当我收到请求XYZ时，我会请求ABC。您甚至可以让它调度事件并在其他地方订阅这些事件（例如在异步示例中）。现在，您已将客户端逻辑与套接字读取逻辑分离。
如果您使用WCF执行操作，则不需要套接字和所有额外处理，但您仍应注意调用是多线程的，并在适用时正确同步应用程序。
对于60位客户，我认为您应该选择最适合您的方式。 WCF易于设置和易于使用，我会使用它，但套接字也很好。如果您担心运行的线程数，请不要这样做。虽然运行太多线程很糟糕，但是大多数线程在等待IO时实际上会被阻塞。处于等待状态的线程不是由OS调度的，并不重要。更不用说等待很可能是在引擎盖下使用io完成端口，因此像你这样的小应用程序的等待开销几乎可以忽略不计。
最后，我会选择最容易编写，维护和扩展的内容。