多人白板競賽條件

Question

想象一個多人白板，幾個人可以同時繪圖。 為簡單起見，假設白板上有一個 object，任何用戶都可以移動或刪除它。 沒有用戶擁有對象的概念（即任何用戶都可以操作任何 object 很重要......這是一個免費的白板）

我的問題是……如果兩個用戶同時嘗試對 object 執行不同的操作，即一個刪除它，另一個移動它，會發生什么？

現在 - 只是讓消息 go 通過，它就會完全失控。

一個想法是有一個服務器端控制來解決誰可以控制 object，並且在解決沖突之前不允許在客戶端發生任何事情。 沖突解決可以基於先到先得的原則。

盡管這可能發生得非常快，但小的延遲（~50-300ms）是不可接受的，因為移動必須在客戶端是瞬時的。 例如，與其操縱對象，不如想一支筆。 因為在他們已經開始畫畫之前會有延遲……不好！

另一個想法是有一個“請求控制”按鈕，它要求服務器端擴展進行控制....和以前一樣的想法，但現在他們不會因為筆畫的初始延遲而感到沮喪。 這也不是很好，因為他們必須按下那個按鈕直到他們可以做任何事情，而這個白板真的是為孩子們設計的......

還有其他解決方案嗎？ :)

Answer 1

這是一個有趣的問題，通常通過結合客戶端和服務器端分辨率來解決。 如果你熟悉《魔獸世界》，尤其是最初發布的日子，你會記得服務器崩潰，每個人都在繼續移動。 這是通過客戶端管理預測性運動並從服務器請求定期更新實際位置和行為值來完成的。

類似的想法應該適用於您的問題。 您在 f.c.fs 基礎上的服務器端分辨率似乎很理想。 您提到的問題是延遲降低了用戶體驗。 為了避免這種情況，為什么不給用戶完全的客戶端控制權，然后在操作后從服務器請求更新呢？ 因此，如果您將一個圓圈向下移動 200 像素，並且我將顏色更改為綠色，我們都可以看到即時客戶端行為，但是當您釋放圓圈時，您也會看到它變成綠色，正如服務器告知的那樣。

當兩個用戶更改 object 的相同屬性時，就會出現明顯的問題。 此時，f.c.fs 系統將需要根據客戶的使用情況做出決定。 它是否應該在 object 上執行凈增量？ 您是否應該通知用戶另一個用戶以不同的方式更改了 object？ 這更像是一個功能問題而不是技術問題。

Answer 2

真的很有趣的問題。 白板的 state 存儲在服務器上（例如在 DB 中）：客戶端上有 3 個可能的操作： startEditing 、 finishEditing 、 delete 。 在執行某些操作后，您應該向服務器發送一條消息來描述一個操作。

如果發送了startEditing ，首先你應該檢查你要編輯的 object 是否沒有鎖。 如果已解鎖，則應上鎖（鎖應包含有關上鎖用戶的信息）。 然后您應該向所有活動客戶端發送消息，告知不應編輯 object。

如果發送完成編輯（這應該包含有關對象更改的信息），您應該更改 DB 中的finishEditing釋放鎖並向所有活動客戶端發送消息，告知更改和釋放鎖。

如果發送delete 。 如果 object 未被與發送消息的客戶端不同的客戶端鎖定，則應從數據庫中刪除 object 並向所有活動客戶端發送消息，命令從白板上刪除該 object

Answer 3

您也許可以做一些事情來展示本地項目的交互以及其他人所看到的內容。 在開始時，您展示了類似的東西，您正在與之交互或書寫的透明 object 不是最終的，每個人都看到不透明的對象/繪圖是最終的，無論人們看到什么。

當您檢測到 2 個用戶同時移動一個項目時，在他們自己的屏幕上他們都是透明的，在某些多人游戲更新過程中，已確定擁有控制權的用戶仍在移動 object，您可以顯示某種用戶正在移動他們的 object 的事件（可能是通用的 poof），現在已確定不在他們的控制范圍內。

這樣，當您確定他們不是控制某個項目的人時，您會立即獲得繪圖響應和一些挫敗感。