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é)議無法在僅具備單向 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ù)量幾乎可以說是沒有限制的，不管是數(shù)10萬個(gè)或是數(shù)100萬個(gè)都沒有問題。FLUTE 不需要接收端回饋的運(yùn)作特性，是它后來會(huì)被應(yīng)用在 DVB-H 單向 IP 網(wǎng)絡(luò)上的主因。

　　FLUTE是建構(gòu)于另一個(gè) IETF 通信協(xié)議 - ALC (Asynchronous Layered Coding，異步分層編碼) 之上發(fā)展的; 而且，甚至我們可以說，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 是可以說是 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í)，不需要來自接收端的回饋信息，因此，ALC 主要依靠 FEC 組成組件所提供的前向糾錯(cuò)功能，來彌補(bǔ) ALC 封包在傳送時(shí)所發(fā)生的遺失或錯(cuò)誤。而且，ALC 在設(shè)計(jì)時(shí)，已保留未來可采用各種不同的 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ù)傳送的角度來說，尚在可接受的范圍內(nèi)。3、由于 Raptor FEC 是 Digital Fountain 公司所擁有的專利技術(shù)，除非真的非常必要，不然不會(huì)被納入標(biāo)準(zhǔn)的必備功能。

FLUTE 通信協(xié)議的運(yùn)作原理

　　在此，我們先跟讀者們介紹 FLUTE session 的觀念?；旧?，一個(gè) FLUTE session 所代表的是一個(gè) FLUTE 的傳送端，在一段指定的時(shí)間區(qū)間內(nèi)，透過 FLUTE 通信協(xié)議傳送一群對(duì)象的行為。因此，代表一個(gè) FLUTE session 的 ID，是由 FLUTE session 傳送端的 IP 地址，再加上 FLUTE session 的 TSI (Transport Session Identifier) 所組成。在一個(gè) FLUTE session 內(nèi)，會(huì)包含一個(gè)或多個(gè) FLUTE channel (頻道)。基本上，這些 FLUTE channel 的來源 IP 地址就是 FLUTE session 傳送端的 IP 地址。另外，不同的 FLUTE channel 會(huì)有各自的目的 IP 地址及通信阜 (port)。在一個(gè) FLUTE channel 中所傳送的每一個(gè) FLUTE 封包，其來源 IP 地址、目的 IP 地址及通信阜的值，都會(huì)與其所屬的 FLUTE channel 相同。FLUTE 接收端可選擇加入一個(gè) FLUTE channel，以接收 FLUTE channel 內(nèi)所傳送的 FLUTE 封包。基本上，F(xiàn)LUTE 接收端加入或離開一個(gè) FLUTE channel 的方法，跟加入或離開一個(gè) IP multicast 群組 (group) 是完全相同的。

　　在一個(gè) FLUTE session 內(nèi)所傳送的每個(gè)檔案，基本上都是一個(gè) ALC 對(duì)象 .而且，F(xiàn)LUTE session 中的每個(gè) ALC 對(duì)象，都會(huì)有一個(gè)獨(dú)一無二的 TOI (Transport Object ID)。每個(gè) ALC 對(duì)象在傳送前，都會(huì)經(jīng)過分割及加入 FEC 信息的流程，然后才會(huì)被放入 FLUTE 封包中被傳送。而且，每個(gè) ALC 對(duì)象均可以自由實(shí)行不同的FEC 算法。在計(jì)算 FEC 信息之前，ALC 對(duì)象會(huì)被分割成一到數(shù)個(gè) source block (來源區(qū)塊)。基本上，F(xiàn)EC 信息是針對(duì)每個(gè) source block 獨(dú)立計(jì)算的。首先，一個(gè) source block 會(huì)被分割成大小相同的 source symbol (來源符號(hào))。接著，F(xiàn)EC 算法再由這些 source symbol，計(jì)算出該 source block 的 parity symbol (檢查碼符號(hào))。因?yàn)?source symbol 與 parity symbol 的大小是一致的，因此，它們也被統(tǒng)稱為 encoding symbol (編碼符號(hào))。

　　在一個(gè) FLUTE 封包內(nèi)，可裝入一個(gè)到數(shù)個(gè)屬于同一個(gè) ALC 物件的 encoding symbol。至于 encoding symbol 如何被裝入 FLUTE 封包內(nèi)的實(shí)際方式，則與 ALC 對(duì)象所實(shí)行的 FEC 算法有關(guān)。例如，若 ALC 對(duì)象未經(jīng) FEC 編碼 (Compact No-Code FEC)，則一個(gè) FLUTE 封包內(nèi)，可裝入一個(gè)到數(shù)個(gè)連續(xù)的 encoding symbol。在該 FLUTE 封包的標(biāo)頭 (header) 內(nèi)，會(huì)記錄該 ALC 對(duì)象的 TOI，以及傳送該 ALC 對(duì)象之 FLUTE session 的 TSI。此外，該 FLUTE 封包的標(biāo)頭內(nèi)也會(huì)記錄被傳送的第一個(gè) encoding symbol 的 source block number (SBN，來源區(qū)塊編號(hào)) 及 encoding symbol identifier (ESI，編碼符號(hào) ID)。

　　至于將 ALC 對(duì)象分割成 source block 的區(qū)塊化算法 (blocking algorithm)，也是由 ALC 對(duì)象所實(shí)行的 FEC 算法決定的。因此，針對(duì)每一個(gè) ALC 對(duì)象，會(huì)有一份 FEC-OTI (FEC Object Transmission Information，F(xiàn)EC 對(duì)象傳遞信息)，里面記錄了該 ALC 對(duì)象所實(shí)行的 FEC 算法 (稱作 FEC encoding ID，F(xiàn)EC 編碼 ID)，以及其它區(qū)塊化算法所需要的參數(shù)。例如，若 ALC 對(duì)象未經(jīng) FEC 編碼 (Compact No-Code FEC)，則該對(duì)象的 FEC-OTI 包括了: ALC 對(duì)象的原始長(zhǎng)度、FEC encoding ID (值為 零)、encoding symbol 的大小、以及一個(gè) source block 所能包含的 encoding symbol 的最大數(shù)量。因此，一旦 FLUTE 接收端收到一個(gè) ALC 對(duì)象的 FEC-OTI 后，即可得知該 ALC 對(duì)象會(huì)被分割成幾個(gè) source block、每個(gè) source block 內(nèi)包含了幾個(gè) source symbol、以及 source symbol (encoding symbol) 的大小。這些信息可協(xié)助 FLUTE 接收端，解碼與重組屬于該 ALC 物件的 encoding symbol。

　　FLUTE 和 ALC 最大的差異點(diǎn)，是增加了 FDT。FDT 是附屬于 FLUTE session 的一個(gè)數(shù)據(jù)結(jié)構(gòu)，里面記錄了被傳送的 ALC 對(duì)象的檔案屬性。以下是 FDT 內(nèi)可為每個(gè)檔案記錄的信息:

　　● 檔案 ID: 指的是代表一個(gè)檔案的 URI (Uniform Resource Identifier，通用資源標(biāo)志符號(hào))，檔案的名稱包含在 URI 內(nèi)。

　　● 檔案類型: 格式為 MIME (Multipurpose Internet Mail Extensions，多用途 Internet 郵件擴(kuò)展) 所定義的媒體類型。

　　● 檔案內(nèi)容: 即 ALC 物件的 TOI。

　　● 檔案的編碼方式: DVB-IPDC CDP 標(biāo)準(zhǔn)允許檔案經(jīng)過 GZip (GNU Zip) 壓縮后才放入 ALC 對(duì)象內(nèi)。

　　● 檔案的原始長(zhǎng)度。

　　● 檔案編碼后的長(zhǎng)度。

　　● 檔案安全信息: 如數(shù)字摘要信息 (digital digest) 或數(shù)字簽章 (digital signature)。

　　FLUTE 傳送端該怎么將 FDT 傳送給 FLUTE 接收端呢?答案是透過一種叫 FDT instance (FDT 實(shí)例) 的 ALC 對(duì)象。跟一般 ALC 對(duì)象不同的是，F(xiàn)DT instance 的 TOI 永遠(yuǎn)為 零，至于 FLUTE session 內(nèi)其它的 ALC 對(duì)象，TOI 會(huì)被指定為其它大于 零 的值。每個(gè) FDT instance 里面會(huì)包含 FDT 中一個(gè)檔案以上的屬性信息，也有可能會(huì)包含 FDT 所有檔案的屬性信息。而且，同一個(gè) FDT instance 被允許在 FLUTE session 內(nèi)被重復(fù)傳送。為了區(qū)別同一個(gè) FLUTE session 內(nèi)所傳送的 FDT instance，每個(gè) FDT instance 都擁有一個(gè)獨(dú)一無二的 FDT instance ID; 這個(gè) ID 被紀(jì)錄在 FLUTE 封包內(nèi)的 LCT 標(biāo)頭擴(kuò)充字段 (LCT header extension) - EXT_FDT 中，凡是 TOI 為 零 的 FLUTE 封包，都會(huì)包含這個(gè)標(biāo)頭擴(kuò)充字段。

　　FDT-Instance 元素內(nèi)所包含的 File 元素，則描述了 FLUTE session 內(nèi)某個(gè) ALC 對(duì)象的檔案屬性。舉例來說，圖5中的第一個(gè) File 元素，里面所包含的是 FLUTE session 中，TOI 為 1 的 ALC 對(duì)象的檔案屬性。File元素內(nèi)的 Content-Location 屬性，是一個(gè) URI，為代表該檔案的 ID。Content-Type 屬性標(biāo)示的是檔案的 MIME 媒體類型。Content-Length 屬性則為檔案編碼前的原始長(zhǎng)度。

　　另外，F(xiàn)DT-Instance元素所包含的屬性，也有可能是 FDT instance 內(nèi)所有的 File 元素共通的預(yù)設(shè)屬性。例如: 當(dāng)與 FEC-OTI 相關(guān)的屬性被放在 FDT-Instance 元素時(shí)，表示這些屬性是FDT instance 內(nèi)所有 File 元素的預(yù)設(shè)屬性。反之，當(dāng) FEC-OTI 的相關(guān)屬性被放在 File 元素時(shí)，則表示這些屬性是專屬于該檔案的屬性，而且，F(xiàn)ile 元素內(nèi)的 FEC-OTI 可覆蓋FDT-Instance元素所指定的預(yù)設(shè)屬性。

　　在此附帶一提的是，一個(gè) ALC 對(duì)象的 FEC-OTI，除了可放在 FDT instance 中傳送之外，也可放在傳送該 ALC 對(duì)象的 FLUTE 封包中傳送。有一種 FLUTE 封包內(nèi)的 LCT 標(biāo)頭擴(kuò)充字段 - EXT_FTI，是用來傳送 ALC 對(duì)象的 FDT-OTI 信息的。由于每個(gè) ALC 對(duì)象所需的 FDT-OTI 信息，是由 ALC 對(duì)象所實(shí)行的 FEC 算法 (FEC encoding ID) 決定的，因此，傳送 ALC 對(duì)象的 FLUTE 封包內(nèi)，EXT_FTI 標(biāo)頭擴(kuò)充字段的實(shí)際格式，也是由 FEC 算法決定的。基本上，F(xiàn)DT instance 的 FEC-OTI 一定要透過 EXT_FTI 來傳送。但是一般的 ALC 對(duì)象，就可以選擇要用 EXT_FTI 或 FDT instance 來傳送該 ALC 對(duì)象的 FEC-OTI; 不過，不管采用哪種方式，被傳送的 FEC-OTI，在格式和內(nèi)容上都必須是一樣的。

　　最后，我們來談一下 FLUTE 接收端如何由收到的 FDT instance，還原 FLUTE session 的 FDT 數(shù)據(jù)結(jié)構(gòu)。通常，在接收端會(huì)有一個(gè)動(dòng)態(tài)的 FDT 數(shù)據(jù)庫 (FDT database)。在 FDT 數(shù)據(jù)庫中，每一個(gè)正在被接收的 FLUTE session，都會(huì)有一個(gè)相對(duì)應(yīng)的表格 (table)，表格內(nèi)儲(chǔ)存了 FLUTE session 中所傳送之檔案的檔案屬性。因?yàn)閺臋n案路徑 (URI) 來搜尋檔案是一般檔案系統(tǒng)的慣例，因此，這個(gè)表格的主索引鍵 (primary key) 是檔案的 ID，而不是 ALC 對(duì)象的 TOI。

　　當(dāng) FLUTE 接收端每收到一個(gè) FLUTE session 的 FDT instance，就會(huì)將其中包含的檔案之屬性，連同 FDT instance 的 ID 及FDT-Instance 元素的 Expires 屬性，一起記錄在該 FLUTE session 的表格中。若 FDT instance 內(nèi)所包含的檔案 ID，已經(jīng)存在表格中，此時(shí)需要比較收到的 FDT instance 之 ID，與表格中該檔案 ID 所記錄的 FDT instance ID。只有當(dāng)表格中所記錄的 FDT instance ID，小于收到的 FDT instance 之 ID 時(shí)，表格中關(guān)于該檔案的屬性才需要被更新。事實(shí)上，這也是 FLUTE 用來更新一個(gè)檔案的版本的方式; 當(dāng)一個(gè) FLUTE 所傳送的檔案之內(nèi)容發(fā)生改變時(shí)，該檔案的 ID 不變，但 TOI 會(huì)改變，以指向另一個(gè)不同的 ALC 物件。

　　要判斷一個(gè) FLUTE session 中的檔案已經(jīng)被刪除，有以下兩種方式: 1、表格中的檔案已超過 FDT-Instance 元素的 Expires 屬性所指定時(shí)間。2、接收到一個(gè)新的 FDT instance (意即 FDT instance ID 更高)，其 FDT-Instance 元素的 Complete 屬性被設(shè)定為真，因此，不在這個(gè)新收到的 FDT instance 內(nèi)的檔案，都會(huì)被刪除。另外，在 FLUTE 標(biāo)準(zhǔn)內(nèi)也要求，針對(duì)同一個(gè) ALC 對(duì)象 (TOI 相同) 的檔案屬性，在未來 FDT instance ID 更大的 FDT instance 中，只能加入和原有屬性不會(huì)產(chǎn)生矛盾的新檔案屬性。因此，在 DVB-IPDC CDP 標(biāo)準(zhǔn)中規(guī)定，若一個(gè)檔案的屬性存在于兩個(gè)不同的 FDT instance 中，而且，在這兩個(gè) FDT instance 中的該檔案，使用的是相同的 TOI，則該檔案的刪除時(shí)間為兩個(gè) FDT instance 中，Expires 屬性所指定的時(shí)間比較晚的那一個(gè)。

　　還有一點(diǎn)需要注意的是，不同的 FLUTE 接收端，若接收同一個(gè) FLUTE session，因?yàn)殚_始接收的時(shí)間可能不同，實(shí)際的接收條件 (FLUTE 封包的遺失或錯(cuò)誤狀況) 也可能不同，所以，F(xiàn)DT 數(shù)據(jù)庫內(nèi)該 FLUTE session 表格的內(nèi)容，也可能會(huì)有所不同。