FLUTE通信协议的基本架构。
在正式谈论FLUTE之前，我想向读者介绍一下DVB-IPDC的CDP标准。规范的网络架构和通信协议，DVB-H广播网络(单向IP网络)是必要的，而双向点对点IP网络只是一个非必要的可选功能。TCP通信协议无法在单向IP网络的环境下工作，所以DVB-H广播网上负责传输视频和音频流的RTP(实时传输协议)和FLUTE等通信协议都是建立在UDP通信协议上的。在DVB-IPDC标准的服务平台上，FLUTE通信协议负责传输ESG数据和通用用户文件。
FLUTE最初是IETF(互联网工程任务组)制定的一套通信协议(RFC 3926-单向传输上的文件传递)，可以通过互联网以组播方式将文件从发送方发送到多个接收方。与传统的组播通信协议不同，FLUTE在运行中不需要从接收方到发送方的任何反馈。因此，接收器的数量几乎没有限制，无论是10万还是100万。FLUTE不需要接收器的反馈，这也是它将用于DVB-H单向IP网络的主要原因。
FLUTE建立在另一个IETF通信协议built(异步分层编码)之上。而且，我们甚至可以说ALC通信协议是FLUTE通信协议的主体。两者的主要区别在于，ALC是单向“对象”组播通信协议，而FLUTE是单向“文件”组播通信协议。由于ALC发送的对象没有任何属性，因此FLUTE通信协议对ALC的主要扩展是将ALC发送的对象视为文件，并为每个对象添加文件所需的属性，如文件名、文件长度和文件类型。因此，FLUTE定义了一个名为FDT(文件描述表)的数据结构，它记录了ALC对象的文件属性。
ALC是在IP组播通信协议(即组播的UDP通信协议)的基础上发展起来的。基本上，IP组播只是一种“尽力交付”的组播通信协议，不具备会话管理、拥塞控制和可靠传输的能力。ALC通信协议建立在IP组播的基础上，同时也弥补了IP组播的三个缺点。此外，ALC通信协议可以应用于两种不同版本的IP通信协议，即IPv4和IPv6。
LCT是ALC通信协议的主体，负责提供上述会话管理功能。CC是一个可选组件，负责互联网上ALC的拥塞控制。但是，由于DVB-H广播网络中不会出现拥塞，因此在DVB-IPDC标准中不会使用CC。前向纠错是与ALC可靠传输功能相关的一个组成部分。由于ALC在操作期间不需要来自接收机的反馈信息，所以ALC主要依靠由前向纠错组件提供的前向纠错功能来弥补传输期间ALC分组的丢失或错误。此外，在设计ALC时，保留了未来采用各种FEC算法的灵活性。因此，FEC分量的实际格式主要由采用ALC的标准(如DVB-IPDC CDP标准)和选择的FEC算法决定。
在当前的DVB-IPDC CDP标准中，只定义了两个FEC组件，第一个是必需的Compact No-Code FEC(意思是没有FEC)，第二个是非必需的Raptor FEC。DVB-IPDC CDP标准将紧凑无代码前向纠错作为标准的基本功能。我猜可能有以下三个原因： 1。方便测试FLUTE通信协议的兼容性。2.在DVB-H标准中，由于MAC层提供了MPE-FEC前向纠错功能，所以DVB-H的IP包传输误码率在数据传输方面还是在可接受的范围内。3.因为猛禽FEC是Digital Source拥有的专利技术，除非确有必要，否则不会纳入标准的本质功能。
FLUTE通信协议的工作原理。
在这里，我们首先向读者介绍FLUTE会话的概念。基本上，一个FLUTE会话代表一个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 表格的内容，也可能会有所不同。