https://blog.csdn.net/zssureqh/article/details/39098621
The red part is to modify the place, more convenient understand!
Background: The
recently doing related work on debugging worklist queries conducted between the terminal and the RIS PACS system, it is also re-standard DICOM3.0 section on network traffic was read in this week's work will be to sum up, DICOM3.0 to deepen the understanding of standards, from the bottom clearer understanding of the worklist queries, C-STORE, C-FIND and other services.
Points:
1) the term referred to
in this section there will be a lot of abbreviations common noun, so in order to better understand its meaning, to give each term corresponding to the name, there is no carried out with Chinese translation for two reasons, one is because English is very simple, very clear and expressive, the other because there is no standard DICOM3.0 official Chinese version, so I did not rash translation.
Commonly referred to as their full name as follows:
ACSE：Association Control Service Element
AE：Application Entity
CMIS：Common Management Information Service
CMISE：Common Management Information Serivce Element
DICOM：Digital Imaging and Communications in Medicine
DIMSE：DICOM Messsage Service Element
DIMSE-C：DICOM Message Service Element-Composite
DIMSE-N：DICOM Message Service Element-Normalized
HL7：Health Level 7
OSI：Open Systems Interconnection
PDU：Protocol Data Unit
PDV：Protocol Data Value
SOP：Service Object Pair
TCP/IP：Transmission Control Protocol/Internet Protocol
DUL：Dicom Upper Layers
2) DICOM network communication model
DICOM network service is built end to end communications service over traditional OSI seven-layer model, including server and client. The basic model of communications services is shown below:
Compare with the conventional OSI model, it can be seen DICOM3.0 standard DICOM network communication services as described is not included in the OSI seven layer in a simple, but rather from the transport layer / network layer up layers are respectively a detailed description and definitions. The next section I will DICOM3.0 for several parts of the standard are to explain in detail the various layers DICOM network communications services, or that the individual modules.
. 3) DICOM3.0 standard DICOM network communication described
below is given directly DICOM3.0 standard several figures, there is first a whole grasp DICOM3.0 standard, as follows:
从右图可以看出DICOM通讯模型是建立在TCP/IP层之上的，最底层的是DICOM Upper Layer Protocol，该部分主要负责与TCP相对接，在此之上就是DICOM3.0标准给出的DICOM通讯模型，与上一节中的OSI七层模型相比可知，DICOM通讯模型涵盖了会话层（Session）、表示层（Presentation）和应用层（Application）。会话层（Session）主要负责为通讯双方制定通信方式，并创建、注销会话。该部分对应的是DICOM3.0标准中的第8部分，即ACSE（Association Control Service Element）；表示层（Presentation）能为不同的客户端提供数据和信息的语法转换内码，使系统能解读成正确的数据。同时，也能提供压缩解压、加密解密。与之相对应的是DIMSE服务，即DICOM3.0标准的第7部分，该部分给出了众多服务（C-STORE、C-FIND、C-GET、C-MOVE、C-ECHO）的编码格式。
左图是右图中DICOM Upper Layer Service以上服务内部结构的细化，从中也可以看出与之相对应的DICOM3.0的各个部分。下面给出一个更全面的结构示意图：
上图中在简单的对DICOM3.0标准中的截图进行组合后，也给出了DCMTK源码库中与各个层相对应模块的名称，从名称简写上也可以看出整个DICOM网络通信是如何完成的。其中与DICOM通信服务相关的几个文件有dimse.h、assoc.h、dul.h（顺序按照OSI七层模型从上到下），其中dimse.h文件中给出了DIMSE层的各种信息的结构体（如T_DIMSE_Message、T_DIMSE_C_EchoRQ、T_DIMSE_C_EchoRSP等）以及各种服务的函数（如DIMSE_echoUser、DIMSE_sendEchoResponse、DIMSE_storeUser、DIMSE_storeProvider等）。dimse.h文件中定义的各类服务函数，都会有一个关于网络连接的参数T_ASC_Association *assoc，如下图：
从参数类型就可以猜出该类型定义在assoc.h文件中（如下图），assoc.h文件的备注指出该文件为DICOM网络应用提供了连接管理（association management），文件中定义的所有结构都是为了支持连接建立的（如应用上下文、表示上下文（抽象语义、传输语义、最大PDU长度））。在实际通讯的交互过程中，SCP会针对SCU发送的信息，进行逐一回复。如下图所示：
从上图的右侧即为SCP回复的信息，其中，Result表示对提交请求的表示上下文的回复的结果。在assoc.h我们能看到这几个状态的定义
enum T_ASC_P_ResultReason
{ /* Part 8, pp 45. */
ASC_P_ACCEPTANCE = 0,
ASC_P_USERREJECTION = 1,
ASC_P_NOREASON = 2,
ASC_P_ABSTRACTSYNTAXNOTSUPPORTED = 3,
ASC_P_TRANSFERSYNTAXESNOTSUPPORTED = 4,
ASC_P_NOTYETNEGOTIATED = 255
};
同时，文件中也指出了其中的函数利用的是DICOM Upper Layer的服务来实现的。而T_ASC_Association结构就代表一次活动链接。
既然assoc.h头文件已经指明了该模块是在Dicom Upper Layer基础上实现的，因此可以猜到链接的各类函数的源代码实现中必定调用了dul.h文件中的函数，此处已ASC_initializeNetwork函数为例，如下图所示，该函数内部直接调用了DUL_InitializeNetwork函数，想必如果按照上面我们的分析，继续追踪下去的话，一定就会出现TCP层的函数，即我们常用的套接字socket函数（如果读者喜欢可自行查看dul.h中函数的源代码，例如DUL_initializeNetwork函数中通过initializeNetworkTCP函数直接使用了socket的常见操作函数，如socket建立套接字函数、setsockopt设置套接字函数、bind绑定套接字函数 等等）
至此通过查看DCMTK开源库源码，使得我们对上面的整体结构图有了更直观的认识，从而对DICOM3.0标准也有了更好的了解。
实际工程测试：
在查看完DCMTK源码设计后，为了更真实的感受和掌握DICOM网络通讯的过程，此处以常见的PACS与RIS系统之间的worklist查询服务和DICOM的C-STORE图像存储服务为例，对服务端与客户端通讯的真实数据包进行抓取分析，从而更好、更直观的认识DICOM通讯服务。
1）测试工具：
为了仿真DICOM的通讯模型，自然需要构造服务和客户两端，DCMTK开源库的bin中给我们提供了很好的工具。此处选用的工具分两类
| 服务端 | 客户端 |
| wlmscpfs.exe | findscu.exe |
| storescp.exe | storescu.exe |
另外为了与DICOM3.0中对DICOM网络服务的各种结构（如DIMSE、PDU）和指令（A-ASSOCIATION、C-FIND）的详细介绍进行对比，将本地模拟的服务端与客户端的通讯数据包进行了抓取，利用的本地回路抓包工具室RawCap.exe，将抓取的数据包存成pcap文件，然后利用Wireshark工具强大的统计分析功能进行直观的对比分析。
| 本地回路抓包工具 | RawCap.exe |
| 数据包分析查看工具 | Wireshark |
2）worklist查询服务的通讯过程分析
第一步，启动本地回路抓包工具，RawCap.exe 5 dumpfile.pcap（可以利用RawCap.exe -h来查看RawCap.exe工具的使用）
第二步，启动worklist服务端程序，wlmscpfs.exe –d 104 –dfp wlistdb >worklist-server.txt（利用shell的重定向将调试信息保存到worklist-server.txt中）
第三步，启动workist查询客户端程序，findscu.exe –d 127.0.0.1 104 testqry.wl –aec OFFIS >worklist-client.txt（testqry.wl文件是上一篇博文http://blog.csdn.net/zssureqh/article/details/38775315中测试使用的，其中设定了PatientID=123456）
然后等待整个通讯过程截止，RawCap.exe会得到一个名为dumpfile.pcap的数据包文件，另外也会得到服务端和客户端的两个调试信息文本文件，分别是worklist-server.txt和worklist-client.txt。
注意：有些时候利用重定向将调试信息输出到文本文件会发生中断错误，因此也可以直接将结果显示到console窗口，然后将其手动拷贝存储到相应的文件中。我在本机的操作如下图所示：
至此整个数据抓取和信息记录的任务就完成了，接下来就是我们的分析阶段了。
首先直接使用文本编辑器打开两个调试信息文本文件，我在本地的结果如下图所示：
调试信息中也基本给出了我们想要的数据，例如A-ASSOCIATE-AC、A-ASSOCIATE-RQ、DIMSE MESSAGE等。上图中的边缘附件的黄色箭头示意的是两端（即两个DICOM AE）进行真实交流时数据流流过的各层的顺序，这与OSI中的类似。途中红色矩形框表示的1、2、3、4等是DICOM协议层（association）的交互顺序，从数据中可以看出association层对一些底层结构（如PDU、PDV）进行了约定；蓝色框标示的是DIMSE协议层，该层主要定义的是DICOM的各种服务，如C-STORE、C-FIND等。
然后，我们利用Wireshark工具打开dumpfile.pcap数据包文件。
利用Protocol的筛选，我们只观察DICOM协议的相关数据包（有兴趣的可以将整个过程的所有数据包分析一下）。如上图所示，可以清晰的看到findscu客户端与worklist服务端的交互过程。双击其中的第一条交互信息，如下图所示：
此图中可以清晰的看到完整的association层的数据包，如图总红色圆圈所示，01类型代表的正是ASSOCIATE-RQ PDU 类型，而随后紧跟着的就是DICOM3.0第8部分Table 9-11中约定的各个字段。
3）C-STORE服务提供者（SCP）、使用者（SCU）通讯过程分析
该部分的测试流程与2）中worklist查询的测试流程是相同的。
第一步，启动本地回路抓包工具，RawCap.exe 5 dumpfile.pcap（可以利用RawCap.exe -h来查看RawCap.exe工具的使用）
第二步，启动storescp服务端程序，storescp.exe -d 104 -aet OFFIS >storescp.txt（利用shell的重定向将调试信息保存到storescp.txt中）
第三步，启动storescu请求客户端程序，storescu.exe –d 127.0.0.1 104 –f test.dcm –aec OFFIS >storescu.txt（test.dcm是一个标准的dcm文件）
然后等待整个通讯过程截止，RawCap.exe会得到一个名为dumpfile.pcap的数据包文件，另外也会得到服务端和客户端的两个调试信息文本文件，分别是storescp.txt和storescu.txt。
分析过程也与2）中相同，此处就不细说了，只给出结果图。
【备注】：
正是利用上述工具，解决了上一篇博文利用fo-dicom发送C-Find查询Worklist失败的问题。具体的排查过程就是先利用DCMTK开源工具包进行模拟，然后利用工具抓取数据包分析结果，在确定无误的情况下，转而转到fo-dicom环境下，同样抓取数据包分析错误原因。然后单步调试到fo-dicom开源库的C-FInd发起函数CreateWorklistQuery中，确定了问题出现的原因。具体的链接可以参见我的Github：https://github.com/zssure-thu/fo-dicom。该分支中我暂时记录了此次修改的代码，等待后续进一步确认。
