FLUTE通信协议原理构架

　　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 表格的内容，也可能会有所不同。