FLUTE通信协议的基本架构
在正式开始谈 FLUTE 之前，在此先跟读者们介绍一下 DVB-IPDC 的CDP 标准，所规范的网络架构与通信协议， DVB-H 广播网络 (单向 IP 网络) 是必备的，至于双向的点对点 IP 网络，则仅是一种非必备的选择性功能。由于 TCP 通信协议无法在仅具备单向 IP 网络的环境下运作，因此在 DVB-H 广播网络上的通信协议，如负责传送影音串流的 RTP (Real-time Transport Protocol，实时传输协议)，以及 FLUTE，均是建构在 UDP 通信协议之上的。在 DVB-IPDC 标准的服务平台上，FLUTE 通信协议除了传送一般的使用者档案之外，同时也负责传送 ESG 的数据。
(资料图片仅供参考)
FLUTE 原本是由 IETF (Internet Engineering Task Force) 所制订的一套通信协议 (RFC 3926 - File deLivery over Unidirectional Transport)，可将档案由传送端 (sender) 以多点传送方式，透过 Internet 传送至多个接收端 (receiver) 上。和传统的多点传送通信协议不同的是，FLUTE 在运作时并不需要任何由接收端回传至发送端的回馈信息 (feedback)，因此，接收端的数量几乎可以说是没有限制的，不管是数10万个或是数100万个都没有问题。FLUTE 不需要接收端回馈的运作特性，是它后来会被应用在 DVB-H 单向 IP 网络上的主因。
FLUTE是建构于另一个 IETF 通信协议 - ALC (Asynchronous Layered Coding，异步分层编码) 之上发展的; 而且，甚至我们可以说，ALC 通信协议才是 FLUTE 通信协议的主体。两者的主要差别在于，ALC 是一套单向的 “对象” (object) 多点传送通信协议，而FLUTE 则是一套单向的 “档案” 多点传送通信协议。由于 ALC 所传送的对象本身，并不具任何的属性 (attribute)，因此，FLUTE 通信协议针对 ALC 的最主要扩充，就是将 ALC 传送的对象视为档案，并为每个对象加上档案所需要的属性，例如文件名称、档案长度及档案类型。为此，FLUTE 额外定义了一种叫 FDT (File Description Table，档案描述表) 的数据结构，里面记录了 ALC 对象的档案属性。
ALC是以IP multicast通信协议 (即多点传送的 UDP 通信协议)为基础发展的。基本上，IP multicast只是一种 “尽最大所能传送” (best effort delivery)的多点传送通信协议，本身并没有对话管理 (session management)、壅塞控制 (congestion control)、以及提供可靠传输 (reliable transmission) 的能力。ALC 通信协议建构于 IP multicast 之上，同时也填补了 IP multicast 前述的3个缺点。而且，ALC通信协议可同时适用于 IPv4 与 IPv6 这两种不同版本的 IP 通信协议。
LCT 是可以说是 ALC 通信协议的主体，负责提供前述的 session 管理的功能。CC 则是一个选择性的组成组件，负责 ALC 在 Internet 上的壅塞控制。不过，因为在 DVB-H 广播网络上并不会发生壅塞的问题，所以 CC 在 DVB-IPDC 标准内是不会被使用到的。至于 FEC 则是与 ALC 可靠传输功能相关的组成组件。由于 ALC 在运作时，不需要来自接收端的回馈信息，因此，ALC 主要依靠 FEC 组成组件所提供的前向纠错功能，来弥补 ALC 封包在传送时所发生的遗失或错误。而且，ALC 在设计时，已保留未来可采用各种不同的 FEC 算法的弹性。因此，FEC 组成组件的实际格式，主要是由采用 ALC 的标准 (如 DVB-IPDC CDP 标准)，依其所选择的 FEC 算法而决定的。
在目前的 DVB-IPDC CDP 标准中，仅定义了两种 FEC 组成组件，第一种是必备的 Compact No-Code FEC (意即没有 FEC)，第二种则是非必备的 Raptor FEC。DVB-IPDC CDP 标准将 Compact No-Code FEC 纳入标准的必备功能，笔者猜测可能有以下3点原因: 1、便于进行 FLUTE 通信协议的兼容性测试。2、在 DVB-H 标准中，由于 MAC 层已提供 MPE-FEC 的前向纠错功能，因此，DVB-H 的 IP 封包传送错误率，以数据传送的角度来说，尚在可接受的范围内。3、由于 Raptor FEC 是 Digital Fountain 公司所拥有的专利技术，除非真的非常必要，不然不会被纳入标准的必备功能。
FLUTE 通信协议的运作原理
在此，我们先跟读者们介绍 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 表格的内容，也可能会有所不同。
