游戲服務器TCP網絡套接字-公平性

Question

我正在為回合制游戲編寫游戲服務器。 一個標准是游戲必須對所有玩家盡可能公平。

到目前為止，它的工作方式如下：

• 每個客戶端都有一個TCP連接。 （如果相關，則通過WebSockets打開連接）
• 在運行時，通過epoll不斷檢查傳入的套接字消息。
• 使用准備好讀取的套接字遍歷客戶端：
  • 閱讀來自客戶端的所有消息。
  • 更新每個消息的內部游戲狀態。
  • 將傳出郵件排隊到受影響的客戶端。
• 在每個“窗口”（轉彎）的末尾：
  • 遍歷客戶端並將所有排隊的傳出消息寫入其套接字

我對公平的關注提出了以下問題：

我以什么順序向客戶發送消息有關系嗎？

• 對於我的程序，在所有套接字上調用write（）只需一秒鍾的時間，但是如果對客戶端列表進行排序，在底層操作系統或網絡中的某個地方會有所不同嗎？
  • 也許我應該先發送給延遲最高的客戶？

我如何將傳出消息寫入套接字有關系嗎？

• 目前，我將它們寫成一大塊。 大小可以超過單個數據包。
  • 如果我以小於1個數據包的小塊發送消息，客戶端開始處理的速度會更快嗎？
  • 一次向每個客戶端寫入一個價值為1的數據包並多次遍歷客戶端會更好嗎？

是否有任何Linux /網絡配置會在這里產生影響？

在此先感謝您的反饋和提示。

Answer 1

我以什么順序向客戶發送消息有關系嗎？

是的，以毫秒為單位。 如果網絡接口可用於發送，則操作系統將立即開始發送。 為什么要等待？

也許我應該先發送給延遲最高的客戶？

我認為您應該以隨機順序發送。 發送前先隨機播放列表。 這很公平。 我認為您的問題是有效的，應該解決。

目前，我將它們寫成一大塊。 [...]

首先，認識到TCP是基於流的，並且在協議級別上沒有包/消息。 在物理級別上，數據確實是打包的。

無需手動拆分數據包，因為無論如何，客戶端都會讀取數據。 如果客戶端發出讀取，則第一個數據包到達后，該讀取將立即完成。 操作系統中沒有人為的等待。

是否有任何Linux /網絡配置會在這里產生影響？

我不知道。 確保禁用打na。