DICOM医学图像处理：AETitle在C-FIND和C-MOVE请求中的设置问题

背景：

        最近去医院部署设备，调试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貌似也可以完成类似的功