本站小编为你精心准备了医学数字与通讯协议实现策略参考范文,愿这些范文能点燃您思维的火花,激发您的写作灵感。欢迎深入阅读并收藏。
1DICOM上层协议(ULP)
ULP处于DICOM应用实体的底层,从开放系统互联(OSI)分层模型看,它包括了对话层、表示层、应用层的应用控制服务元素(ACSE)部分[1].为了体现ULP跨越了多个OSI分层这一事实,图1中用斜线部分表示它.ULP的作用主要包括两方面:①提供应用层的公共服务元素ACSE,具体包括在对等应用实体间建立关联,正常释放关联,异常中止关联等功能;②为DIMSE提供网络数据传输支持,也就是以ULP规定的协议数据包格式传送或接收DIMSE的命令流与数据流.ULP是应用层调用网络服务的功能接口,实际中广泛使用基于传输控制协议/互联网协议(TCP/IP)的4层结构模型,此时ULP直接调用TCP提供的网络传输功能构建本层服务,供应用层调用.
2ULP提供的服务
ULP提供的4种服务及对应的服务对象.A-ASSOCIATE服务用来在对等应用实体间建立关联,它是一个证实性服务.在关联建立阶段,双方需要交换包括应用上下文、表示上下文、DIMSE特定的用户信息等初始化信息,因此建立关联也是个协商过程.一旦关联建立,则双方应用实体对本次关联中的应用层服务项目的范围及相关的参数就有了约定,这样就保证了后继DIMSE消息交互的顺利进行.A-RELEASE服务用来在对等的应用实体间正常有序地结束关联,它也是一个证实性服务.使用A-RELEASE结束关联不会造成任何应用层数据的丢失,因此是一种优雅的中止方式.A-ABORT服务用来异常中止应用实体关联,它是一个非证实性服务.A-ABORT拥有3个服务使用者,这意味着应用实体、DIMSE或ULP这3个层次中的任何实体一旦遇到异常情况都可利用A-ABORT强行中止应用关联,本服务可能造成各层待传数据与暂存数据的丢失.P-DATA-TF服务用来向对等应用实体传送DIMSE命令流与数据流,它是一个非证实性服务.P-DATA-TF服务是应用实体获取网络传输服务的逻辑接口,应用实体的某一方一旦使用该服务把DIMSE消息流传送出去,就可以认为对方应用实体能准确无误地接收到此消息.3ULP的协议数据单元(PDU)及其实现ULP一共提供了7个PDU来实现上述4种服务.DICOM的所有通信最终就是依靠上述7个PDU来完成的[4].PDU承担实现ULP的任务,而PDU本身必须依赖下层网络提供的服务接口.虽然DICOM标准提供了基于OSI与TCP/IP两种可能的实现方式,实际中,一般都采用基于TCP/IP的4层模式,因此首先必须充分了解TCP/IP提供的网络服务和获取这些服务的调用接口.在此基础上,本文给出了有代表性的PDU实现实例.
3.1TCP/IP协议及套接字接口
TCP/IP是应用最广泛的传输层/网络层协议,也是事实上的工业标准[5].TCP是一种面向连接的可靠协议.在复杂的互联网上,它完全屏蔽了任意两个端点间进行通信的细节,提供了端对端有序、无差错流式的数据传输功能.获取TCP服务的编程接口是套接字.套接字锁定了网络层地址(IP地址)与传输层地址(端口号),它是对一个通信端点的抽象[6].ULP所有的PDU数据交互最终需要借套接字来实现.
3.2PDU实现实例
ULP中使用最频繁的PDU是P-DATA-TF,所有的DIMSE消息都是通过它进行传送和接收,P-DATA-TFPDU的最大长度必须符合应用关联建立时双方的协商结果.如图3所示,每一个PDU封装了若干个表示数据值(PDV),每一个PDV由一个字节的表示上下文ID、一个字节的消息控制头与一个DIMSE命令或数据片段组成.表示上下文ID在关联建立协商时确认,因此只在某次特定的应用关联内有效,它指示本PDV所载DIMSE消息所属的服务类.控制头用来指示本PDV是命令还是数据,以及是否是本类型PDV(命令或数据)中的最后一个.一个DIMSE消息包可能被分为若干片段,每个P-DATA-TFPDU可以携带一个或若干个片段(受PDU最大长度值限制).表示上下文ID与消息控制头保证了对方ULP实体能准确无误地重组DIMSE消息包.
4ULP的实现
ULP借助于ULP的PDU来实现,而PDU依靠套接字来完成实际的网络数据传输,这只是静态的描述.在一定的上下文环境下,ULP实现还包括对PDU的解释以及在解释基础上PDU之间的交互,所有的服务功能通过解释与交互体现出来.ULP负责把PDU中的连续字节流解释成为有意义的协议控制信息,并分离出DIMSE流(如果存在的话).以处理应用关联请求为例,该服务涉及的PDU中没有DIMSE负载,实际上只有P-DATA-TFPDU中才包含ULP不能解释的DIMSE流,因此需要向DIMSE层递交.显然,A-RELEASE与A-ABORT的实现要比A-ASSOCIATE简单,因为它们本层的控制信息很少,且不需要向邻接上层递交数据.如图4所示,一旦请求DICOM服务的客户端完成TCP连接,它立即发送A-ASSOCIATE-RQPDU,该PDU是一个有序的数据流块,按照ULP规定存放着各种协商数据,服务器端从该PDU数据流中取出相关内容获得语义解释,就可决定是否接受本次关联请求以及本次关联中的服务内容.表示上下文表征应用层协议中定义的抽象语法和能满足抽象语法的传输语法之间的联系,每个抽象语法和能对它进行编码的传输语法组合起来就构成一个表示上下文.用户信息包括最大PDU长度、实现类UID、实现版本名称等.
5ULP实现的优化
一个优秀的协议实现,必须考虑执行效率.一个良好的设计除了做到快速分配存储空间外,尤其要避免分组在各个协议软件之间移动时的数据复制[7].对于DICOM协议这种以医学图像为主要传输对象.数据流量特别大的应用协议,协议实现效率在很大程度上取决于数据在不同层移动时的复制频度,避免数据移动时的复制操作是ULP实现优化总的着眼点.DICOM应用层数据的移动过程如图5所示,从打包过程看,应用层数据至少移动了4次,即应用层-PDV-PDU-TCP内部缓存-TCP数据包.如果每次移动都伴随数据复制,虽然流程清晰但是实现效率一定较低.注意到底层TCP支持的是面向无边界的数据流,我们可以把数据在形式上打包封装发送的过程等效为封装头信息与封装体信息的次序发送,因此并不需要形成真正在内存中连续存放的PDV或PDU数据包.为了避免ULPPDU数据到TCP内部缓存的复制,可以使用套接字接口新支持的重叠I/O机制,它把调用者提供的数据缓存区的内容直接填充到TCP数据包而绕过TCP内部缓存.同样在接收时,可以把TCP数据包中的数据直接复制到调用者提供的缓存区.可见,在满足ULP封装规范要求的前提下,DIMSE消息数据可以做到直接传入TCP数据包,这样大大提高了数据发送效率.拆包过程是去掉各种封装头提取DIMSE消息数据的过程.封装头中存放着足够的控制信息,用来指导后继动作(比如命令集是否接收完,数据集是否接收完,还剩多少数据尚待接收等等),可以使用一个包括首地址指针与数据长度的结构来描述一个数据片段,那么整个DIMSE消息数据就是一个上述结构的指针链表.这种存储块链表避免了接收时的数据复制,如果应用层需要,把它转化或部分转化为平面空间存储也很容易.在上述打包与拆包的实现过程中,为了避免数据复制,代价是需要多次调用底层的套接字接口.尽管这种调用开销与大量的数据复制开销相比是值得的,但还是有办法克服这个不足:利用套接字提供的分散与聚集I/O机制,使若干个孤立存储区的内容可以通过一次套接字调用发送或接收,避免了多次调用孤立存储区的开销.例如,某病人进行X射线放射荧光成像(RF),一般一次生成7~8个RF图像,每个图像约为2MB大小,共计14~16MB,现在使用DICOM3•0中的C-STORE服务类把图像数据通过网络发送到某个归档服务器,表3给出了两种实现方式的比较.
6结论
按照本文对DICOM3•0ULP设计与实现的理解,已经开发出完整的ULP实现模块,并与美国Picker公司D-MaxDigitalSystem提供的DI-COM3•0接口顺利进行了通信,实现了它的一致性声明中包含的所有应用层服务,从而证明了本文所述ULP设计与实现方案的可行性与有效性.