exe源码剖析,DICOM管教育学图形处理

转载:http://blog.csdn.net/zssureqh/article/details/39213817

转载:http://blog.csdn.net/zssureqh/article/details/39237649

转载:http://blog.csdn.net/zssureqh/article/details/41016091

背景:

       
上一篇专栏博文中针对PACS终端(或配备终端,如CT设备)与奇骏IS系统之间worklist查询进行了介绍,并主要相比分析了DICOM3.0中各部分对DICOM互连网通信服务的概念。此番经过结合早些日子的博文DICOM管工学图像处理:基于DCQualcomm工具包学习和剖析worklist,对DC高通开源库中提供的storescp.exe和storescu.exe工具的源码举办辨析,从最底层深远摸底C-STORE服务的接触及响应。

背景:

       
上1篇博文中,在对storescp工具源文件storescp.cc和DcmSCP类的源文件scp.cc举行剖析后,得出了二者都可以兑现响应C-ECHO和C-STORE(须要对DcmSCP类进行增加)请求的效益。可是在对DcmSCP类进行扩大,期望模拟实现协调的storescp.exe工具时遇到了难点,客户端提醒服务中断链接,而服务端彰显保存战败,如下图所示。本次博文经过免去该难题再贰次对storescp.cc和scp.cc进行比较,主要从Presentation
Context、AbstractSyntax、TransferSyntax等细节出发,认真学习DICOM通信服务。

 

图片 1

 

背景:

       
专栏取名叫DICOM文学图像处理原因是:博主是从军事学图像处清理计算法钻探时开首接触DICOM协议的。当初认识有局限性,认为DICOM只是1个简短的文件格式约定,简单来讲,笔者马上感到DICOM协议便是增添名字为DCM文件的格式表明。其实不然,随着对治疗行当的透彻,对DICOM协议也有了更健全的认识。近期才察觉DCM文件只是DICOM协议一部分中的一小节,仅仅是整整协议中的一个数据结构,而DICOM协议愈来愈多的是关于医疗行业各个劳动及相关流程的约定,因而实际DICOM协议中最重要的是音信流,是对医院全部运维流程的预定。依作者看来,能够将DICOM分为两大类(那里只是从DICOM相关从业者常常职业角度出发来分类的):壹)DICOM管文学图像处理,即DCM文件中实际数据的拍卖,说图像大概有个别狭隘,广义上还包含波形(心电)、摄像(超声)等等;贰)DICOM互联网传输,首要描述新闻在医务室各系统之间的交互情势及传输格式。像自身事先的钻研就全盘属于第贰类“DICOM经济学图像处理”,一旦解析出DICOM的文件格式其实与正规的图像处理就从未不同。假使仅此而已,可以说跟医疗就从未有过其他关联,与治疗行当整合紧凑的是第壹类“DICOM网络传输”,该部分是惯常伤者到诊所就诊等壹体化流程的架空,是DICOM标准的骨干。由此此次博文就首要介绍“DICOM互连网传输”中的第3环节:互连网连接(Association,在OSI中称之为Connection),并组成DCMTK和fo-dicom的源码实行实例介绍。

解析思路:

       
storescp.exe和storescu.exe分别担任着C-STORE服务的SCP和SCU,因而臆度三个工具包一定是应用了DCMediaTek提供的DcmSCP和DcmSCU类来分别达成的。为了求证本人的想法,从剖析storescp.exe源码文件storescp.cc动手,相比storescp.cc与scp.cc,搜索双方的共同点。假设与我们的设想一致,就新建叁个C++本地下工作程,利用DcmSCP类来建立协调的C-STORE
SCP端,期望达到与storescp.exe工具包同样的效应。

主题材料化解:

DICOM互连网传输:

storescp.cc与scp.cc源码分析:

一)比较分析storescp.exe工具包与自定义务工作具包的调试消息

       
为了免除storescu.exe客户端的主题材料,大概分明难点出现的限制,决定再3遍用storescp.exe作为客户端,使用storescu.exe对其发送C-STORE请求,查看storescu.exe客户端的调节和测试消息。与咱们的自定义务工作具服务端的调节和测试音信举办对照。

图片 2

        比较上海体育地方中的调节和测试音信,当中乙酉革命部分END
A-ASSOCIATE-AC表示的是服务端已经胜利的与客户端实现了拉手,即互联网已经胜利响应了客户端的连接。深樱草黄部分代表客户端发送的C-STORE-LacrosseQ请求也已经胜利的到达了服务端,唯一不一样的正是色情圆圈标志的1些,表明在服务端接收到C-STORE-LX570Q请求后对其处理有题目。而我们友好包装的ZSDcmStoreSCP类对于C-STORE-翼虎Q的处理函数是间接拷贝的storescp.exe工具内的storeSCP和storeSCPCallback函数。因而大约能够鲜明难题或许出现的限定。

服务端(Server,SCP)/客户端(Client,SCU):

       
DICOM选取C/S方式来讲述网络传输:客户端(Client)连接到服务端(Server)然后采取服务端提供的每一项服务(Services)。不一样于守旧互连网连接中的Server和Client的,DICOM中的Server叫做ServiceClass Provider,Client叫做Service Class
User。想要建立DICOM连接(Association,古板OSI模型中称之为Connection),客户端会向服务端发送连接请求新闻,该音讯至关心重视要描述客户端本次连接所期望的DICOM服务及有关安装;随后服务端会查看客户端发送过来的央浼音讯,确认本身是或不是帮衬客户端请求的连带服务并交付反馈音讯(DICOM中称之为响应音讯Response
Message)。响应音讯首要分为以下几类:一)若是服务端协助客户端请求的1些服务,服务端会发送确认音信(Association
Acknowledge),申明此番连接形成;2)否则发送拒绝消息(Association
Reject),公告客户端(SCU)连接退步。全数与连接相关的新闻在DICOM协议中的ACSE(Association
Control Service Element)定义。

       
1旦网络连接建立,客户端(SCU)和服务端(SCP)就足以拓展消息相互。DICOM标准中的DIMSE(DICOM
Message ServiceElement)将此类消息分为11类(实际情况可参见DICOM协议中的相关细节,也可参见笔者事先的博文http://blog.csdn.net/zssureqh/article/details/39098621)。依据与连接新闻(ACSE)的不等,提供的DIMSE新闻项目也不及。例如守旧壹幅DICOM图像到服务端进行归档,使用的是C-STORE
DIMSE新闻;倘诺期望由此病人姓名和病者出出生之日期来询问伤者的档案,必要使用DIMSE
C-FIND消息。

图片 3

图片 4

一)storescp.cc源码分析

       
storescp.cc是DC德州仪器提供的storescp.exe工具的源文件。间接张开storescp.cc文件,首先能够观望小编给出的注释:

 

图片 5

 

       
Purpose回顾了该工具的主要用途——是储存服务的提供者,用来响应C-STORE
操作。由于storescp.exe是一个命令行工具,即用户能够通过不一样的参数设置或组合来落到实处分裂的效果。由此在storescp.cc文件起先main主函数外部定义了过多大局的命令行参数变量,例如大家上壹篇博文DICOM文学图像处理:全面剖析DICOM三.0正式中的通信服务模块中利用的storescp.exe
-d 10四 -aet OFFIS命令行中的拾4绝对应的参数是opt_port,
从参数opt_前缀亦能够猜出用途。

       
由于storescp.exe工具是需求与客户端进行相互的,接下去进入到main主函数后的率先件事情正是起首化网络环境。1般来讲图所示,小编采纳标准编写翻译(如下图中的红圈所示)以来落成不一样系统的互联网环境的伊始化,由于作者利用的是Windows7操作系统,由此原则编写翻译的结果是调用WSAStartup初始化Windows
套接字(Socket)的互连网环境。

 

图片 6

 

       
网络环境的早先化是main函数的首先步操作,随后正是后边提到的命令行参数的分析,因为storescpp.exe是命令行类型的工具包。从文件260行至9九贰行便是命令行参数的辨析部分,大家暂时直接跳过该部分,轻松地认为该有的完毕的机能就是对应参数的赋值。

接下去正式进入到了DICOM模块,

第3步,加载DICOM字典文件。该手续差不离是持有与DICOM操作相关的文件的率先步。其实正是加载3个先行写好的带有各样DICOM三.0正式中规定的字段的文本文件。

其次步,开首化互连网连接,成立互连网连接的1个实例,格式为T_ASC_Network(如下图),记住该类型,不要与后面出现的T_ASC_Association混淆了。其实在率先步和第一步之间我们简要了一些代码,该片段至关心器重要是用来调节storescp.exe工具的运维机制,是单线程依旧四线程。

 

图片 7

 

其三步,进入外层while循环。在应用ASC_initializeNetwork开头化互联网环境后,就进来到了while循环内的acceptAssociation函数。那也是正规意况下,while循环中唯一的行事函数。随后正是待连接断开后的了断工作。

第五步,单步调节和测试进入acceptAssociation函数内部。从函数前边的疏解理解到函数是用来选用处理链接请求的,注意看函数的参数,传递进入的是地点我们发轫化后获得的网络连接变量net,ascfig是通过解析命令行而获取的布局参数。

 

图片 8

 

第四步,函数acceptAssociation内部早先通过调用ASC_receiveAssociation来品尝获得客户端的总是请求,该函数与socket编制程序中的accept函数类似,可以安装阻塞形式和非阻塞情势(关于套接字的堵截方式和非阻塞方式的界别可参见《Windows网络编制程序》)。调用该函数后storescp.exe工具就半上落下,等待客户端发起链接。

 

图片 9

 

第陆步,当有客户端连接进入后,ASC_receiveAssociation函数重回,随后会冒优秀多以ASC_为前缀的函数,首要有ASC_acceptContextsWithPreferredTransferSyntaxes、ASC_setAPTitles、ASC_getApplicationContextName,以及1旦产生错误情状下会调用的ASC_rejectAssociation。参照博文DICOM艺术学图像处理:全面剖析DICOM三.0正规中的通信服务模块中的分析可见,以ASC_为前缀的函数属于DICOM叁.0中的Association
Managements,首要在第九有个别授课。用来贯彻上层DIMSE与下层DUL(Dicom
Upper Layer
Protocol)的牵连,所处的职位如下图(更详实的牵线可参考上一篇博文)。因而可见该部分是在ASC_receiveAssociation接收到客户端连接后,所实行的有关连接层的相关安插。(要留心该部分的配置流程,上面包车型地铁实例疏解中会重点介绍由于该有的陈设错误,导致模拟的工具包不或许符合规律运作【注壹】)。

 

图片 10

 

第⑧步,接收客户端连接并布置落成后正是殡葬确认消息,即调用函数ASC_acknowledgeAssociation。此处注意从ASC_receiveAssociation函数重返后,继续的有关ASC_函数操作的参数就从T_ASC_Network类型的net变成了T_ASC_Association类型的assoc,其象征的是客户端的一连。

 

图片 11

 

第9步,storescp.exe发送完确认消息后,接下去就须要处理客户端发来的求实请求了。该有的职业包蕴在processCommands中。

第八步,进入到processCommands函数内部,就是大家所遭受的第二个里面while循环,与第二步中的while外部循环差别的是该内部循环用来收纳客户端发来的DIMSE音信的,而第3步中的while循环是用来循环等待客户端连接请求。

第十步,内部while循环内,调用DIMSE_前缀函数,来促成DIMSE层的消息交互,那也是C-ECHO、C-STORE、C-FIND等请求具体贯彻的部分。首先调用DIMSE_receiveCommand接收客户端的DIMSE音信,随后依据DIMSE中的CommandSet的品种,分别实行处理,如下图所示,能够观望storescp.exe工具能够对C-ECHO和C-STORE举办处理。

 

图片 12

 

       
至此,通过上述差不多的10步大家对storescp.exe源码有了一个较深切周到的认识。从调用的ASC_和DIMSE_函数来看,storescp.exe完全依照DICOM3.0的网络通信协议来拍卖C-ECHO和C-STORE请求的。

       
依据OFFIS官方网站给出的有关dcmnet网络通信包的介绍(http://support.dcmtk.org/docs/mod_dcmnet.html),可见DCMediaTek库中提供了七个来促成DICOM网络通信两端的类DcmSCP和DcmSCU。那么storescp.exe为何未有一向用DcmSCP来落到实处C-STORE的服务端呢?利用DcmSCP类是还是不是能够来促成storescp.exe工具的效益吗?

二)单步调节和测试

       
在handleIncomingCommand函数内部调用storeSCP指令处插入断点,进入单步调节和测试情形。利用VS二零一三提供的新的调整工具“并行旅社”,找到了第3个再次回到状态cond.bad()为true的地点,即函数ASC_findAcceptedPresentationContext,如下图所示:

 

图片 13

 

       
继续单步调节和测试,进入到ASC_findAcceptedPresentationContext函数内部,发现真正出现谬误的地点是findPresentationContextID,该函数的参数presentationContextID始终为零。

图片 14

猜测:莫不是presentationContextID参数在传递进程中的某一环节出错了,导致程序失利。为了表达大家的想法,张开storescp.exe工程,进入调节和测试格局,查看参数的数值景况,如下图所示,storescp.exe工具包中presentationContextID参数的值为四一。由此注脚了我们在presentationContextID参数字传送递的历程中发出了错误。

 

图片 15

 

恳请连接:

       
如上所述,客户端SCU向劳动端SCP发送连接请求,请求服务及相关音信。除此以外,请求音讯中还包罗以下新闻:

 

  • 请求端实体名称(Calling AE
    Title):在DICOM服务中,用于代替客户端(SCU)的号子,仿佛大家的姓名一样;
  • 被呼吁实体名称(Called AE
    Title):在DICOM服务中,用于替代服务端(SCP)的号子,就如我们的全名相同;
  • 讲述上下文(Presentation Contexts):是一个服务清单(List of
    Services)。清单体量最多不超过1三十个,用于描述客户端希望从服务端获得的每一样服务,每一项服务重大总结SOP
    Class和List of Transfer Syntaxes。

 

上边对上述3中国国投息举办更详实介绍:

 

        AE
Title:在DICOM网络中每贰个DICOM系统都会被分配一个称呼,即Application
Entity Title,简称AETitle。AE
Title用于标志DICOM互联网中的唯一(Unique)DICOM系统(有点类似于网络中的IP地址),由此在二个DICOM互联网环境中,要保管每一个DICOM系统具备唯壹的称号——这些工作一般由DICOM互联网管理员来成功。AE
Title最长不超越17个字符,平日在事实上行使进程中都使用大写字母来表示,当然也能够应用小写字母及别的ASCII码。在创设连接进度中,客户端SCU会发送温馨的AE
Title(即Calling AE Title)以及服务端的AE Title(即Called AE
Title,当然那些只是客户端期望的,实际情形有望并非如此)。

        Presentation
Contexts:DICOM协议已经有20多年的野史,从19玖三年DICOM标准提议以来,新的网络连接不断地被增添到DICOM协议中。例如一九九陆年引进的MWL服务,即Modality
Worklist
Services(关于WML的描述可参见从前的博文)。因而抢先5分之3DICOM系统只支持DICOM标准中的部分服务,例如PACS系统往往就不会提供WML服务。不一致的DICOM服务用于区别的指标,客户端(SCU)会向服务端(SCP)发送其希望从服务端获得的服务,而服务端会查看其提供的每一项服务是不是是客户端期望的来调控是或不是提供。鉴于以上原因,客户端(SCU)会向服务端发送一雨后鞭笋长度小于12捌的被称为描述上下文(Presentation
Contexts)的信息列表,每二个叙述上下文代表1种客户端期望的劳动。客户端用DICOM标记符来标志各样服务,即SOP
Class UID(Service Object Pair Class Unique
Identifier),在DICOM标准的第6部分有详实介绍。在接连内外文中,被发送的SOP
Class 也被誉为抽象语义Abstract Syntax(一定要与Transfer
Syntaxes中的Syntaxes区分开来,此前在博文http://blog.csdn.net/zssureqh/article/details/39213817#t12的学识储备中有过粗略的比较介绍。在OFFIS的WIKI中对此的叙述原作为In
the context of association negotiation, the 田野(field) where the SOP class is
sent is also called “Abstract Syntax”.),由此Abstract Syntax正是SOP
Class UID的同义词。在传输SOP Class UID(即Abstract
Syntax)的同时,会发送与该服务对应的编码格式,即Transfer
Syntaxes。以乳腺检查的X光片为例,平时乳腺X光片极大,供给展开压缩。客户端在向服务端发送上下文消息时会提必要服务端一种乳腺X光片的滑坡形式,例如JPEG两千,同时也会提供一种被大多数图像传输服务端接受的非收缩方式。如下图所示:

 

图片 16

 

       
该客户端SCU向服务端发送了三种上下文信息(最多不超过1二十六个),每①种上下文音信(Presentation
Context)包括1种客户端期望的劳务以及相关的有余传输形式,例如Presentation
Context ID
第11中学描述了一种数字乳腺X光片存储服务,同时提供了三种编码方式Implicit VRLittle Endian和JPEG
2000(无损压缩)。在客户端用奇数来标示种种上下文音讯(最笔者号为一,最大为25五),平时从一号初阶单调递增,一、三、5、……。至于上下文消息之间的依次以及其内部编码格式的次第可轻巧设定。通过上海体育地方能够看看,每一种服务都必须提供Implicit
V奇骏 Little Endian编码格式,因为那是DICOM协议中私下认可的传输编码格局。

贰)scp.cc源码分析:

       
参照OFFIS论坛中的一篇帖子(http://forum.dcmtk.org/viewtopic.php?f=1&t=4041&hilit=addPresentationContext&sid=d4de67ef5faada44233de627a062d3b7)中对DcmSCP的简便使用,来具体分析一下DcmSCP类的源码文件scp.cc。

第三步,DcmSCP的构造函数。如下图,在构造函数内部,完成了对网络环境的初步化,那与storescp.exe的main函数起初的代码是一律的。

 

图片 17

 

其次步,依据OFFIS官方网址提供的类表明文件,在DcmSCP开放的函数中listen用于落到实处对客户端请求的处理。其他的共用函数从名称上就可以看到诸多是陈设和收获有关参数的函数,不是以set为前缀正是get,所以接下去重点分析listen函数内部的落实。

 

图片 18

 

其三步,进入到listen函数内部。发现listen函数初始部分是用来加载DICOM字典文件的,与storescp.cc文件中DICOM部分的首先步一样。接下来正是有关的服务开启情势(单线程or十六线程,阻塞or非阻塞)。

第五步,随后出现了ASC_initializeNetwork函数,用来初始化网络连接。

第四步,进入到第3个while循环,循环之中调用的是waitForAssociation函数,用来等待客户端的实际连接请求,注意此时的参数也是T_ASC_Network类型的m_net,那或多或少与storescp.exe情状一样。

 

图片 19

 

第伍步,进入到waitForAssociation函数内部,出现的是ASC_receiveAssociation函数,那与storescp.exe源码分析中的第伍步同样。随后出现的也是以ASC_为前缀的多多函数,用来布局网络连接的求实参数。

第八步,参数配置完结后,就是出殡和埋葬响应给客户端,即调用ASC_acknowledgeAssociation函数——与storescp.exe源码分析的第七步一样。

第十步,随后scp.cc内部将拍卖客户端指令的操作封装在了handleAssociation函数内部,必要专注的是此间handleAssociation函数并不要求传递任何参数进去因为T_ASC_Association类型的变量assoc是保存在DcmSCP内部的个人成员变量——那或多或少与storescp.exe直接将assoc变量传递给processCommands函数差别【注二】

 

图片 20

 

第7步,handleAssociation函数内部须求处理的就是DIMSE层面包车型大巴通令交互工作。由此为了全部接收客户端的DIMSE指令,同样出现了第一个while循环,循环之中调用了DIMSE_receiveCommand指令——那与storescp.exe中的processCommands函数内部一样。

 

图片 21

 

第七步,最终进入到了handleIncomingCommand函数内部,依照DIMSE中的CommandSet类型来分别张开C-ECHO和C-STORE的拍卖。

 

图片 22

 

       
至此,DcmSCP的原来的小说件scp.cc分析完结了。通过与storescp.exe的源文件storescp.cc比较发现,两者基本是一样的流程,无非1个是用类来进展了包装,另1个是贯彻了命令行工具。

三)参数字传送递流向

       
为了分明具体传递进程中的错误环节,我们采取回溯的法子,通过回看findPresentationContextID函数中presentationContextID参数的来源来规定难点出现的具体地点。

图片 23

(注:为了便于讲图片旋转了90度,劳烦大家歪着脖子将就着看一下下吧哈)

       
从上海教室中能够看出T_ASC_PresentationContextID参数最后的来自是大家重载DcmSCP基类的handleIncomingCommand函数,因而与storescp.exe中的是贯彻比较,仔细查看该片段的代码,发现了1个一言九鼎问题,原来大家在将storescp.exe工具中的processCommands函数内容拆解到handleIncomingCommand函数内部时,将盈余的DIMSE_receiveCommand函数注释掉的还要,遗漏了讲授掉T_ASC_Association局地变量,使得本来应该通过DIMSE_receiveCommand函数获取的presID变量一向被部分变量覆盖为0——至此难题找到了。

 

图片 24

 

       
那么由于注释掉了剩余的DIMSE_receiveCommand函数,我们从何处来获得presID参数呢。查看一下handleIncomingCommand函数的头发现函数参数中也未有出现T_ASC_PresentationContextID类型的参数。但是相比较scp.cc原本处理C-ECHO请求的函数handleECHORequest大家发现,scp.cc类上将presID的值存款和储蓄在了DcmPresentationContextInfo类型的presInfo变量中。由此我们修改storeSCP的调用,将presInfo.presentationContextID传递进入作为presID的初值。

 

图片 25

 

       
修改形成后,再次调节和测试发现程序运维符合规律,客户端顺遂接受了服务端反馈回来的DIMSE
Message,并且在服务端的目录下也见到了storescu.exe传递过来的dcm文件(当然在storeSCP函数内部依据时间等新闻对文本举行了重命名)。

图片 26

至此上1博文中自模拟storescp.exe工具包的难题已经顺遂消除,利用我们本身包装的ZSDcmStoreSCP类能够轻松地落到实处storescp.exe工具包的功用。

接受(拒绝)连接:

        服务端SCP会至少接受1种上下文音讯(Presentation
Context)以及别的SCU请求的参数(例如AE
Titles)。随后服务端向客户端发送连接响应音讯接受该链接请求。链接音信响应有三种状态:

  • 接受
  • 拒绝(短暂的)
  • 拒绝(永久的)

        连接响应音信会直接拷贝连接请求新闻中的服务端AE Title(即Called
AE Title)和客户端AE Title(即Calling AE
Title)并回到。别的还会回去响应AE Title(即Respponding AE Title),该AE
Title与劳动端AE
Title同样(那是OSI协议中供给的,但是与DICOM协议不一致的是,OSI商业事务中并未有须要双方如出1辙)。

       
当音信响应结果为接受时(即Accepted),服务端SCP会对客户端SCU请求的各类上下文消息(Presentation
Context)举行确认,是接受大概决绝,如下图所示,DICOM标准第玖部分的附录D中付出了二个示意图,作为劳务触发端的DICOM-瑟维斯-User,给出了伍种描述上下文,ID为1、三、伍、7、9;然则在SCP端只帮忙在那之中的二种(ID为一、三、九),并且对于每一种AbstractSyntax服务端只协理个中的1种TransferSyntax。
 

 

图片 27

        如上图所示,要是SCU请求的Presentation
Context被驳回,SCP不会愈加发送任何消息;借使接受了有个别Presentation
Context,SCP会选拔中间的3个传输语义增加到重临新闻对应的Presentation
Context中以布告SCU。假如没有Presentation
Context被接受,那么会发送拒绝新闻,此时结果代码为Rejected。当连接建立达成后,早先准备传输数据体。

       
假诺结果状态码为”Rejected(permanent)“注明服务端SCP文告客户端SCU它的请求被拒绝了,后续也会被驳回。出现那种景色的原故常常由三种,壹种是请求的AE
Title并不存在,也等于说网络中并不设有该实体;另1种是劳务端SCP不支持客户端SCU请求的其他服务(即SOP
Class)。在不肯情状下,SCP可有选取的回来Diagnostic状态码以通告客户端被拒绝的由来;最差的地方下,服务端SCP只回去”Calling
AE Title not
recognized“。在拒绝状态下,DICOM连接就告壹段落了,SCP和SCU不恐怕传输数据;与此同时底层的TCP连接也会倒闭直到客户端SCU再贰次发送连接请求。

3)storescp.cc与scp.cc共同点:

        两者共同的拍卖流程如下图所示,

 

图片 28

 

       
从上海教室能够观望,大家开首的困惑是不利的,利用DcmSCP是能够兑现storescp.exe工具的,这便是说为啥DC高通给出的storescp.exe工具包未有用DcmSCP类来兑现吗?估算有希望是DcmSCP类和storescp.exe工具的开采者是相互工作的,由此也就不可能运用DcmSCP来促成storescp.exe工具了,并且两者的主旨流程是一样的,也没要求对storescp.exe进行再度修改,毕竟该工具的用途有限。

计算分析:

       
本次调试排除错误的历程中发觉,在整合移接分歧文件的代码时要特别的小心细节部分。顺便借着此番传递丢失T_ASC_Association类型参数的难点,我们详细的辨析一下传递战败的T_ASC_Associaton类型参数的效益,怎么轻易的贰个参数字传送递退步,就会促成C-STORE作用失效?

释放(终止)连接:

       
在连接建立未来,连接双方开首实行数据交流。假诺任何1方想终止连接(服务端SCP也得以),有二种方法:

  • 出殡连接释放消息;
  • 出殡连接终止新闻;

       
第二种意况,接收到一而再释放新闻的1方会向释放方发送一条确认音信。随后TCP连接关闭,DICOM连接终止,那是DICOM网络连接中平常的关门措施;第一种情景,客户端发送完舍弃音讯后,不等到服务端的认可就当仁不让关闭TCP连接。那种关闭是非凡的,平常是客户单遇到意外情状后发生的,那是DICOM中唯一1种不供给服务端发送响应新闻的伸手新闻。当然还有第二种中断格局,正是向来关门TCP连接,那种意况屡屡是由于硬件错误所导致的。

模仿营造和谐的C-STORE SCP:

壹)Presentation Context、AbstractSyntax、TransferSyntax细节学习

        在上1篇博文中大家摘录了DICOM3.0正规中有关Presentation
Context、AbstractSyntax、TransferSyntax多少个名词的解释,通俗一点来讲正是Presentation
Context代表的是七个利用实体(AE=Applicaiton
Entity)交互的环境(常常称为上下文),它富含前面包车型地铁AbstractSyntax和TransferSyntax名词。AbstractSyntax与TransferSyntax比较轻巧混淆视听正是因为英文单词中都包涵了Syntax,其实双方完全是分裂的定义,AbstractSyntax关切的是上层音信,即七个相互的AE之间
实行的是何种交互,也便是专业中所说的劳动对象对(SOP)的花色,通过查看dcuid.h文件能够,AbstractSyntax有Store、Query/Retrive、Worklist等类型,例如Store类型的UID_CTImageStorage 、Query/Retrive类型的UID_FINDPatientRootQueryRetrieveInformationModel、Worklist类型的UID_FINDModalityWorklistInformationModel等等。那多少个是大家在C-ECHO、C-STORE、C-FIND服务中常用到的两种;而TransferSyntax关心的是信息传输交互时的编码规则,是Explicit还是Implicit,是LittleEndian还是BigEndian,常见的有UID_LittleEndianImplicitTransferSyntax、UID_LittleEndianExplicitTransferSyntax等等,具体的能够自行查看dcuid.h文件。而地点传递丢失的presID参数便是总结了那两种最根本的相互消息。因此会促成整个C-STORE服务退步。

数据交流(Date Exchange)DIMSE:

       
利用ACSE信息成功建立连接后,即客户端发送的央求至少有一种上下文描述的服务棉被和衣服务端接受,真正的数目开首沟通,例如一张或多张CT图像、worklist查询、打字与印刷请求等。如上所述,DICOM协议规定了1壹种DIMSE新闻,每一种都得以看做客户端的请求或许服务端的响应。1一种DIMSE音信如下:C-CTORE、C-GET、C-MOVE、C-FIND、C-ECHO、N-EVENT-REPORT、N-GET、N-SET、N-ACTON、N-CREATE、N-DELETE。全体的音信都得以被分歧的劳务应用,依据Presentation
Context的叙说,你只须求中间的壹种或二种。

一)间接行使DcmSCP自建C-STORE SCP端:

       
通过上一节的剖析,大家决定尝试选择DcmSCP类来塑造C-STORE的SCP端,来代替storescp.exe工具。

       
利用VS2012创设C++的工程,命名称叫C-STORETest,直接选取DcmSCP类来促成C-STORE的SCP端,具体代码如下:

 

[cpp] view
plain
copyprint?图片 29图片 30

 

  1. // C-STORETest.cpp : 定义调节台应用程序的入口点。  
  2. //  
  3.   
  4. #include “stdafx.h”  
  5.   
  6.   
  7. //add the include files of Dcmtk library  
  8. #include “dcmtk/config/osconfig.h”  
  9. #include “dcmtk/dcmdata/dctk.h”  
  10. #include “dcmtk/dcmnet/scp.h”  
  11. #include “ZSDcmStoreSCP.h”  
  12. #include “global.h”  
  13.   
  14. int _tmain(int argc, _TCHAR* argv[])  
  15. {  
  16.     DcmSCP mStoreSCP;  
  17.     mStoreSCP.setAETitle(“ZS-TEST”);  
  18.     mStoreSCP.setPort(104);  
  19.     mStoreSCP.setVerbosePCMode(true);  
  20.     mStoreSCP.setACSETimeout(-1);  
  21.     mStoreSCP.setDIMSETimeout(10000);  
  22.     mStoreSCP.setDIMSEBlockingMode(DIMSE_NONBLOCKING);  
  23.     OFList< OFString > transferSyntaxes;  
  24.     transferSyntaxes.push_back(UID_LittleEndianExplicitTransferSyntax);  
  25.     transferSyntaxes.push_back(UID_LittleEndianImplicitTransferSyntax);  
  26.     mStoreSCP.addPresentationContext(UID_CTImageStorage,transferSyntaxes);  
  27.     //mStoreSCP.SET  
  28.     mStoreSCP.listen();  
  29.   
  30.     return 0;  
  31. }  

 

 

 

       
编写翻译实现后,张开四个cmd客户端,运转storescu.exe与我们自行建造的C-STORETest举行再三再四,获得的结果如下:

图片 31

       
发现服务端(上海教室左边)给出的不当提醒展现“相当的小概处理该品种的DIMSE请求”,而客户端(上海体育场地右边)呈现一而再被终止(Aborting
Association)。那是如何原因吧?后来透过协调读书OFFIS官方网址关于DcmSCP类的描述后,找到了难题的案由。原来DcmSCP类的达成还处在测试实验阶段,DcmSCP给出的listen函数内部一时只好够处理C-ECHO请求,

 

图片 32

 

 

图片 33

 

       
依照法定的唤醒,要想完成相应C-STORE指令,须要我们手动扩展DcmSCP类。(原来那样,因而看来之所以没有采用DcmSCP来实现storescp.exe工具的的确原因是DcmSCP功用还不周详,并不能够处理C-STORE指令)。

2)storescp.cc与scp.cc全体再对照

       
那么storescp.exe工具包和DcmScp类又是在什么样时刻?什么职位来安装那些参数的吗?上边大家就再叁回相比较分析一下两种工具的兑现流程(细节可参考上壹篇博文DICOM经济学图像处理:storescp.exe与storescu.exe源码剖析,学习C-STORE请求)。

PDU-Protocol Data Units:

       
在DICOM系统总是中,各样DIMSE音讯在传输进程中会被分开成八个部分,叫做Protocol
Data
Unit,简称PDU。PDU的尺寸也是连接建立进度中协商的。每一个PDU片段中会包括一个与Presentation
Context ID相关的数字。大家得以将每一种Presentation
Context看做双方交换的逻辑通道,通过在PDU中隐含Presentation Context
ID,接收端才清楚PDU属于哪2个坦途,技巧将多少个PDU片段进行重组。

2)扩展DcmSCP类处理C-STORE请求:

       
既然找到了难题所在,那么大家就依照官方的说教尝试对DcmSCP实行扩大,加多处理C-STORE指令的一对。直接的想法是将storescp.exe工程中的针对C-STORE请求的处理函数提收取来,增添到DcmSCP的扩张类ZSDcmStoreSCP中。由此在ZSDcmStoreSCP类中增加了函数storeSCP、storeSCPCallback,如下图所示:

 

图片 34

 

       
一样须要对listen函数进行扩大。原本以为只需求重载DcmSCP中拍卖DIMSE具体CommandSet的函数handleIncomingCommand就能够,可是在扩大进程中窥见storescp.exe处理C-STORE的函数storeSCP和storeSCPCallback都要以T_ASC_association类型为参数,而DcmSCP的m_assoc是个人变量并且未有留住大家获得该民用变量的接口,由此不能够将storeSCP、storeSCPCallback函数直接助长到handleIncomingCommand内部。
  

       
为了落实直接动用storeSCP、storeSCPCallback函数,大家必须想方法得到T_ASC_association变量assoc,通过上述对DcmSCP的源码剖析我们能够,在waitForAssociation函数内部调用ASC_receiveAssociation之后,DcmSCP才从T_ASC_Network出得到到了客户端的T_ASC_association连接变量assoc。那么大家是还是不是能够透过重载waitForAssociation函数来提抽出assoc变量呢?在品味那给ZSDcmStoreSCP类增添新的积极分子变量T_ASC_association*
zs_assoc后,将waitForAssociation内部的调用基类DcmSCP中m_assoc的地点统统换到zs_assoc,直接沟通后意识,大家要求重载的不只waitForAssociation三个函数,诸如dropAndDestroyAssociation、negotiateAssociation、refuseAssociation等等函数都需要重新覆盖,关键是waitForAssociation内部的主导函数handleAssociation也要遮盖,因为该函数并不需求任何参数(见上一节的【注2】),其里面一向调用的正是DcmSCP的私房成员变量m_assoc,由此为了提取贰个m_assoc变量,大家须求将DcmSCP基类中的众多函数进行重写,那还算上的是对DcmSCP的派生扩大么?

       
在未有找到很好的化解办法在此以前,小编将waitForAssociation函数和handleAssociation函数内部的源码直接剪切出来一齐停放了listen函数内部,然后用大家风雨同舟的zs_assoc替换掉了DcmSCP的m_assoc,如是从ZSDcmStoreSCP外观上看来笔者只对DcmSCP类的listen函数、handleIncomingCommand函数进行了增添而已,此外将storescp.exe中的storeSCP和storeSCPCallback函数加多到ZSDcmStoreSCP类中,为了使得上述五个函数可以胜利运作,也增加了稍稍storescp.exe中定义的命令行参数变量。

二.一 scp.cc源码文件

        借助上壹篇博文的图形来分析一下DcmSCP类中对此Presentation
Context(即AbstractSyntax和TransferSyntax)的具体操作。

图片 35

        上海教室中付出了DcmSCP类中设置Presentation
Context上下文环境的具体地点和动用的函数。

DIMSE Message Data:

       
各类DIMSE消息所传输的剧情各有分歧,请求音讯(request)中重大不外乎:

  • Message ID:在连接中各样音信的唯1标示
  • Affected SOP Class UID:DIMSE音讯中钦定的SOP Class,即Presentation
    Context中钦点的Abstract Syntax。
  • Affected SOP Instance
    UID:真正传输的实体数据标志符,例如地方例子中关系的乳腺X光片数据
  • Priority:音讯的优先级,分为HIGH
    、NO奥迪Q5MAL、LOW两种,然而当先56%接收端都忽略。
  • Data Set:传输的数目。

       
响应音讯(response)内容与上述接近。首先包含一个场馆信息,例如0代表成功;此外与Message
ID对应的是Message ID Being Responsed To,通过拷贝并赶回请求端的Message
ID,使得接收端知道响应音讯的靶子。

标题浅析:

贰.二 storescp.exe源码文件

       
想必storescp.exe工具包中的安装流程也基本是形似的,接下去我们同样依靠上壹篇博文的图来分析一下。

图片 36

       
比较五个图片大家能够发现DcmSCP和storescp.exe都以在拍卖真的的DIMSE音讯在此以前对连年的Presentation
Context上下文实行配备,至于那样多UID(无论是AbstractSyntax仍旧TransferSyntax都以在dcuid.h文件中用联合的UID来定义的)储存到何地了呢?结缘上一篇博文的解析,大家清楚外部循环开始后首要的着力函数都有一个T_ASC_Association类型的参数assoc(storescp.exe中)或m_assoc(DcmSCP类中),查看一下T_ASC_Association类型的定义,并逐级张开,能够窥见相比我们预料中的如出一辙,该变量中存储了再而三的上下文的全数UID,如下图所示:

图片 37

       
至此大家对此DcmSCP类和storescp.exe工具的源码的分析总算告一段落了,希望咱们能够对DICOM的网络通信服务有3个更深刻的认识。

开源库中相应的达成:

一)ZSDcmStoreSCP不恐怕响应原本DcmSCP能够响应的C-ECHO:

       
将上述成功的ZSDcmStoreSCP类加多到工程中,创造ZSDcmStoreSCP对象,调用listen()函数(具体代码如下),运营服务端程序,一样选取storescu.exe进行客户端模拟,测试发现连C-ECHO也无力回天响应。

 

[cpp] view
plain
copyprint?图片 38图片 39

 

  1. // C-STORETest.cpp : 定义调控台应用程序的入口点。  
  2. //  
  3.   
  4. #include “stdafx.h”  
  5.   
  6.   
  7. //add the include files of Dcmtk library  
  8. #include “dcmtk/config/osconfig.h”  
  9. #include “dcmtk/dcmdata/dctk.h”  
  10. #include “dcmtk/dcmnet/scp.h”  
  11. #include “ZSDcmStoreSCP.h”  
  12. #include “global.h”  
  13.   
  14. int _tmain(int argc, _TCHAR* argv[])  
  15. {  
  16.       
  17.     ZSDcmStoreSCP mZSStoreScp;  
  18.     mZSStoreScp.setAETitle(“ZS-TEST”);  
  19.     mZSStoreScp.setPort(104);  
  20.     mZSStoreScp.setVerbosePCMode(true);  
  21.     mZSStoreScp.setACSETimeout(-1);  
  22.     mZSStoreScp.setDIMSETimeout(10000);  
  23.     mZSStoreScp.setDIMSEBlockingMode(DIMSE_NONBLOCKING);  
  24.     OFList< OFString > transferSyntaxes;  
  25.     transferSyntaxes.push_back(UID_LittleEndianExplicitTransferSyntax);  
  26.     transferSyntaxes.push_back(UID_LittleEndianImplicitTransferSyntax);  
  27.     mZSStoreScp.addPresentationContext(UID_CTImageStorage,transferSyntaxes);  
  28.     //mStoreSCP.SET  
  29.     mZSStoreScp.listen();  
  30.   
  31.   
  32.   
  33.     return 0;  
  34. }  

 

 

 

图片 40

       
从上海教室能够看书,客户端在出殡和埋葬完A-ASSOCIATE-TiggoQ音讯后,再无响应而直接出现了连接请求失利。再度利用上1篇博文中选取的RawCap.exe抓取本地回路数据包,利用Wireshark查看数据包发现,客户端在发送完A-ASSOCIATE-陆风X捌Q后,服务端并未有发送A-ASSOCIATE-奥迪Q7SP,由此规定难题出在了大家和好包装的ZSDcmStoreSCP内部。

图片 41

       
单步调节和测试后发现,在函数推断进度中,assoc->presentationContextList变量为空,由此推断对ASC_receiveAssociation接收到客户端的链接assoc后的ASC_有关安插有标题(参见上一节的【注一】)。

图片 42

       
通过排查发未来拆迁waitForAssociation函数时将ASC_receiveAssociation函数前面包车型大巴多多ASC_发端的函数给漏掉了,将该段代码补充完全(如下图所示),

 

图片 43

 

叁)对新版DC德州仪器中DcmSCP和DcmStoreSCP达成的初阶困惑

       
通过此番利用DcmSCP类的工程意识,该类的布置有些欠妥,开放的接口不够合理,无法轻巧的达成增添来响应C-STORE等别的请求。估量新版的DC高通鲜明会开始展览修改,通过翻看dcmtk三.陆.一的官方认证,发现新版的dcmtk开源库中真的对DcmSCP和DcmSCU基类实行了大的更动,开放了许多新的接口(如下图)方便用户进行增添,其余新版的库中央直机关接提交了打包好的DcmStoreSCP和DcmStoreSCU类,所以大家就毫无使用自家付出的代码ZSDcmStoreSCP类啦,仅供测试使用,具体运用是依然尽快安装新型版的dcmtk开源库吧。

 

图片 44

 

DCMTK:

       
DC高通开源库更偏重于根据层(Layer)来兑现DICOM应用实体(AE)之间的连天(ACSE)及消息传输(DIMSE),首要分为DIMSE(应用层)、ACSE(属于OSI7层协议中的应用层)和DUL(Dicom
Upper
Layer层,该层与OSI中的TCP/IP层对接)三大部分。用户通过动用DC德州仪器提供的DICOM协议中明确的各层的数据结构和操作函数,依据DICOM标准中规定的流水生产线来贯彻和谐的DICOM服务。

       
dimse.h/dimse.cc中付出了DICOM协议中明显的各类劳动对应的结构体,以T_DIMSE_为前缀,例如T_DIMSE_C_StoreRQ/T_DIMSE_C_StoreRSP、T_DIMSE_FindRQ/T_DIMSE_FindRSP、T_DIMSE_CEchoRQ/T_DIMSE_CEcho奥迪Q7SP等;别的给出了各样服务对应的操作函数的扬言,以DIMSE_为前缀,例如DIMSE_echoUser/DIMSE_sendEchoResponse、DIMSE_storeUser/DIMSE_storeProvider/DIMSE_sendStoreResponse等等,具体对应的函数定义被分别位居了独立的文本中,首要有dimecho.cc、dimfind.cc、dimget.cc、dimmove.cc、dimstore.cc。

       
assoc.h/assoc.cc中付出了ACSE应用层的相应结构的包装,以T_ASC_为前缀,例如T_ASC_Parameters、T_ASC_Association、T_ASC_PresentationContext等等;此外给出了相应的三番五次建立或暂停的操作函数,以ASC_为前缀,例如ASC_initializeNetwork、ASC_dropNetwork、ASC_requestAssociation、ASC_receiveAssociation、ASC_acknowledgeAssociation、ASC_rejectAssociation、ASC_releaseAssociation等等。

        在dul.h/dul.cc中付出了Dicom Upper
Layer层的连带数据结构,以DUL_为前缀,例如DUL_ASSOCIATESERVICEPARAMETERS、DUL_PRESENTATIONCONTEXT、DUL_TRANSFERSYNTAX、DUL_PDV、DUL_PDVLIST;别的给出了DUL层的操作函数,一样以DUL_为前缀,例如DUL_InitializeNetwork、DUL_RequestAssociation、DUL_ReleaseAssociation、DUL_ReadPDVs、DUL_WritePDVs、DUL_NextPDV等等。

二)ZSDcmStoreSCP响应C-STORE请求有误:

       
重新编译,利用storescu.exe进行测试,测试结果如下,通过运用Wireshark观望RawCap.exe抓取的数码包能够一定这次C-ECHO请求能够得手响应,然而对于C-STORE的请求在保存dcm文件的时候出现了难点。当前还未查清楚具体难点出今后怎么着地点。

图片 45

图片 46

实例工程代码下载:

1)CSDN财富下载:

连接:http://download.csdn.net/detail/zssureqh/7906309,需求3个积分奥。

二)Github免费下载

连接:https://github.com/zssure-thu/CSDN

 

fo-dicom:

       
fo-dicom开源库更偏重于依据DICOM新闻流来封装,在落到实处了完整DIMSE新闻流框架的基础上,给用户预留了各品级的接口,方便用户继续自定义完成。

       
PDU.cs中付出了ACSE应用层对应的劳动对象,首要有RawPDU、PDU、A-Associate-福睿斯Q、A-Associate-AC、A-Associate-奥迪Q7J、A-Release-哈弗Q、A-Release-RP、A-Abort、PDataTF。

       
DicomMessage为基类派生出的壹各类子类,例如DicomRequest/DicomResponse、DicomCEchoRequest/DicomCEchoResponse、DicomCStoreRequest/DicomCStoreResponse等等;该有的对DICOM协议中明确的各样音信实行了响应的卷入。

       
DicomService类中付出了总体DICOM协议中分明的SCP/SCU之间交互的流水生产线,不过对于不相同的ACSE应用层的总是操作和DIMSE层的音信操作都留出了相应的接口,通过调用后续的回调函数来促成用户本人的来意。

       
IDicomServiceUser/IDicomServiceProvider、IDicomCStoreProvider、IDicomCEchoProvider等为底蕴的1体系接口类,该有的提交了DicomService中一文山会海操作的回调函数接口,具体的落到实处由用户自身达成。

       
DicomClient/DicomServer为底蕴的实体类,该类是用户本人搭建SCP和SCU两端的必须类,可以说DicomClient和DicomServer便是一对简易完毕的DICOM服务的SCU和SCP。例如fo-dicom自带的实例中var
server = new
DicomServer<DicomCEchoProvider>(123四五);就展开了八个端口号为12345的抽取C-ECHO服务的SCP服务端;var
client = new
DicomClient();client.NegotiateAsyncOps();client.AddRequest(new
DicomCEchoRequest());就落实了贰个简练的倡议C-ECHO请求的SCU客户端。

知识点补充:

       
上述storescp.cc和scp.cc中出现了多量的ASC_XXX函数和DIMSE_XXX函数,那与大家前一篇博文分析的DICOM网络通信服务完全结构是相适合的,借着此番达成C-STORE请求响应的进度再一次明白一下DICOM3.0专业中的多少个概念,越发是第1遍面世布局错误时的TransferSyntax和PresentationContext,加深一下明白。

(该片段雷同依旧直接摘抄自DICOM3.0行业内部的英文官方版,同样不做翻译,实在是英文不佳,技术有限,静候国内大牌现身)

Presentation Context– the set of DICOM network services used over
an Association, as negotiated between Application Entities;includes
Abstract Syntaxesand Transfer Syntaxes.

Transfer Syntax– the encoding used for exchange of DICOM
information objects and messages.Examples: JPEGcompressed
(images), little endian explicit value representation.

Abstract Syntax – the information agreed to be exchanged between
applications, generally equivalent to a Service/Object Pair (SOP)
Class.Examples : Verification SOP Class, Modality Worklist
Information Model Find SOP Class, Computed Radiography Image Storage
SOP Class.

Service/Object Pair (SOP) Class– the specification of the
networkor media transfer (service) of a particular type of data
(object); the fundamentalunit of DICOM interoperability
specification.Examples: Ultrasound Image Storage Service, Basic
Grayscale Print Management.

Service/Object Pair (SOP) Instance– an information object; a
specific occurrence of information exchanged in a SOP
Class.Examples: a specific x-ray image.

Presentation Context consists of an Abstract Syntax plus a list of
acceptable Transfer Syntaxes. The Abstract Syntax identifies one SOP
Class or MetaSOP Class (a collection of related SOP Classes identified
by a single Abstract Syntax UID). By listing the Application Entities
with their proposed and accepted Presentation Contexts, the
Conformance Statement is identifying the set of Information Objects
and Service Classes which are recognized by this implementation。

TransferSyntax是Presentation Context属性的一种;

TransferSyntax只对DICOM 音信中的Data Set部分生效。

TransferSyntax是讲述真实世界中1种或两种Abstract
Syntax的编码规则。

 

图片 47

 

一而再专栏博文预报:

1)dcmtk3.6.0的DcmSCP与dcmtk3.6.1的DcmSCP分析,以及dcmtk3.6.1的DcmStoreSCP和DcmStoreSCU的使用

贰)Dcmtk与fo-dicom保存文件的例外设计格局:单线程VS三二十四线程

三)wlmscpfs.exe与findscu.exe的源码剖析:学习C-FIND请求

DICOM3.0专业分析:

备注:

       
原本指望经过扩充DcmSCP类来轻易加高兴的假冒伪造低劣storescp.exe工具,可是在促成进程中发觉dcmtk3.6.0版本中的DcmSCP类设计存在着欠缺,使得后续的存在延续和扩大比较为难。寻找OFFIS的官方网址发现,在近来新颁发的dcmtk三.6.一版本中,竟然给出了DcmStoreSCP和DcmStoreSCU七个C-STORE请求处理类,而且分别派生自DcmSCP和DcmSCU,不晓得OFFIS的大师傅是还是不是对DcmSCP类举办了改换?此起彼伏会对新版DcmSCP与旧版DcmSCP的比较,以及DcmStoreSCP和DcmStoreSCU的使用举行解析,期望找到本文中冒出难题的消除方法(注:在下壹篇博文中再提交完成的ZSDcmStoreSCP类的代码)。

 

(未完待续……)

 

 

PDU vs PDV:

        DCMediaTek三.0专业中对此PDU(Protocol Data
Unit)的解释和概念与地方博文中介绍的等同,但是对于PDV在正式中有三种解释分别是Protocol
Data Value和Presentation Data
Value,作者更偏向于后人。上边博文中牵线的PDU指的是在DICOM连接建立之上传递的信息片段,英文原稿是“If
such a message is transferred on a DICOM connection, they are cut into
pieces, so called Protocol Data Unit
(PDUs).”——这里须求注意的是message,并不仅指咱们所说的DICOM
Message(参见图壹),还包罗了ACSE协议中动用的连接音信,例如A-ASSOCIATION-索罗德Q、A-ASSOCIATION-宝马X五SP、A-ABORT,该类新闻在DICOM三.0探究的第玖部分有详尽的介绍(参见图贰)。

        在图第22中学P-DATA-TF PDU结构中的Variable
Field可变区域才是PDV,即Presentation Data Value。那里PDV指的是DICOM
Message在具体传输进度中被细分的多少个部分(该有的在DICOM3.0正式第⑨片段的附录E中有详实介绍,参见图3,其实正是上文中涉及的DIMSE
Message
Data)。在fo-dicom中的PDU.cs文件中可验证,个中PDU的子类P-DATA-TF的分子中包罗叁个PDV的链表,即List<PDV>。

     
  一句话总括:PDU指的是DICOM协议中的传输的各个音讯(包罗ACSE和DIMSE)的部分,PDV专指DICOM
Message被分开后的有个别,属于P-DATA-TF类PDU中的Variable Field部分。

 

图片 48

 

 

图片 49

图片 50

 

承袭博文预先报告:

1)storescp.exe与sotrescu.exe的源码剖析:学习C-STORE请求(续)
2)dcmtk3.6.0的DcmSCP与dcmtk3.6.1的DcmSCP分析,以及dcmtk3.6.1的DcmStoreSCP和DcmStoreSCU的使用
3)Dcmtk与fo-dicom保存文件的例外设计格局:单线程VS十2线程
4)wlmscpfs.exe与findscu.exe的源码剖析:学习C-FIND请求

ACSE vs DIMSE:

        ACSE是在DICOM三.0中的第7部分介绍,该部分的标题为Network
Communication Support for Message
Exchange,由此得以肯定ACSE首要应用户连接建立阶段。
连接(Association)的树立是四个DICOM实体(AE)之间进行相互的首先步,AEs在创立的一而再上拓展数据编码格式、传输方式的协议。DICOM
AEs利用ACSE-ASSOCIATE服务来确立连接,在ACSE-ASSOCIATE服务中根本使用的是Application
Context、Presentation Context和User Information
Items(在DICOM三.0专业第拾有的的附录叁中有详实的介绍)。ACSE服务重点有A-ASSOCIATE、A-RELEASE、A-ABORT、A-P-ABORT、P-DATA伍类,对应的PDU有A-ASSOCIATE-大切诺基Q、A-ASSOCIATE-AC、A-ASSOCIATE-BMWX五J、P-DATA-TF、A-RELEASE-中华VQ、A-RELEASE-RP、A-ABORT各类。

        DIMSE是在DICOM三.0中的第9局地介绍,该部分的标题为Message
Exchange,由此表明DIMSE是对DICOM传输音信的规定。DIMSE服务类型有C-STORE、C-GET、C-MOVE、C-FIND、C-ECHO、N-EVENT-REPORT、N-GET、N-SET、N-ACTION、N-CREATE、N-DELETE,如下图。

 

图片 51

 

       
有上述相比较能够看来ACSE是DIMSE的基本功,DIMSE是在ACSE之上完结的。正如PDU vs
PDV中关系的,DIMSE
Message是在Association建立落成后,通过ACSE中的P-DATA-TF服务来传输,各类DIMSE
音信会被划分成PDVs放入到P-DATA-TF的Variable Field。如下图所示:

 

图片 52

 

       
最终通过翻看fo-dicom中的Dicom瑟维斯.cs中EndPDU和ProcessPDataTF函数能够有一个更形象的知道,在EndPDU函数内部通过读取PDU的前5个字节来辨别PDU属于ACSE中的哪一种服务,例如A-ASSOCIATE-TiggoQ、A-ASSOCIATE-AC、A-ASSOCIATE-奥迪Q3J、P-DATA-TF、A-RELEASE-MuranoQ、A-RELEASE-RP、A-ABORT;当PDU属于P-DATA-TF类型时,进入到ProcessPDataTF函数内部。通过提取P-DATA-TF
PDU中的Variable
Field中的PDVs来鉴定区别是哪壹种DIMSE音讯,首要有C-STORE-奥德赛Q/C-STORE-ENCORESP、C-FIND-猎豹CS陆Q/C-FIND-陆风X八SP、C-ECHO-本田UR-VQ/C-ECHO-奥迪Q三SP、C-MOVE-卡宴Q/C-MOVE-奥迪Q3SP等等。

 

参考资料:

http://support.dcmtk.org/redmine/projects/dcmtk/wiki/DICOM_NetworkingIntroduction#Protocol-Data-Units,本文英文原来的文章

http://medical.nema.org/medical/dicom/current/output/html/part07.html,DICOM3.0标准第7部分

http://medical.nema.org/medical/dicom/current/output/html/part08.html,DICOM3.0标准第8部分

https://github.com/redmoxie/fo-dicom,fo-dicom源码

http://support.dcmtk.org/redmine/projects/dcmtk/files,DCMTK源码

 

延续专栏博文介绍:

利用PHP Skel结合DCMTK开发WEB PACS应用

选用oracle直接操作DICOM数据

C#的异步编制程序方式在fo-dicom中的应用

VMWare二种互联网连接情势的莫过于测试

相关文章