多人UDP網絡策略，需要建議

Question

我正在嘗試爲實時3D遊戲創建一個C++插件。雖然我相信對UDP理論有一個牢固的把握，它是如何工作的，它的優點和缺點是什麼，我關心的主要問題是性能，可伸縮性和可能的​​統計數據。我知道，我只知道在涉及UDP甚至TCP的情況下，海洋價值的下降。

問題：

給定一個某些情況下，很多球員會怎麼一個典型的專用服務器（一個或多個）能夠在任何一個時間來應對。

現在的情形...

讓我們想象一下，我們有一個MMORPG遊戲，所有玩家都可以在「遊戲世界」的任何地方。每個人都可以向同一個服務器/服務器中心發送和接收數據，因爲每個人都必須能夠......看到每個人，並在其路徑最終跨越時與其互動。這是一款真正的第一人稱遊戲，所以玩家的位置必須非常及時。

比方說我們有1000個（甚至10000）在線玩家...

三個主要的事情需要在這裏發生：

1. 每個玩家通過UDP的數據流發送到遊戲服務器，比如說每秒發送14次。簡而言之，這些數據包括誰，誰在哪裏以及每個玩家是什麼。正在發送的數據已經規格化並針對大小和速度進行了優化，以鼓勵最小的帶寬使用。

2. 服務器例如每秒接收14次這些數據包，因此每秒鐘處理14 000個數據包，例如達到1000個（用於示範目的的非虛構數字）。該處理階段通常涉及更新中央存儲器數據結構，其中玩家舊的x，y，z位置數據將用他的新位置和時間戳更新。服務器上的這個數據結構包含整個遊戲世界中所有玩家的所有數據。

3. 服務器（可能是一個單獨的線程，甚至可能是一臺獨立的機器）現在需要將數據包廣播給所有其他玩家，以便他們可以更新屏幕以顯示地圖上的其他玩家。這也是每秒發生14次。 （其中14個可能通常是一個動態數字，根據所使用的CPU容量而變化，繁忙的CPU，較低的幀率，反之亦然）。

重要的是：對於玩家X，只有他職位視覺範圍內的其他玩家的數據被分派給相應的玩家。因此，如果玩家Y距離2英里，他的數據需要發送給X，但是如果玩家Z位於地球的另一側，他的數據不會被分派到X以節省帶寬。這當然涉及更多的處理，因爲數據必須使用最有效的索引解決方案進行迭代和過濾。

現在我擔心的是，從客戶端發送數據包到服務器RAM中，稍微處理更新數據並選擇性地向其他播放器播放信息需要時間。這意味着服務器將能夠處理的某個閾值，是的，取決於我的實現的有效性，所使用硬件的速度和能力，當然還有其他外部因素，例如網速，交通和nr。太陽耀斑每秒擊中地球......只是在開玩笑。

我正試圖從別人身上找出來，他們已經經歷了這個過程，陷阱是什麼，以及創建多人插件時可以期待的典型性能。

我可以很容易地說：「我想要滿足10000人同時在同一臺服務器上玩遊戲」，你可能會說：「每臺服務器上100個是更現實可能的數字。」

所以我知道我可能不得不想出一個多服務器/雲計算中心來處理我的數千個請求和調度，將處理負載分配到多臺機器上。所以我可能有幾臺機器只處理接收數據，一個巨大的中央盒子，就像所有接收和發送機器共享內存數據庫，然後是一系列調度機器。

顯然，有技術限制，我真的不知道會發生什麼，以及它們是什麼。並且在問題中拋出額外的CPU和服務器箱將不會永久解決問題，因爲機器之間的更多的互相通信也會降低該過程的速度。我猜想你投入的CPU越多，可能會降低效率，甚至會在某個閾值下逆轉CPU生產力。

可以，我應該考慮P2P（點對點）多人遊戲！

我是否現實地說，我可以在任何時候爲2500名玩家提供服務？

在幾年的時間內可以擴展到10000個玩家嗎？

我知道這個問題太可怕了，所以請接受我真誠的道歉。

Answer 1

• 能不能也應該考慮P2P（點對點）多人遊戲？我不認爲p2p技術能夠處理遊戲網絡的實時問題。此外，在通常的P2P網絡中，您並沒有同時連接數千個成員，但通常連接到一些上游節點，因此它比一棵平坦的樹更像一個圖。

• 我是否現實地說，我將能夠在任何時候迎合2500名玩家？不在一臺服務器上。然而，通過將用戶分佈到多個服務器上，如果它是一個非常龐大的世界，您可以按遊戲世界中的地理區域（例如，通過大陸或國家）對其進行過濾。對於低延遲，您無論如何都希望將服務器保持在用戶的真實位置附近 - 如果您居住在美國，則不會在歐洲服務器上播放，反之亦然。

• 在幾年的時間裏能夠擴展到10000個玩家嗎？有很多方法可以優化數據的編碼和傳輸方式。只發送遊戲世界狀態的變化，玩家移動的客戶端預測，網絡層面的廣播，服務器端的雲計算等，未來幾年將會更多，當遊戲行業接觸OnLive等基於雲的計算平臺時，我們需要更高效的算法和基礎設施來應對這些數量，這變得顯而易見。

Answer 2

縮放問題完全合法。然而，對UDP的關注卻是錯位的。這不會是你的主要問題。

原因是玩家與玩家之間的互動基本上是O（N * N）問題。另一方面，服務器帶寬是O（N）問題。考慮到現代的網絡服務器可以通過TCP over HTTP來攻擊1Gbit以太網，所以UDP的開銷較低意味着只要計算能夠保持，你就可以使用UDP來飽和1 Gbit以太網。

Answer 3

P2P的問題最終是最終用戶的連接。 ISP通常不會給你很多上傳，在很多情況下你的下載速度是其中的1/10。很多用戶都在NAT後面，因此您需要爲客戶端設置某種形式的代理來啓動連接。您將需要處理用戶斷開連接和數據包丟失（對於癱瘓的無線網絡中丟棄一半數據包的不可避免的節點）。而且你需要一種很好的方式來按ISP/Location對客戶進行分組，這樣他們之間就不會有200ms + ping。

IMO聽起來像是一場等待發生的災難。你可能最好使用一個衆所周知的網絡庫（和傳統的客戶/服務器架構），然後試圖發明一個方形的車輪。只傳送需要更新的內容（注意大多數MMO包含動態對象很少的大靜態世界）。

Answer 4

擴展問題是MMO最困難的挑戰之一，也是部分解決的問題之一。有很多關於如何跟蹤和更新用戶信息的例子。

但我要提到的一點是，歷史上，遊戲是一種社會事物，因此大多數人傾向於在中心或單一區域聚集在一起。所以你真的必須設計這種最壞的情況。

一些遊戲真的是一個巨大的史詩般的感覺，並允許所有用戶分組和聚集在一起是一個核心設計要求。對於這種類型的遊戲，計劃所有用戶在完全相同的位置。對於其他遊戲，你應該能夠將它們分成更小的團體並分而治之。

Answer 5

是否可以並且應該考慮P2P（點對點）用於多人遊戲 - 不，這會讓您最多隻能作弊和各種可靠性問題。這是一個最好的未開封的蠕蟲罐。但是，如果這是您所關心的問題，它可能會幫助您解決內容分發問題。

我是否現實地說，我可以在任何時候爲2500名玩家提供服務？ - 當然，但重點在於你如何實現它。在90年代中期，像絕望領域或Medievia這樣的文本遊戲同時在線處理數百個玩家。他們並沒有每秒向每個人發送14次數據，但他們每秒更新數次。自那時以來，計算能力增加了約250倍。食物的思想。

在幾年的時間裏能夠擴展到10000個玩家嗎？ - 現在可以這樣做，如果你放寬你的帶寬需求，這樣你就不會總是每秒發送14次更新，或放寬每個人都由1臺服務器處理的要求。 'C10K問題'被編址爲over 10 years ago。顯然，FTP客戶端不是實時遊戲，但另一方面，其吞吐量要求更高。如果您可以容忍一些額外的延遲以換取更高的帶寬，那麼您將成爲贏家。