2011年10月14日 星期五

動態切換負責廣播的 Local Connection 角色,避免受到 FPS 降低的影響

前年底,曾寫了這麼一篇文章:

多 Local Connection 彼此維護名單的機制

當時的想法是,在 "一個遊戲大廳" 負責廣播訊息給 "多個遊戲桌" 的系統中,嘗試做到每個遊戲桌都可以成為替代遊戲大廳負責廣播的角色,使得遊戲大廳不必要存在。

然而,實務上,遊戲大廳 通常不會只具有廣播、控管中心...的角色,有可能在視覺上仍提供其他功能給玩家,譬如遊戲列表、會員帳戶管理、其它服務...,所以沒有 "移除遊戲大廳" 的需要。

而,這兩天我正在思考一個新的 "策略",不再考慮沒有 遊戲大廳 的情況,但可以考慮 "主訊息廣播者" 這個角色是否可以被變更?!



源由:因 flash player 所在的 browser window 處於一種 "不可見" 的情況下時,如頁籤、或視窗縮小,都會導致 FPS 被降低,請參考以下網址:

http://www.kaourantin.net/2010/03/timing-it-right.html

http://help.adobe.com/zh_TW/as3/mobile/WS4bebcd66a74275c36cfb8137124318eebc6-8000.html

雖然文章中提及 <param name="hasPriority" value="true" /> 的解決方案,但我還沒測出效果~總之,這個 FPS 被降低的問題,會導致 "主訊息廣播者" 的效能降低!所以衍伸出的想法便是:是否可能動態決定最後一個還在畫面上的 flash player 負責做廣播者。

因此,大致上可能包含 (但不限於) 以下幾項系統需求:

* 第一個啟動的、第一個成為這個系統的一份子的、通常應屬遊戲大廳,可將之定義為 "main message dispatcher",此外它也負責維護 端點列表名單,稱為 "peer list maintainer"。

* 前者,第一個啟動的時機點,可以先成為第一個訊息廣播者 "message dispatcher"。

* 每個新開啟的 flash player 視窗,會嘗試尋找 "peer list maintainer" 並將自己的 local connection name 註冊進去,當 "peer list maintainer" 的名單有異動時,便會通知 "message dispatcher" 更新暫存名單。

* 當任一個 peer 向 "message dispatcher" 送訊息時,"message dispatcher" 會依照手邊的暫存名單做廣播。若找不到 "message dispatcher" 的話,便會通知 "main message dispatcher" (遊戲大廳),並由 "main message dispatcher" 成為新的 "message dispatcher"。

* 當任一個 flash player (不論是 遊戲大廳 或 遊戲桌) 收到 activate 事件成為被 focus 的視窗時,都可以向 "main message dispatcher" 告知自己想成為新的 "message dispatcher",這時 "main message dispatcher" 就會請原本的 "message dispatcher" (若找得到的話) 卸除責任。

* 傳送訊息失敗時,都要向 "peer list maintainer" 告之,再更新 "message dispatcher" 手邊的暫存名單。

* 重申目的:希望 "message dispatcher" 所在視窗能在可見畫面中,使 FPS 不被降低,使廣播效率不會受到影響。

以上是這個系統的共用核心概念,接下來要考量的是,如何使用這套核心,因為不同的專案應用 都可能多少必須要處理一些邏輯,維護一些資料,而這份商務邏輯是誰做?遊戲大廳做?當遊戲大廳的 FPS 被降低時?所以期望也由 "message dispatcher" 來做!所以在 "message dispatcher" 責任轉換時,就必須將 "資料" 傳給 "main message dispatcher" 再交給下一任的 "message dispatcher" 繼續維護。

何時要切換 "message dispatcher" 可能是個複雜的問題,切換的 "時機" 如果是 新視窗主動要求成為新 "message dispatcher",那麼可以向舊 "message dispatcher" 索取要維護的 "資料"。但若是發生在舊 "message dispatcher" 所在視窗被關閉時,就有可能發生舊 "message dispatcher" 來不急將 "資料" 送至 "main message dispatcher" 暫存的可能性,衍伸的解法可能是 "備份資料"。

這麼一套複雜的想法,引來的問題就是效能可能會更差,因為會增加 local connection 的溝通次數,以及嘗試找某個 local connection name 是否存在 (送資料失敗才發現不存在),效能可能會比原本背景執行的 local connection 廣播系統還差,那麼大概就沒有這麼設計的必要了~

想了兩天,還沒有開始寫雛型程式碼,若真有需要此架構,再來動手ㄅㄟ!

沒有留言: