比如有一個玩家A向服務器發了條指令，說我現在在P1點，要去P2點。指令發出的時間是T0，服務器收到指令的時間是T1，然后向周圍的玩家廣播這條消息，消息的內容是“玩家A從P1到P2”有一個在A附近的玩家B，收到服務器的這則廣播的消息的時間是T2，然后開始在客戶端上畫圖，A從P1到P2點。這個時候就存在一個不同步的問題，玩家A和玩家B的屏幕上顯示的畫面相差了T2-T1的時間。這個時候怎么辦呢？

　　有個解決方案，我給它取名叫 預測拉扯，雖然有些怪異了點，不過基本上大家也能從字面上來理解它的意思。要解決這個問題，首先要定義一個值叫：預測誤差。然后需要在服務器端每個玩家連接的類里面加一項屬性，叫TimeModified，然后在玩家登陸的時候，對客戶端的時間和服務器的時間進行比較，得出來的差值保存在TimeModified里面。還是上面的那個例子，服務器廣播消息的時候，就根據要廣播對象的TimeModified，計算出一個客戶端的CurrentTime，然后在消息頭里面包含這個CurrentTime，然后再進行廣播。并且同時在玩家A的客戶端本地建立一個隊列，保存該條消息，只到獲得服務器驗證就從未被驗證的消息隊列里面將該消息刪除，如果驗證失敗，則會被拉扯回P1點。然后當玩家B收到了服務器發過來的消息“玩家A從P1到P2”這個時候就檢查消息里面服務器發出的時間和本地時間做比較，如果大于定義的預測誤差，就算出在T2這個時間，玩家A的屏幕上走到的地點P3，然后把玩家B屏幕上的玩家A直接拉扯到P3，再繼續走下去，這樣就能保證同步。更進一步，為了保證客戶端運行起來更加smooth，我并不推薦直接把玩家拉扯過去，而是算出P3偏后的一點P4，然后用(P4-P1)/T(P4-P3)來算出一個很快的速度S，然后讓玩家A用速度S快速移動到P4，這樣的處理方法是比較合理的，這種解決方案的原形在國際上被稱為（Full plesiochronous），當然，該原形被我篡改了很多來適應網絡游戲的同步，所以而變成所謂的：預測拉扯。

　　另外一個解決方案，我給它取名叫 驗證同步，聽名字也知道，大體的意思就是每條指令在經過服務器驗證通過了以后再執行動作。具體的思路如下：首先也需要在每個玩家連接類型里面定義一個TimeModified，然后在客戶端響應玩家鼠標行走的同時，客戶端并不會先行走動，而是發一條走路的指令給服務器，然后等待服務器的驗證。服務器接受到這條消息以后，進行邏輯層的驗證，然后計算出需要廣播的范圍，包括玩家A在內，根據各個客戶端不同的TimeModified生成不同的消息頭，開始廣播，這個時候這個玩家的走路信息就是完全同步的了。這個方法的優點是能保證各個客戶端之間絕對的同步，缺點是當網絡延遲比較大的時候，玩家的客戶端的行為會變得比較不流暢，給玩家帶來很不爽的感覺。該種解決方案的原形在國際上被稱為（Hierarchical master-slave synchronization），80年代以后被廣泛應用于網絡的各個領域。

　　最后一種解決方案是一種理想化的解決方案，在國際上被稱為Mutual synchronization，是一種對未來網絡的前景的良好預測出來的解決方案。這里之所以要提這個方案，并不是說我們已經完全的實現了這種方案，而只是在網絡游戲領域的某些方面應用到這種方案的某些思想。我對該種方案取名為：半服務器同步。大體的設計思路如下：

　　首先客戶端需要在登陸世界的時候建立很多張廣播列表，這些列表在客戶端后臺和服務器要進行不及時同步，之所以要建立多張列表，是因為要廣播的類型是不止一種的，比如說有local message,有remote message,還有global message 等等，這些列表都需要在客戶端登陸的時候根據服務器發過來的消息建立好。在建立列表的同時，還需要獲得每個列表中廣播對象的TimeModified，并且要維護一張完整的用戶狀態列表在后臺，也是不及時的和服務器進行同步，根據本地的用戶狀態表，可以做到一部分決策由客戶端自己來決定，當客戶端發送這部分決策的時候，則直接將最終決策發送到各個廣播列表里面的客戶端，并對其時間進行校對，保證每個客戶端在收到的消息的時間是和根據本地時間進行校對過的。那么再采用預測拉扯中提到過的計算提前量，提高速度行走過去的方法，將會使同步變得非常的smooth。該方案的優點是不通過服務器，客戶端自己之間進行同步，大大的降低了由于網絡延遲而帶來的誤差，并且由于大部分決策都可以由客戶端來做，也大大的降低了服務器的資源。由此帶來的弊端就是由于消息和決策權都放在客戶端本地，所以給外掛提供了很大的可乘之機。

　　綜合以上三種關于網絡同步派系的優缺點，綜合出一套關于網絡游戲傳輸同步的較完整的解決方案，我稱它為綜合同步法（colligate synchronization）。大體設計思路如下：

　　首先將服務器需要同步的所有消息從劃分一個優先等級，然后按照3/4的比例劃分出重要消息和非重要消息，對于非重要消息，把決策權放在客戶端，在客戶端邏輯上建立相關的決策機構和各種消息緩存區，以及相關的消息緩存區管理機構.

　　對于非重要消息，客戶端的大體處理流程，其中有一個客戶端被動行為值得大家注意，其中包括對服務器發過來的某些驗證代碼做返回，來確保消息緩存中的消息和服務器端是一致的，從而有效的防止外掛來篡改本地消息緩存。其中的消息來源是包括本地的客戶端響應玩家的消息以及遠程服務器傳遞過來的消息。

　　對于重要消息，比如說戰斗或者是某些牽扯到玩家一些比較敏感數據的操作，則采用另外一套方案，該方案首先需要在服務器和客戶端之間建立一套Ping System，然后服務器保存和用戶的及時的ping值，當ping比較小的時候，響應玩家消息的同時先不進行動作，而是先把該消息反饋給服務器，并且阻塞，服務器收到該消息，進行邏輯驗證之后向所有該詳細廣播的有效對象進行廣播（包括消息發起者），然后客戶端收到該消息的驗證，才開始執行動作。而當ping比較大的時候，客戶端響應玩家消息的同時立刻進行動作，并且同時把該消息反饋給服務器，值得注意的是這個時候還需要在本地建立一個無驗證消息的隊列，把該消息入隊，執行動作的同時等待服務器的驗證，還需要保存當前狀態。服務器收到客戶端的請求后，進行邏輯驗證，并把消息反饋到各個客戶端，帶上各個客戶端校對過的本地時間。如果驗證通過不過，則通知消息發起者，該消息驗證失敗，然后客戶端自動把已經在進行中的動作取消，恢復原來狀態。如果驗證通過，則廣播到的各個客戶端根據從服務器獲得校對時間進行對其進行拉扯，保證在該行為完成之前完成同步。

　　至此，一個比較成熟的網絡游戲的同步機制已經初步建立起來了，接下來的邏輯代碼就根據各自不同的游戲風格以及側重點來寫了。

　　同步是網絡游戲最重要的問題，如何同步也牽扯到各個方面的問題，比如說游戲的規模，游戲的類型以及各種各樣的方面，對于規模比較大的游戲，在同步方面可以下很多的工夫，把消息分得十分的細膩，對于不同的消息采用不同的同步機制，而對于規模比較小的游戲，則可以采用大體上一樣的同步機制，究竟怎么樣同步，沒有個定式，是需要根據自己的不同情況來做出不同的同步決策的