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应用服务器中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）开放的端口是104或11112，dcm4chee会自动将该SCU客户端的AETitle添加到配置中，允许其与dcm4chee建立连接。按照官方说明，修改请求端的端口为11112，再次尝试。C-FIND依然可以返回结果，而C-MOVE却始终无法下载数据到本地。通过查看dcm4chee后台日志发现，总是提示无法建立连接。那么到底是不是dcm4chee服务出的问题呢？。通过使用dcm4che源码中自带的工具包dcmqr.bat发现可以顺利从部署到外网的dcm4chee服务器中下载数据到本地，具体操作指令如下：
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
输出日志截图如下：

在本地c:\test目录下可以看到下载成功的dcm文件。

C-GET与C-MOVE：

既然dcmqr.bat工具可以顺利将数据下载到本地，可以确信dcm4chee服务端实现没有问题。那么到底是哪里出现了问题呢？让我们接着往下看：