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