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)傳送方式，透過 Internet 傳送至多個(gè)接收端 (receiver) 上。和傳統(tǒng)的多點(diǎn)傳送通信協(xié)議不同的是，F(xiàn)LUTE 在運(yùn)作時(shí)并不需要任何由接收端回傳至發(fā)送端的回饋信息 (feedback)，因此，接收端的數(shù)量幾乎可以說(shuō)是沒有限制的，不管是數(shù)10萬(wàn)個(gè)或是數(shù)100萬(wàn)個(gè)都沒有問題。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é)議，本身并沒有對(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 上的壅塞控制。不過，因?yàn)樵?DVB-H 廣播網(wǎng)絡(luò)上并不會(huì)發(fā)生壅塞的問題，所以 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 (意即沒有 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)的必備功能。