YD/T 949-1998
基本信息
标准号： YD/T 949-1998
中文名称：多点二进制文件传送协议
标准类别：通信行业标准(YD)
标准状态：现行
出版语种：简体中文
下载格式：.zip .pdf
下载大小：7279099
相关标签： 协议
标准分类号
关联标准
出版信息
相关单位信息
标准简介
YD/T 949-1998.Multipoint binary file transfer protocol.
1范围
YD/T 949定义了一个协议,旨在支持交互式会议或群工作环境下的二进制文件的互换。在该环境中使用T.120系列标准。它提供的机制是:使用T.122(多点通信服务)所提供的原语,可方便地同时分发和检索一份或多份文件本标准的设计目标是提供一个多用途的简便协议,该协议可为要求基本文件传送能力的应用之间互通提供核心功能，同时该协议也有满足更复杂的应用需求的灵活性,参见图1。
2引用标准
下列标准和其他参考资料所包含的条文,通过在本标准中引用而构成为本标准的条文,本标准出版时，所示版本均为有效。这些标准和其他参考资料都会被修订,使用本标准的各方应探讨使用下列标准和其他参考资料最新版本的可能性。
CCITT建议T.35(1991) CCITT成员代码的分派规程(非标准设备)
ITU-T建议T.120(199X)多媒体会议 电话的数据协议
ITU-T建议T.122(1993)音 像和视听会议的多点通信服务的服务定义
ITU-T建议T.123(1994)音像和视听会议应用的协议栈
ITU-T建议T.124(1995)通用会议控制
ITU-T建议T.125(1994)多点通信服务协议规范
ITU-T建议T.434(1992)用于 远程信息处理服务的二进制文件传送格式
ITU-T建议H.221(1993)在视听 远程服务中用于64~1920kbit/s信道的帧结构
1范围
YD/T 949定义了一个协议,旨在支持交互式会议或群工作环境下的二进制文件的互换。在该环境中使用T.120系列标准。它提供的机制是:使用T.122(多点通信服务)所提供的原语,可方便地同时分发和检索一份或多份文件本标准的设计目标是提供一个多用途的简便协议,该协议可为要求基本文件传送能力的应用之间互通提供核心功能，同时该协议也有满足更复杂的应用需求的灵活性,参见图1。
2引用标准
下列标准和其他参考资料所包含的条文,通过在本标准中引用而构成为本标准的条文,本标准出版时，所示版本均为有效。这些标准和其他参考资料都会被修订,使用本标准的各方应探讨使用下列标准和其他参考资料最新版本的可能性。
CCITT建议T.35(1991) CCITT成员代码的分派规程(非标准设备)
ITU-T建议T.120(199X)多媒体会议 电话的数据协议
ITU-T建议T.122(1993)音 像和视听会议的多点通信服务的服务定义
ITU-T建议T.123(1994)音像和视听会议应用的协议栈
ITU-T建议T.124(1995)通用会议控制
ITU-T建议T.125(1994)多点通信服务协议规范
ITU-T建议T.434(1992)用于 远程信息处理服务的二进制文件传送格式
ITU-T建议H.221(1993)在视听 远程服务中用于64~1920kbit/s信道的帧结构
标准图片预览
标准内容
YD/T949--1998
本标准等效采用ITU-T建议T.127（1995年版本）《用于音像和视听会议业务的多点通信服务》。该建议是有关音像和视听会议业务的多点通信的应用协议和服务的ITU-T.120系列建议之一。本标准定义了一个协议，旨在支持交互式会议或群工作环境下的二进制文件数据的互换。在该环境中使用T.120系列标准。它提供的机制可支持同时分发多份文件，可选择向部分与会者分发文件和由远端检索文件。制定的条款也适用于远程目录访问。本标准的附录A和附录B是标准的附录，附录C和附录D是提示的附录。本标准由原邮电部电信科学研究规划院提出并归口。本标准由原邮电部数据通信技术研究所负责起草。本标准主要起草人：张勇。
1范围
中华人民共和国通信行业标准
多点二进制文件传送协议
MultipointbinaryfiletransferprotocolYD/T949---1998
eqvITU-TT.127:1995
本标准定义了一个协议，旨在支持交互式会议或群工作环境下的二进制文件的互换。在该环境中使用T.120系列标准。它提供的机制是：使用T.122（多点通信服务）所提供的原语，可方便地同时分发和检索一份或多份文件。本标准的设计目标是提供一个多用途的简便协议，该协议可为要求基本文件传送能力的应用之间互通提供核心功能，同时该协议也有满足更复杂的应用需求的灵活性，参见图1。用广应用（采用标准和非标准应用协议）用户应用
（采用标准应用协议）
T.126静止图像（SD)
节点控制器
通用会议控制(GCC)
多点通信服务（MCS）
T.122/T.125
网络特定的运输协议
图1本标准的适用范围
2引用标准
用户应用
（采用非标准协议）
非标准应用协议实体
下列标准和其他参考资料所包含的条文，通过在本标准中引用而构成为本标准的条文，本标准出版时，所示版本均为有效。这些标准和其他参考资料都会被修订，使用本标准的各方应探讨使用下列标准和其他参考资料最新版本的可能性。CCITT建议T.35（1991）CCITT成员代码的分派规程（非标准设备）中华人民共和国信息产业部1998-07-14批准482
1999-01-01实施
ITU-T建议T.120(199X）
ITU-T建议T.122(1993)
ITU-T建议T.123(1994)
ITU-T建议T.124(1995)
ITU-T建议T.125(1994)
ITU-T建议T.434(1992)
ITU-T建议H.221（1993)
ITU建议X.680(1994)
YD/T949--1998
多媒体会议电话的数据协议
音像和视听会议的多点通信服务的服务定义音像和视听会议应用的协议栈
通用会议控制
多点通信服务协议规范
用于远程信息处理服务的二进制文件传送格式在视听远程服务中用于64~1920kbit/s信道的赖结构信息技术—抽象句法表记法-（ASN.1)基本表记法规范ITU-T建议X.691（1995)
ITU-T建议V.42bis(1990)
信息技术-ASN.1编码规则压缩编码规则（PER）的规范采用纠错规程的数据电路终接设备(DCE)使用的数据压缩规程ISO/IEC3309（1993）信息技术一系统间通信和信息交换-高级数据链路控制（HDLC)规程顿结构
信息处理系统开放系统互连——文件传送、访问和管理（FTAM）-第ISO8571-2(1988）
二部分：虚拟文件存储定义
3定义
确认数据信道：一种多点通信服务信道，在该信道上可分发文件。与会者对确认数据信道上所提供的文件有拒绝的选择权。确认数据信道可以是独占的（即只有信道的创建者可以在该信道上发送文件），也可以是共享的（任何与会者都可在该信道上发送文件）。广播数据信道：一一种多点通信服务信道。在该信道上可分发文件。与会者必须接收在该信道上分发的所有文件；如果哪个与会者不需要，剿在本地予以丢弃。控制信道：一种多点通信服务信道，用于管理文件的事务处理。文件属性：一份文件的文件名和其他可标识的特性。FILE-REQUEST：一种令牌，用于保证在会话控制信道MBFT-CONTROL上最多有一个未决的文件请求。
FILE-REQUEST（P）：一种令牌，用于保证在子会话控制信道MBFT-CONTROL（P）上最多有~个未决的文件请求。
FILE-TRANSMIT：一种令牌，用于保证在会话广播数据信道MBFT-DATA上最多有-个正在进行的文件传送。
FILE-TRANSMIT（p）：一种令牌，用于保证在子会话广播数据信道MBFT-DATA（P）上最多有一个正在进行的文件传送。
FILE-TRANSMIT（n）：一种令牌，用于保证在确认数据信道MBFT-DATA（n）上最多有一个正在进行的文件传送。
MBFT-CONTROL：会话控制信道。MBFT-CONTROL(p）：子会话控制信道，其MCS信道ID是P。MBFT-DATA：会话广播数据信道。MBFT-DATA（p）：子会话广播数据信道，其MCS信道ID是P。MBFT-DATA（n）：确认数据信道，其MCS信道ID是n。非标准能力：本标准范围之外的一种能力，在使用非标准能力之前必须协商。会话：一组对等的应用协议实体。标准能力：本标准范围内定义的一种能力，但并非所有MBFT的实现都需要这种能力。所以在使用标准能力之前必须协商。
子会话：在一个会话内对等的应用协议实体的一个子群。483
4缩略语
GCCSAP
应用资源管理器
应用协议实体
应用服务单元
通用会议控制
YD/T949-1998
通用会议控制的服务接入点
多点二进制文件传送
多点通信服务
多点通信服务的服务接入点
协议数据单元
5多点文件传送简介
为了支持不在一地的与会者进行会谈、会议等活动，需要将两个或多个地方连接起来。术语多点通信就是描述了多个终端的互连。多点二进制文件传送（MBFT)在多点环境下通过使用与基础网络无关的多点通信服务（MCS），使与会者之间能够进行交互式的文件交换。特别是本标准提供灵活有效的机制支持：。同时分发多份文件
·向会议的全体与会者广播文件：向部分与会者有选择地分发文件·从远端站点检索文件
。中断之后文件部分重传
·远程目录访问
6数据的多点传送
为了便于同时传送一份或多份二进制文件，本标准采用了一种控制和数据信道体系结构，见图2它使文件能够向会议的所有与会者广播，或者作为一种专用文件传送有选择地向部分站点传送。对所传送的数据类型没有限制。
本标准中采用了两种类型的信道：控制信道和数据信道。控制信道用于对文件传送的各方面实施管理（提供文件，请求文件），而数据信道则用于传送文件数据。在每条数据信道上，某一时刻仅能传送一份文件。但能采用附加的数据信道同时分发多份文件。在任何给定的时间内，使用的数据信道数目取决于要同时传送的文件数。
相互通信的一组文件传送应用被称为参与同一文件传送的会话。每个文件传送的会话都要求一条单独的控制信道和一条或多条数据信道，用于向所有与会应用分发文件。本标准支持两种类型的数据信道：广播和确认数据信道。如果某个发送者希望所有的节点都接收它提供的某份文件，那么它应采用广播数据信道。在该文件传送的会话期内，所有的节点都必须处于广播数据信道下并接收信道上分发的所有文件；如果某份文件是不需要的，则应由接收者予以丢弃。如果发送者希望给予其他节点可拒绝某份文件的选择权，则它应在确认数据信道上传送该文件。在这种情况下，每个节点都必须告知发送者它是否需要该份文件。这时只有那些希望获得该份文件的节点才加入数据信道。通过使用确认数据信道可支持多份文件的同时传送。如果发送者认为文件头中的一个或多个参数是该应用操作的必不可少的参数，则应使用确认数据信道。比如，某个应用可能要求由接收者保留某个通路名以供将来引用。当将该文件提供分发时，应标识键参数，此时那些不能够支持所有这样的参数的节点必须拒绝该文件。484
YD/T949--1998
确认数据信道的创建者可被指定是独占的（即只有创建者可在该信道上发送文件），或者是共享的（即任何与会者都可以在该信道上发送文件）。当节点都必须在广播信道上接收分发的所有文件时，该信道上的文件事务处理不要求发送者和接收者有任何联络过程，使得在广播数据信道进行事务处理时的启始文件传送的等待时间减至最小。在确认数据信道上的事务处理会在启始一份文件传送时引起某些等待时间。但是，由于避免了向不要求数据的站点分发不需要的数据，总体性能可能会更好。特别是当这样的站点是处于低带宽链路时尤其如此。选择信道是发送者的权利，具体取决于应用、文件尺寸、网络结构和与会者的数量。当前的发送者
源文件A和B
MCS提供者
顶级MCS提供者
控制信道
控制信道
-用于的广播数据信道
·-用于的确认数据信道
不需要文件A
或文件B的节点
MCS提供者
所有的节点都连到控制信道和广播数据信道。1
需要文件A
的节点
MCS提供者
2节点必须接收广播数据信道上的文件，不管它们是否需要该数据。需要文件A和
文件B的节点
[MCs 提供者
3如果节点希望接收当前在某条确认数据信道上传送的文件，它们只有加人该信道。图2本标准会议模型
可以达到有选择地向某个会议的部分节点分发文件的目的，方法是创建个专用文件传送会话，或者在现有的会话内建立一个专用文件传送的子会话。子会话遵照与会话相同的模型，它具有一条控制信道、一条或多条数据信道，然而它不同于会话、因为它不一定要求有广播数据信道。子会话与它所属的会话具有相同的能力集。子会话的与会者都选自其所属的会话与会者。子会话在GCC内无状态（变量）且不会出现在GCC-Application-Roster之中。子会话没有独特的会话标识符，只是按主MBFT会话的会话标识符操作。为了避免因注册过程所造成的时延，子会话允许专用交互式文件交换按简便的方式初始化，但同时保护住GCC和MCS资源。为了检索来自数据库、电子布告栏等的信息，特为站点制定了请求其他节点的某份文件的条文。在请求中必须提供足够的信息以使得源站点唯一地标识所需要的文件。子会话与会话间的关系如图3所示。6.1本标准系统模型
如图4所示，下列属性确定了一个MBFT会话的性能。。一条单独的控制信道。
·条单独的广播数据信道。
，零条或多条确认数据信道。
·零个或多个专用子会话（以使某个选定的部分会议与会者能够交换文件）。485
节点A
用户A
应用1
文件APE
控制信道
YD/T949-1998
节点相
用户B
应用！
文件APE
用户B
应用2
文件APE
用户c
应用！
文件APE
多点二进制文件传送了会话
多点一进制文件传送会话
图3子会话与会话间的关系
MBFT会话
MBFT信道资源
播数据
控制信道
个会话标识符。
每个子会话都具有下述属性：
一条单独的专用控制信道。
，零条或-条专用广播数据信道。·零条或多条专用确认数据信道。独占的确认
数据信道
子会话
MBFT信道资源
数据信道
独占的确认
数据信道
可选了会话
图4本标准信道模型
。没有单独的会话ID（使用主MBFT会话的会话ID操作）。486
节点D
用户D
应用1
文件APE
共享的确认
数据通道
其享的确认
数据信道
YD/T949-1998
每条控制信道都有一个与其相关的FILE-REQUEST令牌（除非该信道的创建者要求独占的权力，即只有它能请求来自其他站点的文件）。每条数据信道都有一个与其相关的FILE-TRANSMIT令牌（除非该信道的创建者要求独占的权力，即只有它能在那条信道上传输文件）。6.2压缩
经成功地协商之后，可对文件进行压缩，但在缺省条件下文件是不压缩的。采用ITU建议T.124规定的格式，可以标识出专有技术，如T.35国家码、国内分配的代码、制造商的代码、非标准能力代码，或可用客体标识符替代。通过这种机制也可以标识出事实标准的压缩格式。注意，压缩仅适用于文件数据的净负荷，对文件头不压缩。
6.3优先级
可将本标准作为后台任务去完成批量数据的传送，也可作为前台任务以便及时分发文件。采用哪种方式由发送方选择。快速数据传送时应使用中优先级，批量数据传送时应使用低优先级。在一个文件的传输过程中，优先级应保持不变，但在连续的事务处理之间可以不同。控制信道上的文件事务处理的管理应使用高优先级。6.4文件预传
为了在交互式会议期间把文件传送量减至量少，可以在召集会议时预先将会议使用的资料文件先分发给与会者。这项工作可以是一个自动过程，并且当接收方能够识别哪些文件是它们希望接收的文件时，文件量可以很少。
基本MBFT应用
希望支持文件传送协议的应用必须能加入控制信道，并且能在广播数据信道上发送或接收。表1示出必须支持的协议数据单元。
表1支持的MBFTPDU
MBFTPDU
File-Ofer
File-Accept
File-Reject
File-Request
File-Deny
File-Error
File-Abort
File-Start
File-Data
Directory-Request
Directory-Response
MBFT-NonStandard
MBFT-Privilege-Request
只接收文件的APE
发送PDU
接收PDU
只发送文件的APE
发送PDU
接收PDU
收、发文件的APE
发送PDU
接收PDU
MBFTPDU
MBFT-Privilege-Assign
Private-Channel-Join-Invite
Private-Channel-Join-ResponseM必备的
0可选的
不需要
8操作说明
YD/T949-1998
表1（完）
只接收文件的APE
发送PDU
接收PDU
只发送文件的APE
发送PDU
接收PDU
收、发文件的APE
发送PDU
接收PDU
文件传送用户应用依靠文件传送应用协议实体（文件APE）的服务，与其他节点上对等的应用进行通信。如图5所示，文件APE有两个组成部分：文件传送应用资源管理器（文件ARM）和文件传送应用服务单元（文件ASE）。ARM提供所有标准化的应用协议共有的通用功能。ASE则提供此应用协议的特定功能，使得文件传送应用能够互通。注意，这是一个概念性模型，不包括实际实现时结构上的任何限制。
每个组成部分都将在下面作更详细的介绍。用户应用
节点控制器
传送成用
通用会议控制(GCC)
多点通信服务(MCS）
T.122/T.125
图5本标准应用模型
8.1文件传送用户应用
文件传送
服务单元
Q件ASE
这是文件传送应用的一部分。该部分涉及对互通没有直接影响的诸方面（例如：用户接口），所以这部分可以是产品特定的，也可以是平台特定的。用户应用的影响也仅限于其驻留站点，所以这部分不属488
YD/T949-1998
于本标准的范围。用户应用依靠文件传送应用协议实体（APE）与在其他节点上对等的应用进行通信的服务。它不与MCS或GCC通信，这种通信是由文件APE完成的。用户应用经其文件APE启始一个文件传送会话，并规定该应用的能力和会话方式。一且在建立了会话之后，所有MBFT特定的事务处理均由代表该用户应用的文件APE完成。8.2文件传送应用资源管理器
文件传送应用资源管理器（文件ARM）代表文件ASE管理GCC和MCS。它提供下列服务：·响应来自GCC的指示（如允许注册、调用）。·用GCC注册文件APE。
·连接一个MCS域以便为文件APE获得一个MCS用户ID。加入静态信道。
。使用GCC登记处和MCS去标识和加人组播信道。·召集专用信道并让对等的文件APE进人这样的信道。·加人任何接纳了文件APE的专用信道。·标识并从GCC登记处获得令牌。，从登记处删除与任何已经创建的信道相关联的条目。，调用其他节点上对等的文件APE。·处理应用名册报告，以便确定所协商的应用能力清单和对等文件APE的标识。8.3文件传送应用服务单元
文件传送应用服务单元（文件ASE）向具有资源（由文件ARM获得）的用户应用提供文件传送功能。其操作与传给它的令牌和信道的类型（即静态的或动态的）以及标识无关。用户应用规定需要的是广播数据信道还是确认数据信道。向会议的部分与会者的专用传送，则需要MBFT用户ID清单。文件ASE提供下列服务：
·发送和接收MBFTPDU。
·获取和释放令牌并使用MCS确定令牌状态。·对GCC-Conductor-Assign和Release指示作出响应。·通过节点控制器发出GCC-Conductor-Permission-Ask请求。，对GCC-Conductor-Permission-Grant指示作出响应。8.4MBFT资源
二进制文件传送会话使用控制信道来管理文件传送，使用数据信道来分发文件。每条控制信道都有一条或多条与其相关的数据信道，每条数据信道都支持每次传送一份文件。每个MBFT会话都有一条会议控制信道（分派的助记符是MBFT-CONTROL）和一条广播数据信道（分派的助记符是MBFT-DATA）。这两条信道是所有该会话的应用与会者都必须加人的。控制信道用于管理所有在广播数据信道上的文件传送。所有的节点都同意接收在广播数据信道上传送的文件，并在不需要时丢弃这些文件。只要任何一个节点处于低带宽链路上且不需要这些数据时，就将导致会议性能不必要的降低。
使用确认数据信道（分派的助记符是MBFT-DATA（n），其中n为此数据信道的MCS信道ID）时，允许同时分发一份以上的文件。对这样的信道上文件传送的管理是通过会话控制信道完成的。但在这种情况下，节点有拒绝向其提供文件的权利。这样便可保证文件只分发给那些需要这些文件的节点，但每次文件传送都需要一些额外的开销。可以通过开辟子会话的办法，实现有选择地向一个已有会话的部分与会者分发文件。这包括一条专用子会话控制信道（分派的助记符是MBFT-CONTROL（p），其中p为该控制信道的MCS信道ID）。此办法适用于在零条或1条专用广播数据信道（分派的助记符是MBFT-DATA（p），其中P是该数据信道的MCS信道ID）和零条或多条专用确认数据信道（分派的助记符是MBFT-DATA（n），其中n是该数489
YD/T949--1998
据信道的MCS信道ID)上的文件事务处理。每条专用子会话都需要一条独立的专用控制信道。每条控制信道都可能有个FILE-REQUEST令牌，此令牌用于保证任意时刻在那条信道上最多只有一份未决的文件请求，需要某份文件的文件ASE在提出请求之前必须获取此令牌，并将其保持到它确定了另一个节点是否能够提供该文件。允许动态控制信道没有FILE-REQUEST令牌，但此时只有该信道的创建者才能在该信道上发送文件请求。分派给会话控制信道MBFT-CONTROL令牌的助记符是FILE-REQUEST；分派给子会话控制信道MBFT-CONTROL（P）令牌的助记符是FILEREQUEST(p)。
每条数据信道都可能有一个FILE-TRANSMIT令牌，此令牌用于保证任意时刻在那条信道上仅有一份文件在传送。发送的文件ASE在提供一份供传送的文件之前需获取此令牌，并在该文件传送期间内保留此令牌，在发出最后块文件数据之后释放此令牌。允许动态数据信道没有FILETRANSMIT令牌，但此时只有该信道的创建者才能在该信道上发送文件。分派给会话广播数据信道MBFT-DATA令牌的助记符是FILE-TRANSMIT，分派给子会话广播数据信道MBFT-DATA（p）令牌的助记符是FILE-TRANSMIT（p），分派给确认数据信道MBFT-DATA（n）令牌的助记符是FILETRANSMIT(n)。
这些信道和令牌一起组成了MBFT会话的可用资源：它们可以是静态的，也可以是动态的。文件传送应用资源管理器（文件ARM）的责任就是确定这些资源的标识。对于任何给定的文件事务处理，用户应用必须规定由文件ASE使用的资源。静态和动态资源都由文件ASE同样处理。8.4.1MBFT初始化
在本地通过某个用户应用或在远端使用GCC-Application-Invoke机制都可以将一个MBFT会话初始化。在这两种情况下，将示于表2中的参数传给文件ARM。会话方式确定了该文件ARM所采取的动作，该动作旨在标识该会话初始使用的一组资源。表2文件APE参数
会话方式
会话ID
此参数可为以下3个值之一：
静态的：此值表示该文件APE应使用由MBFT客体标识符和该会话ID参数组成的会话键注册。它应使用静态的预先规定的MBFT-CONTROL和MBFT-DATA信道以及静态的FILE-TRANSMIT和FILE-REQUEST令牌动态的：此值表示该文件APE应使用由MBFT客体标识符和该会话ID参数组成的会话键注册。所有的信道和令牌资源都是动态的，且由该组播会话的创建者分别使用MCSCHANNEL-JOIN机制和GCC登记处机制予以分派。组播会话的成员通过GCC登记处确定令牌和信道ids。
动态专用：此值表示该文件APE应使用由MBFT客体标识符和该会话ID参数组成的会话键注册。
所有的令牌和信道资源都是动态的，且由该专用召集者文件ARM分别使用GCC登记处机制和MCS-CHANNEL-CONVENE机制予以分派。然后，创建该会话的文件ARM把所有对等文件APE接纳到MBFT-CONTROL和MBFT-DATA信道，文件APE的MCS用户ids出现在接纳清单协议参数中。在企图加入专用MCS信道之前，专用成员文件ARM必须等待其文件APE被专用MCS信道召集者承认。令牌的标识由信道召集者在第一次事务处理时于带内传送此参数用于区分该协议的多个会话所使用的资源，且这些资源可能同时存在于同MCS域中。分派给该MBFT-CONTROL信道的MCS信道ID被用作该会话ID，这样便可保证在该会议域中它是唯一的。如果应用希望参与某个静态会话或者参与某个现有的组播或专用会话，则必须规定该会话ID
接纳清单
YD/T949-1998
表2（完）
会话方式一专用，并且省略会话ID。明
GCC用户ID清单，它相应于被接纳到所召集的专用信道的文件APE所在的那些节若不是则省略撑免费标准bzxz.net
静态方式（Staticmode）用于向会议不限制地广播数据。在使用预先规定的静态信道和令牌时，它是一种最简单的操作方式。应用可以随意加人和撤离某个静态方式的会话。尽管使用静态信道和令牌的不同子集的其他应用协议可以使用该文件ASE，但却只有一种静态方式的文件ARM是本标准预先规定的。
组播方式（Multicastmode）能够在静态会话已经启用后用于广播数据。在功能上它与静态方式相同，但它使用的是动态资源，所以必须经GCC登记处和MCS服务由组播会话的创建者（被称为组播创建者）来分派信道和令牌标识。所有其他与会者（组播成员）都可经该GCC登记处确定信道和令牌ids。应用可随意加入和撤离某个组播会话。在一次会议中的组播方式会话数目也是没有限制的。专用方式（privatemode）用于有选择地向部分与会者分发文件。文件ARM的责任是：启动专用会话（被称为专用召集者）以便分别使用GCC和MCS获得令牌和信道，并将对等文件APE（专用会员接纳到这些信道。令牌的标识在带内传送，但也可以经CCC登记处确定。一次会议中的专用方式会活数目是没有限制的。专用成员文件ARM必须等待其文件APE被专用信道接纳，还要等待召集者分派该会话应使用的令牌，一旦召集者撤离了该专用会话，则所有的其他与会者也便被排除了。应用仅在受到会话召集者邀请时才能加人该专用会话。在所有情况下，启始的一组资源允许每次传送一份文件。同时传送多份文件的情况请参见8.6。为了使某个文件APE与那个节点的GCC提供者通信，以任何方式创建的该文件APE都必须首先建立GCC-SAP（GCC服务接入点）。当节点加入某次会议时，该GCC提供者将发出准许/撤消标志置于准许的GCC-Application-Permission-to-Enroll。无论那时该用户应用是否希望注册，该文件ARM都必须发出GCC-Application-Enroll请求。如果该用户应用不希望注册，则该文件ARM必须将GCC-Application-Enroll请求中的注册/未注册标志置于未注册，并且指定该会议ID。不需要其他参数。此后，只要不是接收到准许/撤消标志置于撤消的GCC-Application-Permission-to-Enroll指示撤消了允许条件，该应用可以随时注册。如果用户应用在决定加人某个会话之前希望接收有关正在进行的所有MBFT会话的GCC-Application-Roster-Reports，则该文件ARM可以注册非激活，指定会话键没有会话ID。如果用户应用希望声明支持该MBFT协议但不消耗MCS资源，则该文件ARM可以注册非激活（没有MCS用户ID)。
当用户应用经过激活的注册之后，文件ARM应向MCS提供者发出MCS-Attach-User请求，此时使用GCC-Application-Permission-to-Enroll指示中包括的该会话ID作为该域选择符。在接收到连续的MCS-Attach-User证实的响应后，该文件ARM应加入发出MCS-Channel-Join请求时所指定的用户ID信道。
8.4.2静态方式
在得到MCS用户ID之后，文件ARM应加人MBFT静态控制和数据信道，方法是发送两个MCSChannel-Join请求，指定MBFT-CHANNEL-O和MBFT-CHANNEL-1为各自加人的信道。在接收到加入这些信道的肯定的证实之后，该文件ARM将注册激活，方法是向GCC提供者发出GCC-ApplicationEnroll请求，其具体参数在表3中指定。激活/非激活标志应被置为激活，会话ID应指定为部分会话键，启始信道应指定为静态的，且必须提供整个的应用能力清单。参见图6。491
会议ID
会话键
文件APE
YD/T9491998
GCC提供者MCS提供者MCS提供者
GCC-Applieation-Pemission-To-Enroil指示MCS-ATTACH-USER请求
MCS-ATTACH-USER 证实 [MBFT用户ID=独特的、薪的]MCS-CHANNEL-JOIN请求[信道|IDMBFT用户ID]]MCS-CHANNELJOIN 证实
MCS-ATTACH-USER请求【信道D-MBFT-信道-0]MCS-CHANNEL-JOIN证实
MCS-ATTACH-USER请求【信道D+MBFT-信道-1]MCS-CHANNELJQIN证实
GCC-Appliocation-Enroll请求【激活、会话ID】GCC-Application-Enjoll 证实
GCC-Application-Roster-Repont指示远端
GCC提供者
文件APEs）操作
获得MBFT用户ID
MBFT-CONTROL
MBFT-DATA
注册激活
GCC-Applicaion-Roster-Repori 指示TO8210120-95/d06
图6静态会话协议初始序列
表3适用于GCC-Application-Enroll请求的参数数
应用用户ID
激活/非激活
管理的操作标志
启始信道
非拆装的能力清单
应用能力清单
注册/未注册
8.4.3组播方式
由GCC-Application-Permission-To-Enroll指示提供(ITU建议T：127版本（0)I和MBFT-SESSION-ID（若此文件APE参数曾规定过）
由MCS-Attach-User证实提供
激活，条件是指示出文件ARM已经加人了MBFT-CONTROL和MBFT-DATA信道，并且确定了任何需要的MBFT令牌IDS。在组播或者专用方式情况下，非激活。条件是在加人MBFT-CONTROL和MBFT-DATA信道之前注册了置位，条件是在管理方式下，文件APE能够成为会话MBFT的管理者，也就是它能够响应MBFT-Privilege-RequestPDUs。当激活/非激活标志置为非激活时，则此标志不置位此参数取决于表2中规定的文件APE参数。静态的，若会话方式一静态。
动态组播，若会话方式一动态组播且省略会话ID。动态专用，若会话方式一动态专用且省略会话ID。若都不是，则省略
本协议不规定非拆装能力。这个字段可包括由用户应用规定的非标准非拆装能力见表7,若激活/非激活标志置为非激活则省略注册
在获得MCS用户ID之后，为了确定文件ARM是（作为一名组播成员）参加了现有的组播会话，还是（作为一名组播创建者）去创建-个新的组播会话，该文件ARM应审查文件APE会话ID参数。如果给出了会话ID参数，该文件ARM应通过发送GCC-Application-Enroll请求来尝试加人该会话，该请求中激活/非激活标志置为非激活，并且使用不可缺少的会话ID指定会话键。然后，它应发送MCS-Channel-Join请求，指定选定了会话的那个会话ID作为该信道ID参数。这条信道被用作MBFTCONTROL信道。再后，该文件ARM必须标识并加人MBFT-DATA信道，方法是使用表4中给定的492
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。
本标准等效采用ITU-T建议T.127（1995年版本）《用于音像和视听会议业务的多点通信服务》。该建议是有关音像和视听会议业务的多点通信的应用协议和服务的ITU-T.120系列建议之一。本标准定义了一个协议，旨在支持交互式会议或群工作环境下的二进制文件数据的互换。在该环境中使用T.120系列标准。它提供的机制可支持同时分发多份文件，可选择向部分与会者分发文件和由远端检索文件。制定的条款也适用于远程目录访问。本标准的附录A和附录B是标准的附录，附录C和附录D是提示的附录。本标准由原邮电部电信科学研究规划院提出并归口。本标准由原邮电部数据通信技术研究所负责起草。本标准主要起草人：张勇。
1范围
中华人民共和国通信行业标准
多点二进制文件传送协议
MultipointbinaryfiletransferprotocolYD/T949---1998
eqvITU-TT.127:1995
本标准定义了一个协议，旨在支持交互式会议或群工作环境下的二进制文件的互换。在该环境中使用T.120系列标准。它提供的机制是：使用T.122（多点通信服务）所提供的原语，可方便地同时分发和检索一份或多份文件。本标准的设计目标是提供一个多用途的简便协议，该协议可为要求基本文件传送能力的应用之间互通提供核心功能，同时该协议也有满足更复杂的应用需求的灵活性，参见图1。用广应用（采用标准和非标准应用协议）用户应用
（采用标准应用协议）
T.126静止图像（SD)
节点控制器
通用会议控制(GCC)
多点通信服务（MCS）
T.122/T.125
网络特定的运输协议
图1本标准的适用范围
2引用标准
用户应用
（采用非标准协议）
非标准应用协议实体
下列标准和其他参考资料所包含的条文，通过在本标准中引用而构成为本标准的条文，本标准出版时，所示版本均为有效。这些标准和其他参考资料都会被修订，使用本标准的各方应探讨使用下列标准和其他参考资料最新版本的可能性。CCITT建议T.35（1991）CCITT成员代码的分派规程（非标准设备）中华人民共和国信息产业部1998-07-14批准482
1999-01-01实施
ITU-T建议T.120(199X）
ITU-T建议T.122(1993)
ITU-T建议T.123(1994)
ITU-T建议T.124(1995)
ITU-T建议T.125(1994)
ITU-T建议T.434(1992)
ITU-T建议H.221（1993)
ITU建议X.680(1994)
YD/T949--1998
多媒体会议电话的数据协议
音像和视听会议的多点通信服务的服务定义音像和视听会议应用的协议栈
通用会议控制
多点通信服务协议规范
用于远程信息处理服务的二进制文件传送格式在视听远程服务中用于64~1920kbit/s信道的赖结构信息技术—抽象句法表记法-（ASN.1)基本表记法规范ITU-T建议X.691（1995)
ITU-T建议V.42bis(1990)
信息技术-ASN.1编码规则压缩编码规则（PER）的规范采用纠错规程的数据电路终接设备(DCE)使用的数据压缩规程ISO/IEC3309（1993）信息技术一系统间通信和信息交换-高级数据链路控制（HDLC)规程顿结构
信息处理系统开放系统互连——文件传送、访问和管理（FTAM）-第ISO8571-2(1988）
二部分：虚拟文件存储定义
3定义
确认数据信道：一种多点通信服务信道，在该信道上可分发文件。与会者对确认数据信道上所提供的文件有拒绝的选择权。确认数据信道可以是独占的（即只有信道的创建者可以在该信道上发送文件），也可以是共享的（任何与会者都可在该信道上发送文件）。广播数据信道：一一种多点通信服务信道。在该信道上可分发文件。与会者必须接收在该信道上分发的所有文件；如果哪个与会者不需要，剿在本地予以丢弃。控制信道：一种多点通信服务信道，用于管理文件的事务处理。文件属性：一份文件的文件名和其他可标识的特性。FILE-REQUEST：一种令牌，用于保证在会话控制信道MBFT-CONTROL上最多有一个未决的文件请求。
FILE-REQUEST（P）：一种令牌，用于保证在子会话控制信道MBFT-CONTROL（P）上最多有~个未决的文件请求。
FILE-TRANSMIT：一种令牌，用于保证在会话广播数据信道MBFT-DATA上最多有-个正在进行的文件传送。
FILE-TRANSMIT（p）：一种令牌，用于保证在子会话广播数据信道MBFT-DATA（P）上最多有一个正在进行的文件传送。
FILE-TRANSMIT（n）：一种令牌，用于保证在确认数据信道MBFT-DATA（n）上最多有一个正在进行的文件传送。
MBFT-CONTROL：会话控制信道。MBFT-CONTROL(p）：子会话控制信道，其MCS信道ID是P。MBFT-DATA：会话广播数据信道。MBFT-DATA（p）：子会话广播数据信道，其MCS信道ID是P。MBFT-DATA（n）：确认数据信道，其MCS信道ID是n。非标准能力：本标准范围之外的一种能力，在使用非标准能力之前必须协商。会话：一组对等的应用协议实体。标准能力：本标准范围内定义的一种能力，但并非所有MBFT的实现都需要这种能力。所以在使用标准能力之前必须协商。
子会话：在一个会话内对等的应用协议实体的一个子群。483
4缩略语
GCCSAP
应用资源管理器
应用协议实体
应用服务单元
通用会议控制
YD/T949-1998
通用会议控制的服务接入点
多点二进制文件传送
多点通信服务
多点通信服务的服务接入点
协议数据单元
5多点文件传送简介
为了支持不在一地的与会者进行会谈、会议等活动，需要将两个或多个地方连接起来。术语多点通信就是描述了多个终端的互连。多点二进制文件传送（MBFT)在多点环境下通过使用与基础网络无关的多点通信服务（MCS），使与会者之间能够进行交互式的文件交换。特别是本标准提供灵活有效的机制支持：。同时分发多份文件
·向会议的全体与会者广播文件：向部分与会者有选择地分发文件·从远端站点检索文件
。中断之后文件部分重传
·远程目录访问
6数据的多点传送
为了便于同时传送一份或多份二进制文件，本标准采用了一种控制和数据信道体系结构，见图2它使文件能够向会议的所有与会者广播，或者作为一种专用文件传送有选择地向部分站点传送。对所传送的数据类型没有限制。
本标准中采用了两种类型的信道：控制信道和数据信道。控制信道用于对文件传送的各方面实施管理（提供文件，请求文件），而数据信道则用于传送文件数据。在每条数据信道上，某一时刻仅能传送一份文件。但能采用附加的数据信道同时分发多份文件。在任何给定的时间内，使用的数据信道数目取决于要同时传送的文件数。
相互通信的一组文件传送应用被称为参与同一文件传送的会话。每个文件传送的会话都要求一条单独的控制信道和一条或多条数据信道，用于向所有与会应用分发文件。本标准支持两种类型的数据信道：广播和确认数据信道。如果某个发送者希望所有的节点都接收它提供的某份文件，那么它应采用广播数据信道。在该文件传送的会话期内，所有的节点都必须处于广播数据信道下并接收信道上分发的所有文件；如果某份文件是不需要的，则应由接收者予以丢弃。如果发送者希望给予其他节点可拒绝某份文件的选择权，则它应在确认数据信道上传送该文件。在这种情况下，每个节点都必须告知发送者它是否需要该份文件。这时只有那些希望获得该份文件的节点才加入数据信道。通过使用确认数据信道可支持多份文件的同时传送。如果发送者认为文件头中的一个或多个参数是该应用操作的必不可少的参数，则应使用确认数据信道。比如，某个应用可能要求由接收者保留某个通路名以供将来引用。当将该文件提供分发时，应标识键参数，此时那些不能够支持所有这样的参数的节点必须拒绝该文件。484
YD/T949--1998
确认数据信道的创建者可被指定是独占的（即只有创建者可在该信道上发送文件），或者是共享的（即任何与会者都可以在该信道上发送文件）。当节点都必须在广播信道上接收分发的所有文件时，该信道上的文件事务处理不要求发送者和接收者有任何联络过程，使得在广播数据信道进行事务处理时的启始文件传送的等待时间减至最小。在确认数据信道上的事务处理会在启始一份文件传送时引起某些等待时间。但是，由于避免了向不要求数据的站点分发不需要的数据，总体性能可能会更好。特别是当这样的站点是处于低带宽链路时尤其如此。选择信道是发送者的权利，具体取决于应用、文件尺寸、网络结构和与会者的数量。当前的发送者
源文件A和B
MCS提供者
顶级MCS提供者
控制信道
控制信道
-用于的广播数据信道
·-用于的确认数据信道
不需要文件A
或文件B的节点
MCS提供者
所有的节点都连到控制信道和广播数据信道。1
需要文件A
的节点
MCS提供者
2节点必须接收广播数据信道上的文件，不管它们是否需要该数据。需要文件A和
文件B的节点
[MCs 提供者
3如果节点希望接收当前在某条确认数据信道上传送的文件，它们只有加人该信道。图2本标准会议模型
可以达到有选择地向某个会议的部分节点分发文件的目的，方法是创建个专用文件传送会话，或者在现有的会话内建立一个专用文件传送的子会话。子会话遵照与会话相同的模型，它具有一条控制信道、一条或多条数据信道，然而它不同于会话、因为它不一定要求有广播数据信道。子会话与它所属的会话具有相同的能力集。子会话的与会者都选自其所属的会话与会者。子会话在GCC内无状态（变量）且不会出现在GCC-Application-Roster之中。子会话没有独特的会话标识符，只是按主MBFT会话的会话标识符操作。为了避免因注册过程所造成的时延，子会话允许专用交互式文件交换按简便的方式初始化，但同时保护住GCC和MCS资源。为了检索来自数据库、电子布告栏等的信息，特为站点制定了请求其他节点的某份文件的条文。在请求中必须提供足够的信息以使得源站点唯一地标识所需要的文件。子会话与会话间的关系如图3所示。6.1本标准系统模型
如图4所示，下列属性确定了一个MBFT会话的性能。。一条单独的控制信道。
·条单独的广播数据信道。
，零条或多条确认数据信道。
·零个或多个专用子会话（以使某个选定的部分会议与会者能够交换文件）。485
节点A
用户A
应用1
文件APE
控制信道
YD/T949-1998
节点相
用户B
应用！
文件APE
用户B
应用2
文件APE
用户c
应用！
文件APE
多点二进制文件传送了会话
多点一进制文件传送会话
图3子会话与会话间的关系
MBFT会话
MBFT信道资源
播数据
控制信道
个会话标识符。
每个子会话都具有下述属性：
一条单独的专用控制信道。
，零条或-条专用广播数据信道。·零条或多条专用确认数据信道。独占的确认
数据信道
子会话
MBFT信道资源
数据信道
独占的确认
数据信道
可选了会话
图4本标准信道模型
。没有单独的会话ID（使用主MBFT会话的会话ID操作）。486
节点D
用户D
应用1
文件APE
共享的确认
数据通道
其享的确认
数据信道
YD/T949-1998
每条控制信道都有一个与其相关的FILE-REQUEST令牌（除非该信道的创建者要求独占的权力，即只有它能请求来自其他站点的文件）。每条数据信道都有一个与其相关的FILE-TRANSMIT令牌（除非该信道的创建者要求独占的权力，即只有它能在那条信道上传输文件）。6.2压缩
经成功地协商之后，可对文件进行压缩，但在缺省条件下文件是不压缩的。采用ITU建议T.124规定的格式，可以标识出专有技术，如T.35国家码、国内分配的代码、制造商的代码、非标准能力代码，或可用客体标识符替代。通过这种机制也可以标识出事实标准的压缩格式。注意，压缩仅适用于文件数据的净负荷，对文件头不压缩。
6.3优先级
可将本标准作为后台任务去完成批量数据的传送，也可作为前台任务以便及时分发文件。采用哪种方式由发送方选择。快速数据传送时应使用中优先级，批量数据传送时应使用低优先级。在一个文件的传输过程中，优先级应保持不变，但在连续的事务处理之间可以不同。控制信道上的文件事务处理的管理应使用高优先级。6.4文件预传
为了在交互式会议期间把文件传送量减至量少，可以在召集会议时预先将会议使用的资料文件先分发给与会者。这项工作可以是一个自动过程，并且当接收方能够识别哪些文件是它们希望接收的文件时，文件量可以很少。
基本MBFT应用
希望支持文件传送协议的应用必须能加入控制信道，并且能在广播数据信道上发送或接收。表1示出必须支持的协议数据单元。
表1支持的MBFTPDU
MBFTPDU
File-Ofer
File-Accept
File-Reject
File-Request
File-Deny
File-Error
File-Abort
File-Start
File-Data
Directory-Request
Directory-Response
MBFT-NonStandard
MBFT-Privilege-Request
只接收文件的APE
发送PDU
接收PDU
只发送文件的APE
发送PDU
接收PDU
收、发文件的APE
发送PDU
接收PDU
MBFTPDU
MBFT-Privilege-Assign
Private-Channel-Join-Invite
Private-Channel-Join-ResponseM必备的
0可选的
不需要
8操作说明
YD/T949-1998
表1（完）
只接收文件的APE
发送PDU
接收PDU
只发送文件的APE
发送PDU
接收PDU
收、发文件的APE
发送PDU
接收PDU
文件传送用户应用依靠文件传送应用协议实体（文件APE）的服务，与其他节点上对等的应用进行通信。如图5所示，文件APE有两个组成部分：文件传送应用资源管理器（文件ARM）和文件传送应用服务单元（文件ASE）。ARM提供所有标准化的应用协议共有的通用功能。ASE则提供此应用协议的特定功能，使得文件传送应用能够互通。注意，这是一个概念性模型，不包括实际实现时结构上的任何限制。
每个组成部分都将在下面作更详细的介绍。用户应用
节点控制器
传送成用
通用会议控制(GCC)
多点通信服务(MCS）
T.122/T.125
图5本标准应用模型
8.1文件传送用户应用
文件传送
服务单元
Q件ASE
这是文件传送应用的一部分。该部分涉及对互通没有直接影响的诸方面（例如：用户接口），所以这部分可以是产品特定的，也可以是平台特定的。用户应用的影响也仅限于其驻留站点，所以这部分不属488
YD/T949-1998
于本标准的范围。用户应用依靠文件传送应用协议实体（APE）与在其他节点上对等的应用进行通信的服务。它不与MCS或GCC通信，这种通信是由文件APE完成的。用户应用经其文件APE启始一个文件传送会话，并规定该应用的能力和会话方式。一且在建立了会话之后，所有MBFT特定的事务处理均由代表该用户应用的文件APE完成。8.2文件传送应用资源管理器
文件传送应用资源管理器（文件ARM）代表文件ASE管理GCC和MCS。它提供下列服务：·响应来自GCC的指示（如允许注册、调用）。·用GCC注册文件APE。
·连接一个MCS域以便为文件APE获得一个MCS用户ID。加入静态信道。
。使用GCC登记处和MCS去标识和加人组播信道。·召集专用信道并让对等的文件APE进人这样的信道。·加人任何接纳了文件APE的专用信道。·标识并从GCC登记处获得令牌。，从登记处删除与任何已经创建的信道相关联的条目。，调用其他节点上对等的文件APE。·处理应用名册报告，以便确定所协商的应用能力清单和对等文件APE的标识。8.3文件传送应用服务单元
文件传送应用服务单元（文件ASE）向具有资源（由文件ARM获得）的用户应用提供文件传送功能。其操作与传给它的令牌和信道的类型（即静态的或动态的）以及标识无关。用户应用规定需要的是广播数据信道还是确认数据信道。向会议的部分与会者的专用传送，则需要MBFT用户ID清单。文件ASE提供下列服务：
·发送和接收MBFTPDU。
·获取和释放令牌并使用MCS确定令牌状态。·对GCC-Conductor-Assign和Release指示作出响应。·通过节点控制器发出GCC-Conductor-Permission-Ask请求。，对GCC-Conductor-Permission-Grant指示作出响应。8.4MBFT资源
二进制文件传送会话使用控制信道来管理文件传送，使用数据信道来分发文件。每条控制信道都有一条或多条与其相关的数据信道，每条数据信道都支持每次传送一份文件。每个MBFT会话都有一条会议控制信道（分派的助记符是MBFT-CONTROL）和一条广播数据信道（分派的助记符是MBFT-DATA）。这两条信道是所有该会话的应用与会者都必须加人的。控制信道用于管理所有在广播数据信道上的文件传送。所有的节点都同意接收在广播数据信道上传送的文件，并在不需要时丢弃这些文件。只要任何一个节点处于低带宽链路上且不需要这些数据时，就将导致会议性能不必要的降低。
使用确认数据信道（分派的助记符是MBFT-DATA（n），其中n为此数据信道的MCS信道ID）时，允许同时分发一份以上的文件。对这样的信道上文件传送的管理是通过会话控制信道完成的。但在这种情况下，节点有拒绝向其提供文件的权利。这样便可保证文件只分发给那些需要这些文件的节点，但每次文件传送都需要一些额外的开销。可以通过开辟子会话的办法，实现有选择地向一个已有会话的部分与会者分发文件。这包括一条专用子会话控制信道（分派的助记符是MBFT-CONTROL（p），其中p为该控制信道的MCS信道ID）。此办法适用于在零条或1条专用广播数据信道（分派的助记符是MBFT-DATA（p），其中P是该数据信道的MCS信道ID）和零条或多条专用确认数据信道（分派的助记符是MBFT-DATA（n），其中n是该数489
YD/T949--1998
据信道的MCS信道ID)上的文件事务处理。每条专用子会话都需要一条独立的专用控制信道。每条控制信道都可能有个FILE-REQUEST令牌，此令牌用于保证任意时刻在那条信道上最多只有一份未决的文件请求，需要某份文件的文件ASE在提出请求之前必须获取此令牌，并将其保持到它确定了另一个节点是否能够提供该文件。允许动态控制信道没有FILE-REQUEST令牌，但此时只有该信道的创建者才能在该信道上发送文件请求。分派给会话控制信道MBFT-CONTROL令牌的助记符是FILE-REQUEST；分派给子会话控制信道MBFT-CONTROL（P）令牌的助记符是FILEREQUEST(p)。
每条数据信道都可能有一个FILE-TRANSMIT令牌，此令牌用于保证任意时刻在那条信道上仅有一份文件在传送。发送的文件ASE在提供一份供传送的文件之前需获取此令牌，并在该文件传送期间内保留此令牌，在发出最后块文件数据之后释放此令牌。允许动态数据信道没有FILETRANSMIT令牌，但此时只有该信道的创建者才能在该信道上发送文件。分派给会话广播数据信道MBFT-DATA令牌的助记符是FILE-TRANSMIT，分派给子会话广播数据信道MBFT-DATA（p）令牌的助记符是FILE-TRANSMIT（p），分派给确认数据信道MBFT-DATA（n）令牌的助记符是FILETRANSMIT(n)。
这些信道和令牌一起组成了MBFT会话的可用资源：它们可以是静态的，也可以是动态的。文件传送应用资源管理器（文件ARM）的责任就是确定这些资源的标识。对于任何给定的文件事务处理，用户应用必须规定由文件ASE使用的资源。静态和动态资源都由文件ASE同样处理。8.4.1MBFT初始化
在本地通过某个用户应用或在远端使用GCC-Application-Invoke机制都可以将一个MBFT会话初始化。在这两种情况下，将示于表2中的参数传给文件ARM。会话方式确定了该文件ARM所采取的动作，该动作旨在标识该会话初始使用的一组资源。表2文件APE参数
会话方式
会话ID
此参数可为以下3个值之一：
静态的：此值表示该文件APE应使用由MBFT客体标识符和该会话ID参数组成的会话键注册。它应使用静态的预先规定的MBFT-CONTROL和MBFT-DATA信道以及静态的FILE-TRANSMIT和FILE-REQUEST令牌动态的：此值表示该文件APE应使用由MBFT客体标识符和该会话ID参数组成的会话键注册。所有的信道和令牌资源都是动态的，且由该组播会话的创建者分别使用MCSCHANNEL-JOIN机制和GCC登记处机制予以分派。组播会话的成员通过GCC登记处确定令牌和信道ids。
动态专用：此值表示该文件APE应使用由MBFT客体标识符和该会话ID参数组成的会话键注册。
所有的令牌和信道资源都是动态的，且由该专用召集者文件ARM分别使用GCC登记处机制和MCS-CHANNEL-CONVENE机制予以分派。然后，创建该会话的文件ARM把所有对等文件APE接纳到MBFT-CONTROL和MBFT-DATA信道，文件APE的MCS用户ids出现在接纳清单协议参数中。在企图加入专用MCS信道之前，专用成员文件ARM必须等待其文件APE被专用MCS信道召集者承认。令牌的标识由信道召集者在第一次事务处理时于带内传送此参数用于区分该协议的多个会话所使用的资源，且这些资源可能同时存在于同MCS域中。分派给该MBFT-CONTROL信道的MCS信道ID被用作该会话ID，这样便可保证在该会议域中它是唯一的。如果应用希望参与某个静态会话或者参与某个现有的组播或专用会话，则必须规定该会话ID
接纳清单
YD/T949-1998
表2（完）
会话方式一专用，并且省略会话ID。明
GCC用户ID清单，它相应于被接纳到所召集的专用信道的文件APE所在的那些节若不是则省略撑免费标准bzxz.net
静态方式（Staticmode）用于向会议不限制地广播数据。在使用预先规定的静态信道和令牌时，它是一种最简单的操作方式。应用可以随意加人和撤离某个静态方式的会话。尽管使用静态信道和令牌的不同子集的其他应用协议可以使用该文件ASE，但却只有一种静态方式的文件ARM是本标准预先规定的。
组播方式（Multicastmode）能够在静态会话已经启用后用于广播数据。在功能上它与静态方式相同，但它使用的是动态资源，所以必须经GCC登记处和MCS服务由组播会话的创建者（被称为组播创建者）来分派信道和令牌标识。所有其他与会者（组播成员）都可经该GCC登记处确定信道和令牌ids。应用可随意加入和撤离某个组播会话。在一次会议中的组播方式会话数目也是没有限制的。专用方式（privatemode）用于有选择地向部分与会者分发文件。文件ARM的责任是：启动专用会话（被称为专用召集者）以便分别使用GCC和MCS获得令牌和信道，并将对等文件APE（专用会员接纳到这些信道。令牌的标识在带内传送，但也可以经CCC登记处确定。一次会议中的专用方式会活数目是没有限制的。专用成员文件ARM必须等待其文件APE被专用信道接纳，还要等待召集者分派该会话应使用的令牌，一旦召集者撤离了该专用会话，则所有的其他与会者也便被排除了。应用仅在受到会话召集者邀请时才能加人该专用会话。在所有情况下，启始的一组资源允许每次传送一份文件。同时传送多份文件的情况请参见8.6。为了使某个文件APE与那个节点的GCC提供者通信，以任何方式创建的该文件APE都必须首先建立GCC-SAP（GCC服务接入点）。当节点加入某次会议时，该GCC提供者将发出准许/撤消标志置于准许的GCC-Application-Permission-to-Enroll。无论那时该用户应用是否希望注册，该文件ARM都必须发出GCC-Application-Enroll请求。如果该用户应用不希望注册，则该文件ARM必须将GCC-Application-Enroll请求中的注册/未注册标志置于未注册，并且指定该会议ID。不需要其他参数。此后，只要不是接收到准许/撤消标志置于撤消的GCC-Application-Permission-to-Enroll指示撤消了允许条件，该应用可以随时注册。如果用户应用在决定加人某个会话之前希望接收有关正在进行的所有MBFT会话的GCC-Application-Roster-Reports，则该文件ARM可以注册非激活，指定会话键没有会话ID。如果用户应用希望声明支持该MBFT协议但不消耗MCS资源，则该文件ARM可以注册非激活（没有MCS用户ID)。
当用户应用经过激活的注册之后，文件ARM应向MCS提供者发出MCS-Attach-User请求，此时使用GCC-Application-Permission-to-Enroll指示中包括的该会话ID作为该域选择符。在接收到连续的MCS-Attach-User证实的响应后，该文件ARM应加入发出MCS-Channel-Join请求时所指定的用户ID信道。
8.4.2静态方式
在得到MCS用户ID之后，文件ARM应加人MBFT静态控制和数据信道，方法是发送两个MCSChannel-Join请求，指定MBFT-CHANNEL-O和MBFT-CHANNEL-1为各自加人的信道。在接收到加入这些信道的肯定的证实之后，该文件ARM将注册激活，方法是向GCC提供者发出GCC-ApplicationEnroll请求，其具体参数在表3中指定。激活/非激活标志应被置为激活，会话ID应指定为部分会话键，启始信道应指定为静态的，且必须提供整个的应用能力清单。参见图6。491
会议ID
会话键
文件APE
YD/T9491998
GCC提供者MCS提供者MCS提供者
GCC-Applieation-Pemission-To-Enroil指示MCS-ATTACH-USER请求
MCS-ATTACH-USER 证实 [MBFT用户ID=独特的、薪的]MCS-CHANNEL-JOIN请求[信道|IDMBFT用户ID]]MCS-CHANNELJOIN 证实
MCS-ATTACH-USER请求【信道D-MBFT-信道-0]MCS-CHANNEL-JOIN证实
MCS-ATTACH-USER请求【信道D+MBFT-信道-1]MCS-CHANNELJQIN证实
GCC-Appliocation-Enroll请求【激活、会话ID】GCC-Application-Enjoll 证实
GCC-Application-Roster-Repont指示远端
GCC提供者
文件APEs）操作
获得MBFT用户ID
MBFT-CONTROL
MBFT-DATA
注册激活
GCC-Applicaion-Roster-Repori 指示TO8210120-95/d06
图6静态会话协议初始序列
表3适用于GCC-Application-Enroll请求的参数数
应用用户ID
激活/非激活
管理的操作标志
启始信道
非拆装的能力清单
应用能力清单
注册/未注册
8.4.3组播方式
由GCC-Application-Permission-To-Enroll指示提供(ITU建议T：127版本（0)I和MBFT-SESSION-ID（若此文件APE参数曾规定过）
由MCS-Attach-User证实提供
激活，条件是指示出文件ARM已经加人了MBFT-CONTROL和MBFT-DATA信道，并且确定了任何需要的MBFT令牌IDS。在组播或者专用方式情况下，非激活。条件是在加人MBFT-CONTROL和MBFT-DATA信道之前注册了置位，条件是在管理方式下，文件APE能够成为会话MBFT的管理者，也就是它能够响应MBFT-Privilege-RequestPDUs。当激活/非激活标志置为非激活时，则此标志不置位此参数取决于表2中规定的文件APE参数。静态的，若会话方式一静态。
动态组播，若会话方式一动态组播且省略会话ID。动态专用，若会话方式一动态专用且省略会话ID。若都不是，则省略
本协议不规定非拆装能力。这个字段可包括由用户应用规定的非标准非拆装能力见表7,若激活/非激活标志置为非激活则省略注册
在获得MCS用户ID之后，为了确定文件ARM是（作为一名组播成员）参加了现有的组播会话，还是（作为一名组播创建者）去创建-个新的组播会话，该文件ARM应审查文件APE会话ID参数。如果给出了会话ID参数，该文件ARM应通过发送GCC-Application-Enroll请求来尝试加人该会话，该请求中激活/非激活标志置为非激活，并且使用不可缺少的会话ID指定会话键。然后，它应发送MCS-Channel-Join请求，指定选定了会话的那个会话ID作为该信道ID参数。这条信道被用作MBFTCONTROL信道。再后，该文件ARM必须标识并加人MBFT-DATA信道，方法是使用表4中给定的492
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。