DICOM:C-GET与C-MOVE对照剖析

背景:

之前专栏中介绍最多的两款PACS各自是基于dcmtk的dcmqrscp以及Orthanc。和基于fo-dicom的DicomService(自己开发的)。该类应用场景都是针对于局域网,因此在使用DIMSE-C各项服务时并未遇到的复杂问题,学习和使用成本相对较低。

通过近一年的时间也已经对C-ECHO、C-FIND、C-STORE、C-MOVE、N-PRINT等各项服务都进行了详细介绍,而且从DICOM标准来看C-MOVE服务能够包括C-GET,因此今天之前专栏中从未介绍过C-GET服务。

最近因为项目须要,開始频繁接触基于dcm4che的dcm4chee服务。通过托管于JBoss AS应用server中dcm4chee能够为互联网用户提供DICOM服务(注意差别于之前介绍的Orthanc的RESTful服务,以及DICOM标准中的WADO协议)。

通过直接将DICOM服务部署到外网主机中来实现web的PACS服务,因为DICOM协议本身是建立在TCP上,所以从理论上这样的DICOM服务的web化是可行的。

起初在对接C-FIND、C-STORE等服务时也非常顺利,与常规的局域网操作全然同样。无非就是訪问的对端AE节点IP地址是公网IP而已。可是在进行C-MOVE操作时,却总是无法成功。

dcm4chee的AE Title配置服务:

起初以为dcm4chee对C-MOVE的实现有问题。于是自己在本地Ubuntu虚拟机中搭建部署了一套dcm4chee服务。

通过单步调试,以及检索dcm4che官网,找到了部分线索:dcm4che的AE Title Configuration Service

如官网中所述。dcm4chee因为部署到互联网中,相较于局域网须要配置SCU和SCP各自AETitle信息的情形,dcm4chee额外加入了一种自己主动配置模式,即假设请求端(即不论什么SCU)开放的port是104或11112。dcm4chee会自己主动将该SCUclient的AETitle加入到配置中,同意其与dcm4chee建立连接。依照官方说明。改动请求端的port为11112,再次尝试。

C-FIND依旧能够返回结果。而C-MOVE却始终无法下载数据到本地。通过查看dcm4chee后台日志发现,总是提示无法建立连接。那么究竟是不是dcm4chee服务出的问题呢?。通过使用dcm4che源代码中自带的工具包dcmqr.bat发现能够顺利从部署到外网的dcm4cheeserver中下载数据到本地,详细操作指令例如以下:

dcmqr DCM4CHEE@XXX.XXX.XXX.XXX:11112 -cget -nocfind -q0020000D=1.3.6.1.4.1.30071.6.10987654321.1234567890 -cstore CT -cstoredest c:\test

输出日志截图例如以下:

DICOM:C-GET与C-MOVE对照剖析

在本地c:\test文件夹下能够看到下载成功的dcm文件。

C-GET与C-MOVE:

既然dcmqr.bat工具能够顺利将数据下载到本地,能够确信dcm4chee服务端实现没有问题。

那么究竟是哪里出现了问题呢?让我们接着往下看:

同样使用dcmqr.bat工具,输入下述指令:

dcmqr DCM4CHEE@XXX.XXX.XXX.XXX:11112 -cmove ZSSURE -nocfind -q0020000D=1.3.6.1.4.1.30071.6.198690283870599.4896581024566519 -cstore CT -cstoredest c:\test

却总是提示无法识别Move Destination AETitle:ZSSURE,例如以下截图所看到的各自是dcm4chee服务端和dcmqr.batclient的额输出日志:

DICOM:C-GET与C-MOVE对照剖析

DICOM:C-GET与C-MOVE对照剖析

至此应该能够大致确定问题出如今C-MOVE服务的实现机制上,通过dcmqr.bat工具的測试。能够确定C-GET服务能够顺利从部署到互联网的dcm4cheeserver下载数据,而C-MOVE服务无法实现。



以下就详细分析一下C-GET与C-MOVE的差别:

DICOM:C-GET与C-MOVE对照剖析

DICOM:C-GET与C-MOVE对照剖析

从DICOM3.0标准官方描写叙述中能够看出,两者的目的是同样的。且主动发起请求方(即SCU)的起始操作是同样的——都是从SCP端查询匹配项。

可是随后的子操作不同。在C-GET SERVICE中的描写叙述是子操作的触发在同一个连接中(on the same Association);而在C-MOVE SERVICE中的描写叙述是子操作的触发在单独的、另外的一个连接中(on a separate Association)

为了更清楚的描写叙述两者的差别,请看以下两幅示意图:

DICOM:C-GET与C-MOVE对照剖析

DICOM:C-GET与C-MOVE对照剖析

图中用双向箭头来示意详细C-GET和C-MOVE服务中所建立的TCP连接数;单项箭头分别表示详细服务中的RQ和RSP,依照官方说法C-GET和C-MOVE服务都是确认服务(Confirmed Service),所以单项箭头都是一一配对的,正常情况下一个RQ相应一个RSP;单项箭头标记的数字表明C-GET和C-MOVE服务详细请求过程中的各消息发送时序。

fo-dicom(mDCM)实现C-GET:

之前分析过fo-dicom(mDCM)库中实现DICOM协议的各种关系。简单来说类就是对某种操作以及操作所需的数据的一种封装,从上面的结构图分析以及官方DICOM3.0标准来看,DICOM协议中的操作主要就是建立&关闭TCP连接、发送&接收请求、读取&解析套接字信息(DIMSE)。以及相关异常处理等等,所以总体的操作都被放到了DcmNetworkBase类中。然后依据不同的角色(即SCU和SCP)。分别派生出DcmServiceBase和DcmClientBase,直至最底层的DcmServer和DcmClient。

简单的类图例如以下所看到的:

依据背景中的描写叙述,我们这里扮演的是C-GET SCU角色。即须要派生DcmClient。细致查看fo-dicom(mDCM)源代码发现当中并未实现C-GET相关的不论什么client(SCU)和服务端(SCP)类的封装。为了借鉴现有经验又查看了一下dcmtk和dcm4che的源代码,仅仅有dcm4che提供的dcmqr.bat工具包中嵌入了c-get服务。

通过查看DICOM标准第7部分可知,C-GET服务于C-MOVE服务除了在Association上不同以外。其它參数以及操作流程差点儿全然同样。

既然fo-dicom(mDCM)中给出了CMoveClient类,那么我么直接借用CMoveClient类来编写CGetClient类。

起初直接拷贝了CMoveClient类源代码。去掉了当中关于第三方DestinationAE的相关成员变量,在測试过程中总是出现Association.Available==0的情况,例如以下图所看到的:

DICOM:C-GET与C-MOVE对照剖析

后来通过对照DICOM标准以及上述分析发现。在CMoveClient类中并未实现DcmNetworkBase类的OnReceiveCStoreRequest方法,而C-GET服务依照我们之前的分析须要在同一个Association中处理来C-GET SCP的C-STORE SCU,因此对CGetClient类的OnReceiveCStoreRequest进行扩展。加入保存DcmDataset到.dcm文件的代码(注:这里为了方便用户后期扩展,将详细的实现放到了代理delegate中。由用户在Dicom.dll库外部自己定义实现)
大致的代码例如以下所看到的:

        protected override void OnReceiveCStoreRequest(byte presentationID, ushort messageID, DicomUID affectedInstance,
DcmPriority priority, string moveAE, ushort moveMessageID, DcmDataset dataset, string fileName)
{
try
{
if (OnCStoreRequest != null)
OnCStoreRequest(presentationID, messageID, affectedInstance, priority, moveAE, moveMessageID, dataset, fileName);
SendCStoreResponse(presentationID, messageID, affectedInstance, DcmStatus.Success); }
catch (System.Exception ex)
{
SendCStoreResponse(presentationID, messageID, affectedInstance, DcmStatus.ProcessingFailure); }
Console.WriteLine("c-move c-store RQ!");
}

加入OnReceiveCStoreRequest实现代码后。再一次连接dcm4cheeserver后能够看到顺利接收到了DcmDataset并保存到本地.dcm文件。

至此CGetClient类的封装工作就完毕了。

知识点补充:

TCP全双工:

全双工协议(即Full-Duplex Transmissions),是指通信时同意两个方向同一时候传递数据,他相当于两个单工通信。它要求发送设备和接收设备都有独立的接收和发送能力。

通熟点来讲在通信时能保证在随意时刻两方都能听到对方的声音。(摘自《全双工和半双工的差别》)。TCP协议就是全双工协议,因此在上述实现C-GET请求时能够再同一个TCP连接中(即Association)实现C-STORE和C-GET。

外网VS内网:

IP地址资源紧张,255.255.255.255形式的32位地址已经远不能标识互联网中的全部主机。而外网和内网的划分在一定程度上攻克了IP地址资源紧张的问题。每一个内网通过路由映射到一个外网IP地址,内网中的主机经过路由器之后才干訪问外网,而对外他们仅仅耗费了一个外网IP地址资源。

常见的内网IP有以下几种类型:

10.0.0.0~10.255.255.255

172.16.0.0~172.31.255.255

192.168..0.0~192.168.255.255


所以仅仅要拥有外网IP。就能够直接连接互联网,而不须要经过路由器或交换机。因为外网IP资源宝贵,且属于全球化资源,因此外网IP一般都是用于公司企业、学校、*等机构。除了上述三类内网IP以外的地址都是外网IP

外网訪问内网:

自媒体的火热,以及Github、Gitlib等的普及,人人都希望建立自己的独立博客、独立站点。

之前博文介绍的就是一种公布个人站点的一种方式。这样的方式费用较高,须要购买server(拥有外网IP的主机),能够简单的觉得就是购买外网IP地址,以及域名。大家能够訪问www.zssure.me体验一下我搭建的个人主页。

那么除此以外有没有其它方法能够公布个人主页呢?搜索一下就能够看到非常多博文介绍怎样使用路由的虚拟server(即port映射)来实现外网訪问内网的功能呢,如是也能够简单的公布个人主页。当然这样的方式的危急系数高,易受到黑客攻击,不建议大家使用。

关于从外网直接訪问内网的设置可參见路由器实现外网訪问内网

大致的流程是利用路由器的虚拟server功能,进行port映射,实现外网IP地址到内网IP+port的一一映射。从而实现外网直接訪问内网的目的。示意图例如以下(图片来源于路由器实现外网訪问内网):

DICOM:C-GET与C-MOVE对照剖析

DICOM:C-GET与C-MOVE对照剖析

内网訪问外网:

内网訪问外网的情况就比較常见。诸如公司、学校等机构局域网内能够上网的都是内网訪问外网。通常通过NAT(Network Address Translation)来实现。百度百科对NAT的描写叙述例如以下:

NAT(Network Address Translation,网络地址转换)是1994年提出的。当在专用网内部的一些主机本来已经分配到了本地IP地址(即仅在本专用网内使用的专用地址),但如今又想和因特网上的主机通信(并不须要加密)时。可使用NAT方法。

这样的方法须要在专用网连接到因特网的路由器上安装NAT软件。

装有NAT软件的路由器叫做NAT路由器,它至少有一个有效的外部全球IP地址。这样,全部使用本地地址的主机在和外界通信时,都要在NAT路由器上将其本地地址转换成全球IP地址。才干和因特网连接。

另外。这样的通过使用少量的公有IP 地址代表较多的私有IP 地址的方式,将有助于减缓可用的IP地址空间的枯竭。

在RFC-1632中有对NAT的说明。

利用NAT有两大优点。各自是宽带分享和安全防护。

对内能够多台主机共享一条宽带。对外多带主机相应一个公网IP,因此当受到外网攻击时无法确定相应的单一主机。(这也就是C-MOVE请求訪问基于WEB的dcm4cheeserver终于失败的原因。

虚拟server:

VPN:

对于虚拟server和VPN的介绍临时搁置一下,因为后期须要手动搭建VPN服务因此放到下一篇博文中再介绍。敬请期待!

PS:能够对照之前专栏中的博文DICOM医学图像处理:AETitle在C-FIND和C-MOVE请求中的设置问题来分析一下内网与外网的差别。这里特此说明当时的一种解决方式(即利用TcpClient来直接反推IP地址)的做法是有局限性的,在局域网中是可行的,在互联网大环境下会失败。

修正:博文中C-GET服务示意图中C-GET-RSP、C-STORE-RQ、C-STORE-RSP等消息的流程是错误的,详情能够參见兴许的博文DICOM:C-GET服务

作者:zssure@163.com

时间:2015-07-13

上一篇:Android常用控件


下一篇:JVM调优——之CMS 常见参数解析