FLUTE通信協(xié)議原理構(gòu)架

　　FLUTE通信協(xié)議的基本架構(gòu)

　　在正式開始談 FLUTE 之前，在此先跟讀者們介紹一下 DVB-IPDC 的CDP 標(biāo)準(zhǔn)，所規(guī)范的網(wǎng)絡(luò)架構(gòu)與通信協(xié)議， DVB-H 廣播網(wǎng)絡(luò) (單向 IP 網(wǎng)絡(luò)) 是必備的，至于雙向的點(diǎn)對(duì)點(diǎn) IP 網(wǎng)絡(luò)，則僅是一種非必備的選擇性功能。由于 TCP 通信協(xié)議無(wú)法在僅具備單向 IP 網(wǎng)絡(luò)的環(huán)境下運(yùn)作，因此在 DVB-H 廣播網(wǎng)絡(luò)上的通信協(xié)議，如負(fù)責(zé)傳送影音串流的 RTP (Real-time Transport Protocol，實(shí)時(shí)傳輸協(xié)議)，以及 FLUTE，均是建構(gòu)在 UDP 通信協(xié)議之上的。在 DVB-IPDC 標(biāo)準(zhǔn)的服務(wù)平臺(tái)上，F(xiàn)LUTE 通信協(xié)議除了傳送一般的使用者檔案之外，同時(shí)也負(fù)責(zé)傳送 ESG 的數(shù)據(jù)。

　　FLUTE 原本是由 IETF (Internet Engineering Task Force) 所制訂的一套通信協(xié)議 (RFC 3926 - File deLivery over Unidirectional Transport)，可將檔案由傳送端 (sender) 以多點(diǎn)傳送方式，透過(guò) Internet 傳送至多個(gè)接收端 (receiver) 上。和傳統(tǒng)的多點(diǎn)傳送通信協(xié)議不同的是，F(xiàn)LUTE 在運(yùn)作時(shí)并不需要任何由接收端回傳至發(fā)送端的回饋信息 (feedback)，因此，接收端的數(shù)量幾乎可以說(shuō)是沒(méi)有限制的，不管是數(shù)10萬(wàn)個(gè)或是數(shù)100萬(wàn)個(gè)都沒(méi)有問(wèn)題。FLUTE 不需要接收端回饋的運(yùn)作特性，是它后來(lái)會(huì)被應(yīng)用在 DVB-H 單向 IP 網(wǎng)絡(luò)上的主因。

　　FLUTE是建構(gòu)于另一個(gè) IETF 通信協(xié)議 - ALC (Asynchronous Layered Coding，異步分層編碼) 之上發(fā)展的; 而且，甚至我們可以說(shuō)，ALC 通信協(xié)議才是 FLUTE 通信協(xié)議的主體。兩者的主要差別在于，ALC 是一套單向的 “對(duì)象” (object) 多點(diǎn)傳送通信協(xié)議，而FLUTE 則是一套單向的 “檔案” 多點(diǎn)傳送通信協(xié)議。由于 ALC 所傳送的對(duì)象本身，并不具任何的屬性 (attribute)，因此，F(xiàn)LUTE 通信協(xié)議針對(duì) ALC 的最主要擴(kuò)充，就是將 ALC 傳送的對(duì)象視為檔案，并為每個(gè)對(duì)象加上檔案所需要的屬性，例如文件名稱、檔案長(zhǎng)度及檔案類型。為此，F(xiàn)LUTE 額外定義了一種叫 FDT (File Description Table，檔案描述表) 的數(shù)據(jù)結(jié)構(gòu)，里面記錄了 ALC 對(duì)象的檔案屬性。

　　ALC是以IP multicast通信協(xié)議 (即多點(diǎn)傳送的 UDP 通信協(xié)議)為基礎(chǔ)發(fā)展的?；旧?，IP multicast只是一種 “盡最大所能傳送” (best effort delivery)的多點(diǎn)傳送通信協(xié)議，本身并沒(méi)有對(duì)話管理 (session management)、壅塞控制 (congestion control)、以及提供可靠傳輸 (reliable transmission) 的能力。ALC 通信協(xié)議建構(gòu)于 IP multicast 之上，同時(shí)也填補(bǔ)了 IP multicast 前述的3個(gè)缺點(diǎn)。而且，ALC通信協(xié)議可同時(shí)適用于 IPv4 與 IPv6 這兩種不同版本的 IP 通信協(xié)議。

　　LCT 是可以說(shuō)是 ALC 通信協(xié)議的主體，負(fù)責(zé)提供前述的 session 管理的功能。CC 則是一個(gè)選擇性的組成組件，負(fù)責(zé) ALC 在 Internet 上的壅塞控制。不過(guò)，因?yàn)樵?DVB-H 廣播網(wǎng)絡(luò)上并不會(huì)發(fā)生壅塞的問(wèn)題，所以 CC 在 DVB-IPDC 標(biāo)準(zhǔn)內(nèi)是不會(huì)被使用到的。至于 FEC 則是與 ALC 可靠傳輸功能相關(guān)的組成組件。由于 ALC 在運(yùn)作時(shí)，不需要來(lái)自接收端的回饋信息，因此，ALC 主要依靠 FEC 組成組件所提供的前向糾錯(cuò)功能，來(lái)彌補(bǔ) ALC 封包在傳送時(shí)所發(fā)生的遺失或錯(cuò)誤。而且，ALC 在設(shè)計(jì)時(shí)，已保留未來(lái)可采用各種不同的 FEC 算法的彈性。因此，F(xiàn)EC 組成組件的實(shí)際格式，主要是由采用 ALC 的標(biāo)準(zhǔn) (如 DVB-IPDC CDP 標(biāo)準(zhǔn))，依其所選擇的 FEC 算法而決定的。

　　在目前的 DVB-IPDC CDP 標(biāo)準(zhǔn)中，僅定義了兩種 FEC 組成組件，第一種是必備的 Compact No-Code FEC (意即沒(méi)有 FEC)，第二種則是非必備的 Raptor FEC。DVB-IPDC CDP 標(biāo)準(zhǔn)將 Compact No-Code FEC 納入標(biāo)準(zhǔn)的必備功能，筆者猜測(cè)可能有以下3點(diǎn)原因: 1、便于進(jìn)行 FLUTE 通信協(xié)議的兼容性測(cè)試。2、在 DVB-H 標(biāo)準(zhǔn)中，由于 MAC 層已提供 MPE-FEC 的前向糾錯(cuò)功能，因此，DVB-H 的 IP 封包傳送錯(cuò)誤率，以數(shù)據(jù)傳送的角度來(lái)說(shuō)，尚在可接受的范圍內(nèi)。3、由于 Raptor FEC 是 Digital Fountain 公司所擁有的專利技術(shù)，除非真的非常必要，不然不會(huì)被納入標(biāo)準(zhǔn)的必備功能。