對於在C＃中同時播放多達32個播放器的專用服務器，Asyncronous TCP網絡是否會更好？

Question

目前我計划在C＃中為XNA游戲設計一個專用服務器，最多可以同時連接32個玩家。 我有與System.Net建立聯系的經驗，但我以前不必處理相當多的玩家數量。

我從心里知道創建和銷毀線程（特別是每個玩家一個）並不是一個好主意，我不確定是否使用ThreadPool，因為“沒有線程可用時排隊等待”性質。 所以，我已經決定（幾乎是我唯一的最后選擇）使用Async來處理大客戶端數量。

但我仍然不確定這是否是明智的選擇，或者我是否應該使用其他東西來滿足我的苛刻需求。

抱歉，如果這個問題聽起來很黯淡，但我很難過 - 非常感謝！

Answer 1

如果游戲的限制確實是32個並發用戶，也許是少數幾個觀察者，那么線程就沒問題，特別是如果你發現它們比回調更容易編碼。 （您必須適當地協調對共享數據結構的訪問 ，並且其復雜性可能超過相應的基於事件的設計。）

我可能甚至不會為32個並發用戶而煩惱一個線程池。

線程對吞吐量的限制顯示大約100個線程（當然，取決於實現細節）。 如果您從未瞄准100個並發用戶（例如，這將是一個非常輕載的IRC服務器），那么除非您和您的團隊對事件模型更加放松，否則不需要異步事件模型。

Answer 2

當服務器受I / O限制時，異步方法很強。 等待I / O時將需要更少的資源。

當服務器受CPU限制時，線程方法很強。 它可以輕松擴展到多個內核或CPU。

有32個用戶，我會謹慎地建議去線程，至少在異步支持准備好在.NET中的黃金時間之前。 只需使用.NET中包含的線程安全結構進行所有線程間通信，不要編寫自己的代碼，你應該沒問題。 如果您決定編寫自己的代碼，經驗告訴我您可能會更糟糕，因為即使是最輕微的錯誤也可能導致非常難以追蹤的隨機錯誤。

Answer 3

什么適合你取決於你正在計划的負荷。 最高性能的解決方案通常被認為是異步處理器的線程池，但這很容易造成嚴重的過度殺傷。 選擇可以完成工作的最簡單的解決方案。