DICOM医学图形处理：storescp.exe与storescu.exe源码剖析，学习C-STORE请求（续）

最新推荐文章于 2021-11-05 17:26:29 发布

zssure

最新推荐文章于 2021-11-05 17:26:29 发布

阅读量8k

点赞数 7

分类专栏： DICOM DICOM医学图像处理文章标签： C-STORE DICOM DcmSCP c++ dcmtk

本文链接：https://blog.csdn.net/zssureqh/article/details/39237649

版权

本文详细分析了在 DICOM 网络通讯服务中，C-STORE 请求的问题排查过程。通过对比storescp.exe与自定义工具包的调试信息，发现了参数传递错误，特别是presentationContextID参数的丢失导致服务中断。通过单步调试，定位到错误源在于presID参数的获取问题，并成功修复。同时，文章深入探讨了Presentation Context、AbstractSyntax和TransferSyntax的细节，以及它们在DICOM通讯中的重要性。此外，还对新版DCMTK中的DcmSCP和DcmStoreSCP类进行了初步分析，预测了其设计改进。

摘要由CSDN通过智能技术生成

背景：

上一篇博文中，在对storescp工具源文件storescp.cc和DcmSCP类的源文件scp.cc进行剖析后，得出了两者都可以实现响应C-ECHO和C-STORE（需要对DcmSCP类进行扩展）请求的功能。但是在对DcmSCP类进行扩展，期望模拟实现自己的storescp.exe工具时遇到了问题，客户端提示服务中断链接，而服务端显示保存失败，如下图所示。此次博文通过排除该问题再一次对storescp.cc和scp.cc进行对比，主要从Presentation Context、AbstractSyntax、TransferSyntax等细节出发，认真学习DICOM通讯服务。

问题排除：

1）对比分析storescp.exe工具包与自定义工具包的调试信息

为了排除storescu.exe客户端的问题，大致确定问题出现的范围，决定再一次用storescp.exe作为客户端，使用storescu.exe对其发送C-STORE请求，查看storescu.exe客户端的调试信息。与我们的自定义工具服务端的调试信息进行对比。

对比上图中的调试信息，其中红色部分END A-ASSOCIATE-AC表示的是服务端已经顺利的与客户端完成了握手，即网络已经顺利响应了客户端的连接。蓝色部分表示客户端发送的C-STORE-RQ请求也已经顺利的到达了服务端，唯一不同的就是黄色圆圈标记的部分，说明在服务端接收到C-STORE-RQ请求后对其处理有问题。而我们自己封装的ZSDcmStoreSCP类对于C-STORE-RQ的处理函数是直接拷贝的storescp.exe工具内的storeSCP和storeSCPCallback函数。因此大致可以确定问题可能出现的范围。

2）单步调试

在handleIncomingCommand函数内部调用storeSCP指令处插入断点，进入单步调试状态。利用VS2012提供的新的调试工具“并行堆栈”，找到了第一个返回状态cond.bad()为true的地方，即函数ASC_findAcceptedPresentationContext，如下图所示：