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

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

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

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

　　FLUTE 和 ALC 最大的差異點，是增加了 FDT。FDT 是附屬于 FLUTE session 的一個數據結構，里面記錄了被傳送的 ALC 對象的檔案屬性。以下是 FDT 內可為每個檔案記錄的信息:

　　● 檔案 ID: 指的是代表一個檔案的 URI (Uniform Resource Identifier，通用資源標志符號)，檔案的名稱包含在 URI 內。

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

　　● 檔案內容: 即 ALC 物件的 TOI。

　　● 檔案的編碼方式: DVB-IPDC CDP 標準允許檔案經過 GZip (GNU Zip) 壓縮后才放入 ALC 對象內。

　　● 檔案的原始長度。

　　● 檔案編碼后的長度。

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

　　FLUTE 傳送端該怎么將 FDT 傳送給 FLUTE 接收端呢?答案是透過一種叫 FDT instance (FDT 實例) 的 ALC 對象。跟一般 ALC 對象不同的是，FDT instance 的 TOI 永遠為 零，至于 FLUTE session 內其它的 ALC 對象，TOI 會被指定為其它大于 零 的值。每個 FDT instance 里面會包含 FDT 中一個檔案以上的屬性信息，也有可能會包含 FDT 所有檔案的屬性信息。而且，同一個 FDT instance 被允許在 FLUTE session 內被重復傳送。為了區別同一個 FLUTE session 內所傳送的 FDT instance，每個 FDT instance 都擁有一個獨一無二的 FDT instance ID; 這個 ID 被紀錄在 FLUTE 封包內的 LCT 標頭擴充字段 (LCT header extension) - EXT_FDT 中，凡是 TOI 為 零 的 FLUTE 封包，都會包含這個標頭擴充字段。

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

　　另外，FDT-Instance元素所包含的屬性，也有可能是 FDT instance 內所有的 File 元素共通的預設屬性。例如: 當與 FEC-OTI 相關的屬性被放在 FDT-Instance 元素時，表示這些屬性是FDT instance 內所有 File 元素的預設屬性。反之，當 FEC-OTI 的相關屬性被放在 File 元素時，則表示這些屬性是專屬于該檔案的屬性，而且，File 元素內的 FEC-OTI 可覆蓋FDT-Instance元素所指定的預設屬性。

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

　　最后，我們來談一下 FLUTE 接收端如何由收到的 FDT instance，還原 FLUTE session 的 FDT 數據結構。通常，在接收端會有一個動態的 FDT 數據庫 (FDT database)。在 FDT 數據庫中，每一個正在被接收的 FLUTE session，都會有一個相對應的表格 (table)，表格內儲存了 FLUTE session 中所傳送之檔案的檔案屬性。因為從檔案路徑 (URI) 來搜尋檔案是一般檔案系統的慣例，因此，這個表格的主索引鍵 (primary key) 是檔案的 ID，而不是 ALC 對象的 TOI。

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

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

　　還有一點需要注意的是，不同的 FLUTE 接收端，若接收同一個 FLUTE session，因為開始接收的時間可能不同，實際的接收條件 (FLUTE 封包的遺失或錯誤狀況) 也可能不同，所以，FDT 數據庫內該 FLUTE session 表格的內容，也可能會有所不同。