背景：

最近去医院部署设备，调试PACS系统，遇到了一个奇葩的问题。基本场景是：医院内部网络情况复杂，多个楼层的诊室都安装了看图端，都需要访问顶楼机房的PACS服务器。起初为了调试关闭了防火墙，并确保各楼层的看图端与PACS服务器之间可以ping通，端口也顺利开放。但是具体部署调试过程中发现“有些楼层可正常进行worklist查询和Query/Retrieve查询，而有些楼层只能正常进行worklist查询，Query/Retrieve查询后本地并未获得图像数据”；第二天尝试后发现“原本正常进行worklist和Query/Retrieve查询的看图端，只能正常进行worklist查询，Query/Retrieve查询后本地无图像数据，而原本Query/Retrieve查询失败的竟然奇迹的可以下载图像了”。

现场排查：

在看图端和PACS服务端已经通过ping和talnet指令分别检测了网络和端口的连通性，所以说明网络硬件环境因素基本可以排除。那么问题多半出在DICOM服务端和看图端配置方面，最糟糕的是系统内部的bug导致（最不希望看到的就是系统的bug，^_^）。首先拷贝PACS服务端与正常看图端的日志文件，与异常的看图端日志文件进行对比分析，如下图所示：

上图中是正常的看图端，可以看到在看图端本地有保存图像的日志记录；而下图中是异常看图端的日志记录，对比上图发现PACS服务端响应看图端的C-Move请求的消息，即C-Move response，顺利到达了看图端，而看图端保存图像数据的信息并未出现。由于发现C-Move response信息能够顺利返回，而图像却不能保存所以猜测有可能是医院网络环境中对于影像数据的传输进行了限制，因为影像传输的数据量较大，但是在跟网管沟通后发现网络方面并未进行任何流量方面的限制。因此第一次排查尝试失败。

既然网络环境没有限制，那么会是那一部分除了问题呢？为了对问题有一个更全面的把握，决定对医院的现有看图端的情况进行统计，希望能够从中找到线索，所以开始逐楼层进行排查。首先从最底层楼层开始排查，此时确保其他楼层并未有人使用看图端。逐个排查后发现有部分看图端依然只能实现worklist查询，Query/Retrieve查询仍然失败，记录失败看图端的IP地址和AETitle，耗费了一整天的时间统计了多个楼层的看图端连接情况。经过整理发现大多数Query/Retrieve查询失败的看图端的AETitle竟然有大面积的重合，因此可以断定大多是由于AETitle的重复而导致的Query/Retrieve查询失败。

问题解决：

随意挑选了AETitle重复的两台看图端，通过修改PACS服务器端和看图端的AETitle发现问题竟然奇迹般的解决了。于是通过观察PACS服务端Dicom节点数据库文件对AETitle出现重复的看图端进行了修改，顺利解决了此次部署。

问题仿真：

现场虽然解决了背景中介绍的奇葩问题，但是并未对问题进行深究，例如既然AETitle有重复，那么为什么所有看图端worklist查询都可以成功，唯独Query/Retrieve查询会失败？既然Query/Retrieve查询失败，那么为什么PACS服务端的C-Move response响应信息会出现在看图端的日志文件中？为了对问题进行一个全面的分析，找到问题出现的根源。因此回来后决定复原“现场场景”，希望通过分析本地的源码找到问题的根源。

利用VMWare复原现场

为了在同一台电脑中同时模拟出多台看图端与PACS服务端，我们需要借助于VMWare虚拟机工具（最近很火的Docker貌似也可以完成类似的功能，但是由于相关工程是基于Windows开发的，所以估计使用Docker来模拟还有一定的困难，如果有大神曾做过类似的模拟，还请不吝赐教^_^）。

一、VMWare本机模拟结构图

如上图所示，利用VMWare WorkStation构建两个虚拟机，模拟现场中出现重复AETitle的看图端；本地安装PACSServer模拟医院的PACS服务器。基本的模拟流程如上图所示，

1）利用GuestOS-1虚拟机向HostOS上传一组数据，因为本地HostOS安装完PACSServer后其中并未存储相关数据，所以需要利用GuestOS-1上传来向PACSServer数据库写入一条数据；

2）利用GuestOS-1查询自己上传的数据，测试环境PACSServer是否正常运行。经测试证明HostOS中的PACSServer运行正常。

随后利用GuestOS-1和GuestOS-2来复原医院现场的情况，

3）GuestOS-1看图端向服务器发起worklist查询服务；

4）GuestOS-1看图端顺利获取到PACSServer中的患者信息；

5）GuestOS-2看图端向服务器发起worklist查询服务；

6）GuestOS-2看图端顺利获取到PACSServer中的患者信息；

7）GuestOS-1看图端向服务器发起Query/Retrieve请求；

8）GuestOS-1看图端顺利获得C-Move response及图像信息；

9）GuestOS-2看图端向服务器发起Query/Retrieve请求；

10）GuestOS-2看图端顺利获得C-Move response，但是并未获得图像信息；

至此成功复原了当时的现场，为本地调试做好了准备。

二、VMWare虚拟机GuestOS与HostOS之间网络连接（局域网）

为了实现上述结构图中的模拟，需要在GuestOS虚拟机与HostOS之间建立连接。VMWare虚拟机的网络连接有三种方式：Bridge模式、Host-Only模式、NAT模式。博文（http://www.cnblogs.com/xiaochaohuashengmi/archive/2011/03/15/1985084.html）和博文（http://zhaisx.iteye.com/blog/458671）中对该三种模式有简单的介绍，大家可以仔细阅读，此处我选用的是Host-Only模式，HostOS主机的VMware
Network Adapter VMnet1的IP地址是192.168.24.1，GuestOS-1的IP地址是192.168.24.100，GuestOS-2的IP地址是192.168.24.200.

Dicom Network源码分析（基于mDCM）

此处的DicomViewer看图端和PACSServer服务端采用的是C#编写的mDCM开源库。为了解决上述问题，此处对mDCM开源库中Dicom Network的相关类进行分析，对mDCM中DICOM网络服务的实现流程有一个宏观的认识，期望能够快速找到上述问题的根源。

从Github上下载mDCM的源码，利用VS打开（如下图）。找到mDCM中关于DICOM网络服务的文件夹Network，可以看到mDCM按照Client和Server将DICOM网络服务的实现类分成了两部分。

上图中的各个类之间的继承关系如下所示，

此处通过对PACSServer服务端的实现来剖析一下mDCM的相关类，对于客户端分支的相关分析此处就不做介绍了，客户端的流程比服务端要简单，主要是一个主动连接及被动接收服务端应答的过程，相应的处理函数也比较少，有兴趣的同学可自己浏览mDCM源码。

从上述表格中我们对mDCM实现DICOM网络服务的流程有了一个基本的把握，下面从真实的PACSServer实现代码入手，给出具体的相关DICOM网络服务流的流向示意图，如下图所示：

上图中ServerProc到Process到ProcessNextPDU到ProcessPDataTF到ProcessDimse的流向就是mDCM对DICOM网络服务实现的控制流，并且上述四步控制，即ServerProc、Process、ProcessNextPDU、ProcessPDataTF、ProcessDimse，都是表格中所提到的各个类中的私有函数，言外之意就是我们不能够随意更改整体处理流程，但是对于各处理部分相应的处理函数可自由定制。

通过上述的剖析我们对mDCM的具体实现有了一个深刻的了解，那么接下来就是分析问题根源的时候了。对于Query/Retrieve请求，发出的是C-MOVE Request，那么从上图流向中我们可以定位到PacsSCPImpl类中的OnReceiveCMoveRequest函数内部，插入断点，单步调试。具体流程为：1）启动PACSServer进入调试模式；2）利用GuestOS-1虚拟机中的DicomViewer发起Query/Retrieve查询；3）PACSServer进入到OnReceiveCMoveRequest函数内部；按照同样的流程启动GuestOS-2的看图端发起Query/Retrieve请求，通过对比观察两次调试时刻的成员变量和局部变量发现，由于GuestOS-1和GuestOS-2中的AETitle相同，PACSServer服务端内部在数据库检索时刻搜索到第一个对应的AETitle对应的客户端IP地址后就退出了，因此对于GuestOS-1和GuestOS-2中的AETitle相同的情况，永远是在服务器数据库中顺序靠前的那一个看图端可以顺利完成Query/Retrieve查询请求。通过修改PACSServer服务端数据库中GuestOS-1和GuestOS-2的顺序得到了验证。

那么还有另外一个问题就是：失败的GuestOS-2中的DicomViewer日志文件中为什么会接收到C-MOVE Response信息呢？再次按照上述方法进入到单步调试模式，发现在相应客户端发起的Query/Retrieve请求时，对于应答的发送使用的是DcmNetworkBase基类中的SendCMoveResponse函数，该函数对于C-MOVE response信息的发送是根据PACSServer服务端监听套接字接收到的客户端套接字来完成的，因此并未通过查询服务端数据库中的AETitle来获取客户机的IP地址。

至此对于此次奇葩问题有了一个完美的解答，最后总结一下。虽然mDCM库中对于信息的发送有的是通过查询数据库来获取目的地IP地址，有的是直接利用客户机的套接字来获取IP地址，按理来说如果是直接利用套接字中的IP地址来发送消息（如上述的SendCMoveResponse）看图端中的AETitle是可以相同的，但是随着医院信息系统的扩展，看图端数量的增加，建议还是按照DICOM3.0标准来设置不同的AETitle以区分网络中的各终端设备。如果不是此次现场部署的医院看图端足够多（原本的设计是根据IP地址的最后一位添加“SCU_”前缀来命名各个看图端，没想到的是医院每个楼层都有上百台看图端，因此导致只以IP地址最后一部分为后缀的AETitle命名方式出现了重复）也不会发现PACSServer服务端程序中的问题。

备注：

1）VMWare虚拟机安装Win7出现“GCDROM not loaded”错误

搜索了网络上的部分资料，最后从WinPE启动进入后，对虚拟机的硬盘进行格式化和分区，然后利用WinPE中的安装工具成功在VMWare虚拟机中安装Win7操作系统。

2）后续博文介绍

Dicom中的MPPS服务介绍

C#的异步编程模式在fo-dicom中的应用

VMWare三种网络连接模式的实际测试

作者：[email protected]

时间：2014-09-28