DICOM：C-GET与C-MOVE对比剖析（续）

背景：

专栏之前剖析过DICOM协议的C-GET服务与C-MOVE服务，两者最大的区别在于C-GET是基于单个TCP连接的点对点的两方服务，而C-MOVE是基于两个TCP连接的三方服务，详情参见之前的专栏博文DICOM：C-GET与C-MOVE对比剖析。
近期在将相关DICOM服务，例如CStoreSCP、CMoveSCP，MppsSCP等，Docker化并Web发布时又遇到了一个问题，大致情形如下：

通过Tomcat的Servlet来响应DICOM的C-MOVE-RQ请求，但是由于CMove操作完成耗时较长，易导致页面超时失效。

尝试解决方案：

基于之前对于C-GET和C-MOVE服务的剖析，了解了C-MOVE的三方通信机制，如下图所示：

图中所示CMOVE是基于两个独立的TCP连接进行通信，其中真正进行数据转移的（即CSTORE服务）TCP连接（即上图TCP2、Socket2）是导致上述 “页面超时失效”的问题的根源，单纯传输CMOVE结果状态的效率是很高的。 既然如此，是否可以在发送了C-MOVE-RQ请求后，直接关闭TCP1连接，使得CMove函数直接返回，而CSTORE服务依然在继续，当然该做法会导致无法掌握CSTORE服务的完成状况。。