我在寫一個簡單的多人遊戲，使用WebSockets在客戶端和服務器之間發送信息。WebSocket：發送每個消息的用戶id
當我最初設計協議時，我決定每個消息頭都包含一個用戶標識（一個隨機生成的UUID）。如果連接斷開，客戶端將嘗試重新連接，服務器將能夠通過用戶標識識別客戶端。
我只使用無連接UDP協議通過網絡發送數據。我意識到WebSocket是建立在TCP之上的，這意味着套接字更像是一個數據流，而不是可能到達目的地的單個數據包。
我開始懷疑跟蹤郵件中的user-id。由於TCP本質上是基於連接的，我需要跟蹤用戶ID嗎？實際上跟蹤用戶標識是否有任何優勢？如果連接斷開，服務器和客戶端會自動重新連接？我沒有太多的實施這個遊戲。我應該一起放棄用戶id的想法嗎？
在每條消息中添加一個唯一的標識符看起來像是過度殺毒。只要他們保持連接，您的websocket服務器應該跟蹤您的連接。但是，如果客戶端斷開連接以保持連續性，您將需要用戶標識，因此我只會在用戶第一次連接時將用戶標識發送到客戶端一次。然後，如果客戶端必須重新連接，客戶端可以將其發回，並且您的遊戲可以從停止的地方恢復。
當然，使用會話提供商與您的websocket服務器將照顧這一點以及...
TCP連接是有狀態連接 - 數據包從源發送到目的地，並且源從目的地接收到確認包（雙向 - 任一方可能是源或目的地） - 這是由網絡堆棧，並且對你而言不可見。
但是，重新連接並不是自動的，它會在您的部分（很可能在客戶端）進行干預以重新連接。
如果僅通過IP &端口跟蹤客戶端，那麼可能不需要用戶標識，然而，大多數人通過一些不同的NAT系統鏈來使用互聯網，其中一個IP可見的IP隱藏多個未知數的用戶和網絡。 在這些情況下，我認爲繼續通過您生成的特定ID而不是IP &端口識別您的客戶端確實有意義。 IP和端口本身並不保證是唯一的，因爲該連接可能會被丟棄，然後另一個用戶可能會聲明相同的未使用的源端口。
所有這些也是我的理論猜測 - 我對你的建議是開始迭代設計，看看有什麼作用。 :)在開始之前，沒有必要嘗試設計和預測完美的一切。
感謝您的答覆。你能否詳細說明會話狀態提供者是什麼？快速谷歌表明，這是一個.NET的事情，這是Linux服務器的問題。 – Moyamo
會話絕對不限於.NET。你使用什麼樣的websocket服務器？許多內置此功能。 – mattexx
我正在使用龍捲風Web框架。再次感謝你的幫助。我一定會對這件事做更多的研究。雖然，我認爲如何使用會話提供者不在這個問題的範圍之內，並且可能不應該在SO評論主題中回答。我會將答案標記爲已接受。 – Moyamo