-
數據廣播
(廣播通道)
鎖定
- 中文名
- 數據廣播
- 外文名
- Data broadcasting
數據廣播定義
定義數據廣播是把數據化的音頻、視頻、圖像、動畫、軟件包括以及計算機文件等各種數據信息通過數字電視廣播信道以"推送"(push)的方式傳輸的用户的數字電視機頂盒、數字電視接收機、個人電腦(pc)以及移動設備等智能設備的一類新型業務。
數據廣播簡介
數據廣播的技術實現方式是使用單一的系統前端(Headend),連續、滾動地將已編輯整理好的內容,經過信息傳輸網絡,傳送到地域廣泛的、能夠處理這些56 ST數據的用户智能設備上去,如:PC、機頂以及手提設備等。信息內容則是由視頻、音頻、軟件程序、流式數據或者其他數字多媒體組成的。
數據廣播實質上就是傳統廣播媒體一報紙、電台、電視在數字時代的一次升級,保持了廣播高速和經濟(受眾面廣)的特點,而且全無互聯網缺乏CoS(服務等級)、QoS(服務質量)和安全的問題,成為一種高效率的數字信息傳輸手段。
業界對該技術的前景有一種預言:數據廣播將會被嵌入和包容進未來的互聯網中,並且成為其最大的單一領域。可以確信直到那時,數字媒體才擁有點對點和點對多點兩種方式,才具有真正意義上的完整性。正如互聯網的出現充實了信息傳輸方式一樣。數據廣播的發展也會是信息傳輸技術的另一場革新。
數據廣播適應了數字裝置不斷擴張的處理能力和Internet提供的基礎設施資源,並可以與電視等多種媒體融合,這些跨媒體的立體信息傳輸業務非常適應於企業信息化的需求。在企業信息化建設中會得到更廣泛的應用。
數據廣播衞星
高速衞星數據廣播:
高速數據廣播系統技術已趨於成熟,衞星數據廣播可提供2M~45Mb/s的速率。網絡的可管理性、大容量的數據備份系統(可為用户提供1G~40G的存儲備份)和異地備份吸引了世界上許多大公司在世界範圍內開始實驗網的建設。具有142個成員國的世界上最大的商業衞星組織Intelsat,於1999年4月初開始衞星互聯網多播試驗,試驗通過Intelsat 603衞星不斷地把最新的Internet內容進行緩存,然後通過衞星把它廣播到世界各地相應的ISP衞星接收器中。這意味着ISP可以利用衞星連接得到非常高的帶寬,花費較小的費用,快速地瀏覽國際網站,而且傳輸成本低,每Bit傳輸費用比固定線路少30%。
衞星數據廣播以衞星通信為載體,包容了衞星通信的基本特點。
1 通信距離遠,覆蓋範圍廣
2 無地理條件限制
對於沙漠、高原、高山、海島等鋪設地面線路困難且成本較高的地區,通過衞星方式可便捷地實現數據業務傳輸。
3 快速服務
與鋪設光纜等地面通信線路所耗費的時間相比,衞星數據業務方式能夠在極短的時間內完成相關工程與調試,為用户提供服務。
4 費用與通信距離無關
與地面通信線路相區別,衞星數據業務的服務費用與傳輸距離無關,因此對於較偏遠地區及地面線路效果差的地區,採用衞星數據業務方式可以節省通信費用。
VBI數據廣播:利用電視逆程,通過衞星、微波或有線電視進入千家萬户,最大傳輸速度約180Kbps,目前已在證券行情信息傳輸、公眾多媒體信息傳輸等方面獲得廣泛應用。
DVB數據廣播:按傳輸介質不同,分為DVB-S、DVB-C、DVB-T,分別通過衞星、有線電視或地面廣播進入千家萬户,傳輸速度為56~90Mbps,主要用於數字視音頻廣播、寬帶數據廣播 、現代遠程教育等領域。
DAMB數據廣播:通過L波段衞星傳播,利用光盤大小的天線,無需精確調整方向即可接收數據。每顆衞星提供了多達72路128Kbps的可移動的數據廣播及數字音頻服務,世廣"亞洲之星"、"非洲之星"、"美洲之星"覆蓋全球85%人口。
數據廣播相關資料
電視數據廣播包括與節目相關數據和與電視節目無關的數據。
與電視機節目相關的數據將隨節目一起傳送。這種數據又兩種,一類是電子節目指南(EPG),描述節目的播出時間、電影內容簡介、電影演員介紹等。電子界目指南幫助觀眾方便快速的尋找自己感興趣的節目;另一類是與節目內容相關的數據,如與足球比賽有關的雙方球隊戰績、球員的個人背景資料等。觀眾根據自己的需要選出某些與節目有關的數據。
數據廣播方案的優化
這 樣,在數據廣播時便存在一個很大的優化可能性。以前的單服務器架構時,比如要廣播移動消息,可以直接找出周圍的玩家列表,構造要發送的數據,然後依次調用 send即可。但是在多服務器架構下要是還這麼做的話,那地圖服務器與網關服務器之間的數據傳輸量將會非常大,而且這些數據之間除了目標IP地址不一樣 外,實際內容完全相同。
其實在以前單服務器架構時就曾考慮過該優化方案。最初使用的立即發送數據包的方式在遇到需要同時發送大量數據時出 現了問題,為了避免由於在邏輯線程內的send調用導致的遊戲邏輯被阻塞,我們將數據發送工作放到了一個獨立的線程中,遊戲邏輯線程在需要向客户端發送數 據時,只是將要發送的數據包和客户端連接句柄遞交給了發包線程。這個過程也就和帶網關的多服務器架構完全類似了。
最終採取的方案是隻遞交一次發包請求,在請求包裏面包含了這個數據包要發送到的客户端句柄列表,這樣數據完全不需要做拷貝,而且內存佔用也只有一份。
以前的方案只做到了這一步,再繼續考慮一下,其實還有進一步優化的可能。
拿 比較簡單的聊天數據包來説,比如在一個小組頻道內聊天,服務器在廣播此類數據包時,每次遞交的發包請求中的客户端句柄列表都是相同的,除非隊員發生變動。 所以,可以考慮的是這個列表其實不用每次都發送。通過控制命令在網關服務器上先建立好這些廣播組,以後廣播數據時只需要指明廣播組編號即可。在雲風的《遊 戲服務器內的組播》一文中對此有介紹。
這裏的組我們也可以稱之為頻道,比如小組頻道,團隊頻道,公會頻道,世界頻道,本地頻道,當前頻道等,當然還可能會有自建的頻道,每個頻道有一個唯一ID。不同玩家間的當前頻道需要獨立,但其他頻道可以共用。
關 於當前頻道需要特別説明一下。這裏的當前頻道指的是以玩家當前所在位置為中心點的一個可見範圍,也就是當玩家移動,或者説話時需要廣播到的範圍。因為玩家 位置是經常會變動的,所以這個頻道內的玩家列表變動也非常頻繁,而且不同玩家間的當前頻道不能像小組頻道一樣進行共用。
比如一個玩家坐着沒有動,不停有玩家從其旁邊經過,這時他的當前頻道玩家列表是不斷變化的,但如果該玩家不做任何操作,比如移動和在當前頻道聊天,這個變動情況其實是不需要反饋到網關服務器的,因為不會有這個頻道內的數據需要廣播。
當然,如果這樣做的話,可能就需要在地圖服務器上也保留兩份當前頻道玩家列表,用於比較該列表的變動情況,這也就是要在內存佔用和網絡數據傳輸量上做個權衡。雖然未經實踐驗證,目前來説我還是比較傾向於後一種方案。
[1]
- 參考資料
-
- 1. 百度空間