2011 年的 GDC 年會中, BUNGiE.net 分享了他們在進行 Halo 的遊戲開發時針對一些即時性的網路傳輸議題的處理經驗. 介紹到他們的網路架構時, 較讓我驚訝的是他們採用完全 UDP 的實現. 微軟的 Halo 技術服務頁面也應驗了這一點. 稍一查訪之後發現全 UDP 實作的網路傳輸在遊戲領域中還不算少見, 另一個專門用於遊戲開發的 Raknet 網路函式庫也是採用 UDP 實作 (另提供 TCP wrapper). 在 BUNGiE 分享的投影片內容中, 有提到他們的架構很大程度是延用 1995 年 Tribes 開發團隊同樣是在 GDC 中分享的 "Tribes Networking Model" 中提到的架構. 這篇論文目前還可在網路上找到 (PDF).
相對於 TCP 提供的可靠且保證有序的封包傳輸, UDP 提供的是不可靠 (不保證封包會送達) 而且也不保證有序 (後發可能先至) 的資料傳輸. 也是基於這個差異, TCP 的運行代價相對比 UDP 來得高, 也就是說若以同一台機器來實驗, 全以 UDP 為底的最大網路傳輸承載量必然比 TCP 大得多. 取捨點在於上層應用是否能容忍封包丟失或失序的現象發生.
由 Tribes 的實作論文來看, 他們把遊戲中的資料封包都加上了是否有保障 (guaranteed) 的屬性. 無保障 (non-guaranteed) 的資料封包就當一般 UDP 封包發出去, 有保障 (guaranteed) 的封包必要時會重傳以確保對方確實有收到. Tribes 的 UDP 網路實作中會額外用類似 TCP 協定中使用的 transmit sliding window 來做監控, 用以確保得知每個封包的傳送狀態. 另外, Tribes 實作中, 雙方的資料傳輸並不是按需求 (on-demand) 馬上發生的, 而是雙方保持著一個定時定量的資料傳輸. 可以想像成一班定時發車的列車, 每班列車上可裝載的資料量有限, 所有會產生資料傳輸的人按優先權往裡面加資料, 若裝滿了後面後面加上來的資料就直接被丟棄了. 上層可視情況等下班列車還是直接放棄這個封包的傳輸. 這種定時定量的資料傳輸也跟一般的 on-demand 傳輸有根本上的差異 -- 引入了優先權的發揮時機. 一般基於 TCP 的資料傳輸每個封包都是一樣重要的, 一旦交付進 TCP Stack 之後就被一視同仁地保障.
由以上可推估 Tribes 的網路層在 UDP 以上、直至封包交付層以下的這中間一大塊範圍內重新實作了類 TCP 的種種機制來達到整體資料傳輸的完好性. 原本這部分的資料就只有這篇論文的簡要描述, 背後的 knowhow 只有被 Halo, Raknet (某個版本之前有 open source, 後來又 close source) 等等真的付諸實現的 player 所把持.
今年 9/20, Torque 遊戲引擎宣佈轉為 MIT 授權的開源計畫. 由 Wiki 上可得知其開發公司 GarageGames 大部分的開發成員都是由原本開發 Tribes 的 Dynamix 公司轉過來的. 從 github 上面把 Torque 的程式碼載下來看, 發現真的有一個非常類似於論文中所提的純 UDP 網路傳輸層實現可以參考 (位置 Engine/source/sim 底下). 此後若要實作這類傳輸層, 大可不必重零開始, 現成有一個已經經過驗證的參考實作可以轉化運用. (雖說現今網路環境或設備都已經很發達, 大型的網路遊戲也多半是單純 TCP 的實作....)
沒有留言:
張貼留言