CN108040041B - 一种基于业务驱动的图像差异传输协议设计系统及方法 - Google Patents

Abstract

本发明属于图像数据传输领域，提出了一种基于业务驱动的图像差异传输协议设计系统及方法。该协议结合实际需求以及图像压缩编码对图像传输过程进行了分析设计，利用网络协议工程设计了一个具有图像差异传输功能，可高效、灵活解决共享问题的应用层协议；由于下层为TCP可靠协议提供支持，对于定长参数的控制信息报文的传输非常稳定，不存在需解决的关键问题，但该协议的传输重点即图像差异传输过程，在内容无错的情况下进行性能调优，是提高整个系统使用过程的稳定性与交互体验的关键。

Description

一种基于业务驱动的图像差异传输协议设计系统及方法

技术领域

本发明属于图像数据传输领域，采用网络协议工程的方法，构造协议，具体涉及一种基于业务驱动的图像差异传输协议设计系统及方法。

背景技术

在协议设计过程中，图像传输部分主要依赖于图像压缩编码技术。图像传输的实现，主要依托于信息论中的相关知识。数字图像在传输前，需要对图像进行编码。图像编码过程，首先对原始数字图像进行相关处理，去除冗余信息，根据一定的失真允许要求，对去除相关性后的原始信号重新编码。在一定条件下，当对连续的图像渲染结果进行传输时，在有已传图像的基础存在情况下，新图像传输时，无必要对整张图像做传输。在一定条件下，参考预测编码原理，即是通过对前一帧的预测值来生成后一帧，但该过程相对耗时，但其中的“差值”思路值得借鉴。对单张图像传输过程采用视频中的“关键帧”和“非关键帧”分类。“关键帧”表示当前图像必须完整的进行传输，“非关键帧”表示当前图像与前一帧图像存在相似关系，可以以这一张图像与上一张图像的差异来代替该图像的数据传输。

如果判定当前单张图像，可以作为是“关键帧”，则以原始图像的压缩数据作为传输数据；如果判定为“非关键帧”图像，则将当前图像与上一张图像做差异比对，拾取差异，这里的差异数据不同于视频压缩的预测值，为保证图像数据的可靠性，此差异提取过程为无损过程，以压缩后的差异数据作为传输数据。对差异数据仔细分析后发现，由于相邻帧存在逻辑关系，即会出现大部分连续的像素点不发生变化，或变化幅度相同的情况，差值分布具备一定连续性，故选择游程算法支持该差异数据的压缩过程。故对于连续个同差异变化(未发生变化为0，或差异值相同)的像素点采用游程编码后，将以差异点个数与这一组点相同的差异值来代替原有连续的多个差异值顺序数据。且在图像恢复时，由于游程编码算法复杂度低，图像恢复时间会大大缩短。基于以上两点的分析与设计，图像差异拾取最终方案，结合相邻帧对应像素点像素差值过程与游程编码过程来实现。

“协议(Protocal)”一词，最早用于描述数据的通讯过程。“协议是关于分布式系统进行信息交换时的一种约定，协议应按照语言的方式进行定义”，这是对信息传输过程中的协议的最早说明。随着互联网的出现以及其不断发展，协议也有了更全面的定义以及更系统的工程方式，网络协议是具有规定文法、语法和语义的语言。其中文法给出了有效信息的精确格式，语法描述了数据交换的规则，语义规定了可交换信息的词汇及其含义。协议工程，即针对实际需要进行一体化的、形式化的协议开发过程。其中，“一体化”定义为协议的设计、验证、实现和测试，在技术上前后衔接，并在同一开发系统中完成，一体化(Integrated)即系统化；以往的协议开发没有做到一体化，技术上前后阶段并不衔接，协议设计者凭借经验只会设计协议，以自然语言描述，经他人审定或模拟后即公布，或者仅在必要时才对协议进行验证，协议在实现过程中也会经协议实现者参考自己的环境和要求进行修改，缺乏连续性。

本发明协议内采用了业务驱动以及图像差异传输两个关键思路。业务驱动思想体现在协议设计过程中，即协议设计要围绕在要解决关键问题上，而非协议覆盖业务广泛性与全面性，最终目的在于如何结合具体的问题需求，设计出能够精准解决问题的协议，一味追求协议使用广泛性是不合理的。图像差异传输思路，借鉴了视频传输的思路，但是由于图像的非事先编码的特点，不能完全照搬视频传输过程，需在研究图像数据本身特点的基础上，结合其特殊性给出能够集中解决问题的方法。

发明内容

针对现有技术的不足，本发明提出一种基于业务驱动的图像差异传输协议设计。

本发明技术方案如下：一种基于业务驱动的图像差异传输协议设计系统，其特征在于，包括协议环境分析模块、协议构造要点模块、协议报文格式模块、协议声明格式模块和协议报文过程模块；

所述的协议环境分析模块，通过协议工程方式分析需求，进而明确协议环境，分析要点包括：

(1)联接管理：联接方式选用有联接服务形式，客户端与服务器联接为连续信息传递，信息具备实时性与连续性。其中，联接建立过程由客户端请求进行，维护过程由两端同时进行，断开过程可由客户端和服务器请求进行；

(2)通信模式：每个客户端和服务器之间只维护一条链路，服务器可同时向多个客户端维持链路，但客户端同时只拥有一条链路；

(3)服务认可：本层协议服务认可采用无认可式，ACK动作由TCP层协议通道完成；所有协议原语都会导致功能执行，对于协议原语不必进行认可确认动作，采取形式为信息发送方若发现协议原语在规定时间内未执行预期动作，则重新发送该语句，重新请求执行，在确定链接状态未断开正常情况下，根据实际情况重复请求到需要次数为止；

(4)通讯方式：通讯方式选择全双工模式，对于任意两用户间维持的通道而言，接收和发送动作可同时进行；

(5)数据形式：数据形式采用块数据形式，发送时单一报文携带该报文长度，接收方可根据该报文长度，读取全部报文进行解析；报文本身长度并不固定，但是报文头部长度是固定的；

(6)数据长度：由于块数据长度不固定，可能过长，报文分片过程由下层TCP协议完成，本层协议顺序按位读取数据，如果数据不完整等待下层协议直至数据完整；

(7)数据可靠性：下层协议TCP协议，是典型的可靠协议，报文有序、不丢不重、CRC错误校验都会进行，该需求内容由下层协议完成；

(8)目标识别：报文内容区分为有目标和无目标特性两种，对于有目标特性报文，需在报文内容中加入目标标识；

(9)通道性质：对于单一客户端和服务器形成的单一信道，提供有联接服务，且该联接服务仅支持该两结点间的通信；队列性质方面，报文贮存长度由TCP协议提供，以同步读取加等待方式进行，对读取到传输之间的延时消耗忽略不计，由报文接收方缩短处理事件时间保持在延时时效内保证；

(10)工作方式：协议工作方式选用全双工同步模式，全双工通道由两个信道端口维持，每个信道端口单向无冲突，使用时以同步方式进行；

(11)工作模式：协议需求环境为多点模式，模式中，服务器结点为主控实体，其他客户端结点以唯一的服务器主控实体为中心，接受为唯一来自该来源的信息，拓扑构建模式为主从模式。

所述的协议构造要点模块，本发明的协议构造过程采用的的自上而下的开发方法。根据待解决的业务需求以及实际的协议使用环境描述，用于对协议设计思路进行归纳；由于该协议的设计目的在于解决面向医学图像的远程医疗过程，所以协议的设计过程无需考虑多种复杂场景，将协议的功能划分与原语设计以业务为驱动，将图像差异传输过程作为图像协议传输的核心内容；基于以上的分析及思路确认，基于业务驱动的图像差异传输协议的协议模块划分与原语构成如表1所示。

表1 协议原语

在业务驱动的前提下，维护协议稳定性以及容错等协议基本性质，工作由下层支持协议TCP/IP协议进行保证，而不在本层协议重复进行工作，以提高报文分析速度，降低延时消耗；上述内容即为所有协议中的PDU及SDU原语，其中PDU为各联接管理及通道管理部分，SDU原语为其他业务驱动部分；协议使用时，以联接管理作为使用前提，视口通道管理与音频通道管理部分建立，在视口通道基础上使用图像传输管理与图像交互动作的协议进行具体的业务驱动部分。

所述的协议报文格式模块，指定了报文头部，报文内容，报文尾部；

所述的协议声明格式模块，包含了所有协议的功能原语；

所述的协议报文过程模块，描述了报文从生成、发送到解析的过程。

进一步地，上述的协议报文格式模块，根据协议原语需求以及内容需求，设计协议报文格式；协议报文由报文头部(Packet Head)、报文内容(Packet Body)以及报文尾部(Packet Tail)组成，各部分详细说明如下：

3.1所述的报文头部(Packet Head)：报文头部由协议功能名称(ProtocalFunction Name)与报文内容长度(Protocal Body Length)两部分组成；协议功能名称对应各个协议原语，以明文方式呈现，指定了该报文执行功能内容，方便各级解析器进行解析；报文内容长度指定了报文内容的长度，在协议环境分析内容中已经指出，协议采取块数据进行传输，但该块数据的大小会因不同的协议功能发生变化，由于对单一的数据报文解析需要预先得知长度，所以在这一结构中加入了报文内容的长度用于报文解析时使用，用于解析时先读取报文头部获得协议功能和报文长度，再按照该长度顺序读取报文内容，根据协议功能将解析后的内容交由系统其它部分处理；

3.2所述的报文内容(Packet Body)：报文内容中为解决协议头部中指出的协议功能所需要的参数；由于不同的协议功能执行过程中，需要不同的参数，所以以业务将该部分分成定长参数、浮动参数两类参数类型：

(1)定长参数：即在报文构造前，已知道该报文内容部分的最终长度，此类参数以“Key-Value”的键值对方式进行传输，解决的业务部分为状态变更或动作修改时的原子业务类型；

(2)浮动参数：即在报文构造前，不知道报文内容部分的最终长度，需要在报文构造时临时计算实际要传输的报文长度，此类参数以纯二进制数据流进行传输，解决的业务部分为图像传输数据；

3.3所述的报文尾部(Packet Tail)：用于标识该报文结束，并分割下一个报文的起点；该部分的内容是固定的，永远为关键字“ENDBODY”，并以关键字形式验证报文完整性。

进一步地，上述的基于业务驱动的图像差异传输协议设计系统，所述的协议声明格式模块，其特征在于，协议报文格式固定后，需在使用前根据实际的业务原语对要使用的协议功能簇进行声明；以XML描述方式描述声明的基本格式；

所述的协议声明(Protocal Function Collection)包含了所有协议功能原语，每一个协议功能原语(Protocal Function)定义了对应协议报文的相关内容，详细说明如下：

4.1所述的功能名称(name):描述了该协议报文的名称，Function Name对应报文结构中报文头部的协议功能名称(Protocal Function Name)中的内容；

4.2所述的报文长度(length):描述了该协议报文的内容长度，有非0与0两种取值：

(1)非0：对应报文内容中定长参数，即该报文在构造前已经知道报文内容长度，报文内容由一组或多组键值对构成，键值对由其Param集合决定。此时报文头部中报文内容长度(Protocal Body Length)即为该非0值；

(2)0：对应报文内容中的浮动参数，即该报文在构造前不知报文长度，报文内容由二进制数据构成，需要临时计算实际报文内容长度，并以该长度数值作为报文头部中报文内容长度(Protocal Body Length)的内容，报文内容实际长度与该实际计算值保持一致；

4.3所述的报文内容参数(Param):描述了该协议报文内容中携带的参数的Key值；对于定长参数而言，Param存在一组或多组，长度为固定值；对于浮动参数而言，Param不存在，及不存在该标签，存在也是无意义的，长度为实际计算值。

将定长参数报文与浮动参数报文声明方式作区分，其主要目的在于缩短报文解析时间。

进一步地，上所述的协议报文过程模块，协议描述文本，需由协议使用过程中每一个使用者保存，每一个结点通过该协议描述文本中阐述的规则对收到的数据进行解析，并根据该规则生成要发送的报文；原则上，所有的报文都可以以不定长及浮动参数的方式进行传输，报文不经过参数提取过程，直接交还给系统的对应处理部分，解析报文内容的部分交由上层系统部分进行，但是这一过程将使得整个系统各个部分的信息处理时间不平衡，大大增长报文的解析时间。对比定长参数报文的处理流程，具备固定长度的定长报文在收到报文的第一时间内解析，解析工作由定长参数提取器执行，提取出键值对参数，并将键值对参数直接交由系统对应处理部分进行使用并执行，但浮动参数的解析到使用过程则将全部压力交给后者，故使得这一报文的平均生命周期增长。

结合协议环境中压缩报文解析时间的需求，如果将所有的传输过程全部参照浮动参数的方式进行，是极其不合理且不负责任的，所以在协议的使用过程以及未来规划而言，应尽量使用定长参数的协议报文格式而减少浮动参数的使用，浮动参数只用于处理极端二进制传输或流传输需求情况，以平衡系统负载。

上述的基于业务驱动的图像差异传输协议设计系统的方法，包括以下步骤：

步骤1：按照协议工程方式分析需求，明确协议环境；

步骤2：根据业务需求和协议环境，使用自上而下的开发方法，归纳出设计思路；

步骤3：根据协议原语需求以及内容需求，指定报文格式，包括报文头部、报文内容以及报文尾部；

步骤4：协议报文格式固定后，需在使用前根据实际的业务原语对要使用的协议功能簇进行声明，包括功能名称、报文长度以及报文内容从参数；

步骤5：协议描述文本，需由协议使用过程中每一个使用者保存，每一个结点通过该协议描述文本中阐述的规则对收到的数据进行解析，并根据该规则生成要发送的报文。

本发明的有益效果：本发明设计了一种基于业务驱动的图像差异传输协议，该协议结合实际需求以及图像压缩编码对图像传输过程进行了分析设计，利用网络协议工程设计了一个具有图像差异传输功能，可高效、灵活解决共享问题的应用层协议；由于下层为TCP可靠协议提供支持，对于定长参数的控制信息报文的传输非常稳定，不存在需解决的关键问题，但该协议的传输重点即图像差异传输过程，在内容无错的情况下进行性能调优，是提高整个系统使用过程的稳定性与交互体验的关键。

附图说明

图1为本发明实施方案中的协议构造过程中利用自上而下开发方法的流程图。

图2为本发明实施方案中协议组织结构示意图。

图3为本发明实施方式协议报文格式示意图。

图4为本发明实施方式协议声明格式示意图。

图5为本发明实施方式协议报文过程示意图。

图6为本发明实施方式联接建立报文示意图。

图7为本发明实施方式协议报文读取过程示意图。

具体实施方式

下面结合附图对本发明实施方式作进一步详细的说明。

本实施方式中采用的基于业务驱动的图像差异传输协议设计方法，以网络协议工程的基本方法进行设计与构建，本实施将结合实际的工程环境与编程环境，针对该协议的实现过程进行详细阐述，证明协议的可操作性与可行性。其协议的实现部分，从协议报文格式、声明格式、报文过程阐述了协议最终形态，并举例说明实际的协议实现过程。

1.协议报文格式

根据协议原语需求以及内容需求，设计协议报文格式。协议报文由报文头部(Packet Head)、报文内容(Packet Body)以及报文尾部(Packet Tail)组成，如图3所示，各部分详细说明如下：

1.1所述的报文头部(Packet Head)：报文头部由协议功能名称(ProtocalFunction Name)与报文内容长度(Protocal Body Length)两部分组成。协议功能名称对应各个协议原语，以明文方式呈现，指定了该报文执行功能内容，方便各级解析器进行解析；报文内容长度指定了报文内容长度，在协议环境分析内容中已经指出，协议采取块数据进行传输，但该块数据的大小会因不同的协议功能发生变化，由于对单一的数据报文解析需要预先得知长度，所以在这一结构中加入了报文内容的长度用于报文解析时使用，解析时先读取报文头部获得协议功能和报文长度，再按照该长度顺序读取报文内容，根据协议功能将解析后的内容交由系统其它部分处理。

1.2所述的报文内容(Packet Body)：报文内容中为解决协议头部中指出的协议功能所需要的参数。由于不同的协议功能执行过程中，需要不同的参数，所以以业务将该部分分成定长参数、浮动参数两类参数类型：

(1)定长参数：即在报文构造前，已知道该报文内容部分的最终长度，此类参数以“Key-Value”的键值对方式进行传输，解决的业务部分多以状态变更、动作修改等瞬时原子业务类型，其定义声明过程将在后文描述。

(2)浮动参数：即在报文构造前，不知道报文内容部分的最终长度，需要在报文构造时临时计算实际要传输的报文长度，此类参数以纯二进制数据流进行传输，解决的业务部分为图像传输数据，其定义声明部分将在后文描述。

1.3所述的报文尾部(Packet Tail)：用于标识该报文结束，并分割下一个报文的起点。该部分的内容是固定的，永远为关键字“ENDBODY”，并以关键字形式验证报文完整性。

2.协议声明过程

协议报文格式固定后，需在使用前根据实际的业务原语对要使用的协议功能簇进行声明。以XML描述方式描述声明的基本格式，如图4所示。

所述的协议声明(ProtocalFunctionCollection)包含了所有协议功能原语，每一个协议功能原语(ProtocalFunction)定义了对应协议报文的相关内容，根据协议声明方案，现对协议的具体的声明过程给出实现样例。

报文数据类型分为定长参数与浮动参数两种。

其中以联接通道建立功能的协议声明对定长参数报文声明做出解释，如下：

联接建立报文声明，对应联接建立功能原语。其内容说明了一个报文的完整信息结构，报文功能为“CLIENTCONNECT”(客户端联接)，该报文内容部分的长度为20Byte，报文内容的键值对参数为一组，键值名为“USER”(用户)。

与此类定长参数报文声明相对应，浮动参数报文声明样例如下：

该浮动参数报文声明样例为图像关键帧传输协议报文格式声明，其报文功能为“SCREENSHOTSEND”(图像关键帧信息)，该报文长度此处声明为0，与定长参数报文声明相比，特殊点在于报文内容长度为0，且该报文内无参数声明。由前文协议设计部分可以得知，浮动参数报文在实际报文内容构造前是无法知道报文内容的具体长度的，需要在发送前临时做计算，故此处填写任何规定报文内容长度的信息都是无意义的，为协议报文解析形式的一致性，此处以0代表浮动参数报文长度。这种声明方式，与实际的业务需求不会产生冲突，原则上不存在报文内容为0的定长参数报文，即协议构造时规定，任何一个定长参数报文至少携带一组键值对参数，所以协议中长度为0的报文声明直接表示该声明为浮动参数报文声明。

与协议报文格式声明对应的是最终形成的报文形态。以联接建立为代表的定长参数报文最终形式与报文声明对应关系如图6所示。

所有的定长参数报文，在报文内容部分以“Key1-Value1Key2-Value2”形式进行生成，键与名之间以“-”符号进行分割，键值对与键值对之间以“空格”进行分割，尾部以“ENDBODY”进行标注，定长参数报文内容中，以上三种字符串作关键字使用。

与定长参数报文的最终生成形式不同的是，浮动参数报文的报文内容部分不是以可识别的键值对方式进行保存，而是不可单独分片或识别的二进制流。使用前，需要将该二进制数据在之后的实现过程中转换为对应的数据格式，同时，报文内容长度也不是提前决定的，而是由实际的二进制数据长度进行确定。3.协议报文读取过程

基于业务驱动的图像差异传输协议，从TCP/IP五层模型做区分，为应用层协议，下层依赖的传输层协议为TCP(Transmission Control Protocol)^[67]。TCP协议是一种面向连接的可靠字节流传输层通信协议，其最突出的特点就是可靠传输，及协议本身对字节流的传输过程保证无损、无重、无乱序特性。在TCP传输协议基础上建立的应用层协议，在传输过程中无需再为保证字节流可靠性做出相应处理，只需保证报文的封装与发送过程序列保持业务正确性即可。在该编程环境中，TCP协议的使用过程主要通过KPI套接字(Socket)来实现。该应用层协议的收发及解析过程，在套接字基础之上进行。

Socket套接字根据IP地址进行联接建立过程，联接建立后，两侧的端口位置等待新信息进入，新进入的信息以消息块的方式进入收信方的缓冲区队列，消息块在收信方缓冲区队列中的排列顺序与发信方对消息块的发送顺序保持一致。

由于消息一旦进入缓冲区队列后，字节流是完全连续的，即字节流无法进行片段分割，应用层的多个数据包将首尾相接在一起，所以从Socket缓冲区中取出数据时，在无法得知下一个分片的具体长度数值时，是无法恰好的准确的读出该分片的，一旦发生少读取或多读取数据的情况时，就会导致缓冲区的所有后续报文的读取异常。传统在TCP协议之上利用Socket的协议构建，都选择使用定长报文做处理，即所有的报文均是同一长度，读取时只需按照该长度进行读取，就能读取单一分片，再根据分片编号对同一报文进行组装。基于业务驱动的图像差异传输协议并不采用这一方案，而选择发送定长报文头部与不定长的报文内容相结合的形式。其报文读取过程如图7所示。

结合报文读取过程示意图，报文读取步骤说明如下：

(1)首先读取定长报文头部，头部中包含了协议报文功能与报文内容长度两个参数。

(2)根据报文头部中的报文内容长度，继续读取该报文长度大小的字节流，即为报文内容部分。

(3)读取报文内容后，继续读取报文尾部，提取内容，做出完整性验证。

基于TCP协议的应用层协议在构建时，需要注意在读取的分包问题，即如何解决字节流的连续性问题。传统解决方案是构造定长数据包，一个或多个数据包组成一个报文，基于业务驱动的图像差异传输协议，采用的是以定长数据头部作为前驱，并在该定长内容中携带不定长的数据部分的长度，接下来的读取过程就可以按照该长度读取。

总结而言，连续字节流的报文解析过程中，必须存在定长部分，并且该定长部分中必须能对不定长部分的读取做出指导或携带相关索引，从而使整个数据包由不定长度转换为可识别的“固定长度”。

Claims (6)

1.一种基于业务驱动的图像差异传输协议设计系统，其特征在于，包括协议环境分析模块、协议构造要点模块、协议报文格式模块、协议声明格式模块和协议报文过程模块；

所述的协议环境分析模块，通过协议工程方式分析需求，进而明确协议环境；具体分析要点包括：

(1)联接管理：联接方式选用有联接服务形式，客户端与服务器联接为连续信息传递，信息具备实时性与连续性；其中，联接建立过程由客户端请求进行，维护过程由两端同时进行，断开过程可由客户端和服务器请求进行；

(2)通信模式：每个客户端和服务器之间只维护一条链路，服务器可同时向多个客户端维持链路，但客户端同时只拥有一条链路；

(3)服务认可：本层协议服务认可采用无认可式，ACK动作由TCP层协议通道完成；所有协议原语都会导致功能执行，对于协议原语不必进行认可确认动作，采取形式为信息发送方若发现协议原语在规定时间内未执行预期动作，则重新发送该语句，重新请求执行，在确定链接状态未断开正常情况下，根据实际情况重复请求到需要次数为止；

(4)通讯方式：通讯方式选择全双工模式，对于任意两用户间维持的通道而言，接收和发送动作可同时进行；

(5)数据形式：数据形式采用块数据形式，发送时单一报文携带该报文长度，接收方可根据该报文长度，读取全部报文进行解析；报文本身长度并不固定，但是报文头部长度是固定的；

(6)数据长度：由于块数据长度不固定，可能过长，报文分片过程由下层TCP协议完成，本层协议顺序按位读取数据，如果数据不完整等待下层协议直至数据完整；

(7)数据可靠性：下层协议TCP协议，是典型的可靠协议，报文有序、不丢不重、CRC错误校验都会进行，该需求内容由下层协议完成；

(8)目标识别：报文内容区分为有目标和无目标特性两种，对于有目标特性报文，需在报文内容中加入目标标识；

(9)通道性质：对于单一客户端和服务器形成的单一信道，提供有联接服务，且该联接服务仅支持该两结点间的通信；队列性质方面，报文贮存长度由TCP协议提供，以同步读取加等待方式进行，对读取到传输之间的延时消耗忽略不计，由报文接收方缩短处理事件时间保持在延时时效内保证；

(10)工作方式：协议工作方式选用全双工同步模式，全双工通道由两个信道端口维持，每个信道端口单向无冲突，使用时以同步方式进行；

(11)工作模式：协议需求环境为多点模式，模式中，服务器结点为主控实体，其他客户端结点以唯一的服务器主控实体为中心，接受为唯一来自该来源的信息，拓扑构建模式为主从模式；

所述的协议构造要点模块，将协议的功能划分与原语设计以业务为驱动，将图像差异传输过程作为图像协议传输的核心内容；在业务驱动的前提下，维护协议稳定性以及容错协议基本性质，工作由下层支持协议TCP/IP协议进行保证，而不在本层协议重复进行工作；上述内容即为所有协议中的PDU及SDU原语，其中PDU为各联接管理及通道管理部分，SDU原语为其他业务驱动部分；

表1 协议原语

所述的协议报文格式模块，指定了报文头部，报文内容，报文尾部；

所述的协议声明格式模块，包含了所有协议的功能原语；

所述的协议报文过程模块，描述了报文从生成、发送到解析的过程。

2.根据权利要求1所述的基于业务驱动的图像差异传输协议设计系统，其特征在于，所述的协议报文格式模块，其特征在于，根据协议原语需求以及内容需求，设计协议报文格式；协议报文由报文头部、报文内容以及报文尾部组成，各部分详细说明如下：

3.1所述的报文头部：报文头部由协议功能名称与报文内容长度两部分组成；协议功能名称对应各个协议原语，以明文方式呈现，指定了该报文执行功能内容，方便各级解析器进行解析；报文内容长度指定了报文内容的长度，用于解析时先读取报文头部获得协议功能和报文长度，再按照该长度顺序读取报文内容，根据协议功能将解析后的内容交由系统其它部分处理；

3.2所述的报文内容：报文内容中为解决协议头部中指出的协议功能所需要的参数；以业务将该部分分成定长参数、浮动参数两类参数类型：

(1)定长参数：即在报文构造前，已知道该报文内容部分的最终长度，此类参数以“Key-Value”的键值对方式进行传输，解决的业务部分为状态变更或动作修改时的原子业务类型；

(2)浮动参数：即在报文构造前，不知道报文内容部分的最终长度，需要在报文构造时临时计算实际要传输的报文长度，此类参数以纯二进制数据流进行传输，解决的业务部分为图像传输数据；

3.3所述的报文尾部：用于标识该报文结束，并分割下一个报文的起点；该部分的内容是固定的，永远为关键字“ENDBODY”，并以关键字形式验证报文完整性。

3.根据权利要求1或2所述的基于业务驱动的图像差异传输协议设计系统，其特征在于，所述的协议声明格式模块，其特征在于，协议报文格式固定后，需在使用前根据实际的业务原语对要使用的协议功能簇进行声明；以XML描述方式描述声明的基本格式；

所述的协议声明包含了所有协议功能原语，每一个协议功能原语定义了对应协议报文的相关内容，详细说明如下：

4.1所述的功能名称:描述了该协议报文的名称，Function Name对应报文结构中报文头部的协议功能名称中的内容；

4.2所述的报文长度:描述了该协议报文的内容长度，有非0与0两种取值：

(1)非0：对应报文内容中定长参数，即该报文在构造前已经知道报文内容长度，报文内容由一组或多组键值对构成，键值对由其Param集合决定，此时报文头部中报文内容长度即为该非0值；

(2)0：对应报文内容中的浮动参数，即该报文在构造前不知报文长度，报文内容由二进制数据构成，需要临时计算实际报文内容长度，并以该长度数值作为报文头部中报文内容长度的内容，报文内容实际长度与该实际计算值保持一致；

4.3所述的报文内容参数:描述了该协议报文内容中携带的参数的Key值；对于定长参数而言，Param存在一组或多组，长度为固定值；对于浮动参数而言，Param不存在，及不存在该标签，存在也是无意义的，长度为实际计算值。

4.根据权利要求1或2所述的基于业务驱动的图像差异传输协议设计系统，其特征在于，所述的协议报文过程模块，其特征在于，协议描述文本，需由协议使用过程中每一个使用者保存，每一个结点通过该协议描述文本中阐述的规则对收到的数据进行解析，并根据该规则生成要发送的报文；定长参数报文的处理流程，具备固定长度的定长报文在收到报文的第一时间内解析，解析工作由定长参数提取器执行，提取出键值对参数，并将键值对参数直接交由系统对应处理部分进行使用并执行。

5.根据权利要求3所述的基于业务驱动的图像差异传输协议设计系统，其特征在于，所述的协议报文过程模块，其特征在于，协议描述文本，需由协议使用过程中每一个使用者保存，每一个结点通过该协议描述文本中阐述的规则对收到的数据进行解析，并根据该规则生成要发送的报文；定长参数报文的处理流程，具备固定长度的定长报文在收到报文的第一时间内解析，解析工作由定长参数提取器执行，提取出键值对参数，并将键值对参数直接交由系统对应处理部分进行使用并执行。

6.权利要求1-5任一所述的基于业务驱动的图像差异传输协议设计系统的方法，其特征在于，包括以下步骤：

步骤1：按照协议工程方式分析需求，明确协议环境；

步骤2：根据业务需求和协议环境，使用自上而下的开发方法，归纳出设计思路；

步骤3：根据协议原语需求以及内容需求，指定报文格式，包括报文头部、报文内容以及报文尾部；

步骤4：协议报文格式固定后，需在使用前根据实际的业务原语对要使用的协议功能簇进行声明，包括功能名称、报文长度以及报文内容参数；

步骤5：协议描述文本，需由协议使用过程中每一个使用者保存，每一个结点通过该协议描述文本中阐述的规则对收到的数据进行解析，并根据该规则生成要发送的报文。

Images