【网络】简述Dicom设置
1、DICOM接口就是通常所说的“数字口
”。“DICOM”是英文&
“Digital&&
Communication&&
in&& Medicine ” 的缩写。DICOM标准是由ACR
(American College of Radiology)以及NEMA(National Electrical
Manufacturers Association)联合委员会， 于1983年以后陆续发展而成的医疗数字影像及传输标准。
&2、DICOM标准建立的目的:
推动开放式与厂牌无关的医疗数字影像的传输与交换。促使影像储存与传输系统PACS (Picture Archiving and
Communication Systems) 的发展与各种医院信息系统HIS (Hospital Information
Systems) 的结合。允许所产生的诊所资料库能广泛地经由不同地方的设备来访问DICOM。
&3、对于DICOM3.0数字接口，使用标准通讯协议采集图像，图像信息完全不丢失。用DICOM影像最大的优势还在于能调节窗宽、窗位，充分利用设备采集到的丰富信息帮助诊断。而胶片是固定的，医生当时看时可以，调好了窗宽窗位打成胶片，病人复诊时就看不到更多的信息了。还有，对于确实难以下结论的模糊病例，还提供了快速参考其他诊断结果的途径。
&4、DICOM中有11种不同的服务类（Service
Class），例如打印(Printing)、传输（Move）、存储（Store）、存档（Archiving)
等。某一服务类中又分为使用者（User、SCU）和提供者（Provider、SCP），某一设备可能仅符合其中的某一个或某几个类。比如：
& a：通常的设备操作台(Operator
Console) 仅符合 DICOM的存储类及传输类，它仅作为SCU而不是SCP，且不符合DICOM
3.0的打印服务类(Service Class for Printing)。
& b：存档服务器 (Archiving
Server)是存档类的提供者（Archiving SCP）。
c：影像工作站是存储类的提供者（Storage SCP）。
&二、前期准备
&1、为了深入了解影像设备在DICOM方面的性能，在购买影像设备(如CT)时就必须要求厂家提供“DICOM设备的一致性说明(
Conformance
Statement)”。这是连接设备所需的重要资料。即便如此，在实际工作中还是要遇到不少问题，例如在将一台工作站接入系统时，发现尽管它是传输服务类的提供者和使用者，但在实际上对一些后处理图像却不能以DICOM方式传送。
&2、首先要确认，影像设备(如CT)支持不支持DICOM3 Storage
SCU，如果支持，DICOM的发送功能（Storage SCU）是否已经开放。
&a：主要是1997年以后购买的高档影像设备，包括CT、ECT、MR、CR、DR、DSA及彩超等（下面就简称“影像设备”），才可支持DICOM3发送功能。
&&b：很多DICOM接口设备没有安装发送模块，或者安装了但在软件上都是经过加密的，或者其DICOM接口被封闭，一般只有向生产商提供五千到一万美金才能向用户开放密码，一般都要通过非正常手段解决此类问题。
&3、支持DICOM
存储服务类的设备(如CT)，取得密码后，要设置AET（Remote Application&
Entity Title），IP地址/远程机名，Port口等信息。
&4、这些影像设备(如CT)多数采用UNIX操作系统，UNIX存在很多版本，例如AT&T的版本、UCB的BSD
UNIX、SUN MICROSYSTEMDE 的SUN OS、IBM的AIX、HP的HP-UNIX、SANTA CRUZ公司的SCO
UNIX及SIEMENS公司、日本东芝、日立、松下等公司开发的UNIX等等。目前我国熟悉UNIX操作系统的人员很少，即使懂得UNIX也并不一定能解决在连接中的大部分问题。
&5、有时某些影像设备(如CT)传过来的图像没有原始的窗宽和窗位，这需要在影像设备的软件中设置一下。例如在传GE
DR的时侯碰到过一次，要在DR RF上设置，这要问厂家的工程师，因为这和他们软件发送图象时设置的参数有关。
&6、CT、MR、DSA、DR、CR及彩超等高档医学影像设备价值少则几百万，多则几千万，没有丰富的连接经验，一旦造成影像设备瘫痪，维修费用昂贵，且耽误医院正常的工作，没有一定的施工经验，难以连接成功，甚至造成医学影像设备瘫痪，造成不可挽回的损失。因此在施工过程中必须万无一失。
&7、综上所述，连接DICOM接口工作站，技术上只是一个方面，而人际关系至关重要，首先要有使用大夫的积极配合，其次要与影像设备厂家的的工程师密切关系，让他把DICOM参数设置好（分配一个IP地址（对应于远程机名），AET、Port口等信息），然后才能连接符合DICOM标准的工作站。
&8、传统胶片的像素尺寸非常小，其分辨率大约为5.0LP／mm，目前CR图像的空间分辨率则达到了6.0LP，像素矩阵至少要求，这就要求作为取代胶片成为诊断图像载体的显示器必须具有非常高的分辨率，且作为一个工作站的显示器数目以2－4台为宜。CT图像分辨率一般是512*512的，好一点的普通显示器就能满足诊断标准了，比如用SONY的E230等。而CR、DR的分辨率一般是，用2k*2.5k的竖窗就能满足诊断要求。
&9、医学影像的数据量大，CT图像一般为0.5MB、CR图像一般为8MB、DR图像一般为16MB，数字化乳腺图像可达到40MB，1例DSA的资料可达GB数量级，并且还有多种新的成像设备在不断投入使用，因此，医学影像的数据量还在急剧上升，医院每天可产生达到几个GB的数据，因此必须有大容量存储器才能支持。
&10、除上面提到的需要准备特别的显示器和大容量的硬盘（或者一个独立的存储服务器），还要准备用于联网的网卡、网线和/或HUB、交换机等。联网完全类似于本系列（随心所欲版）软件的“网络版”局域网连接方法，影像设备(如CT)本质上就是一台计算机。设置AET、IP地址/远程机名、Port口等信息也完全对应于本系列软件“网络版”的第一次手工运行cimgs、服务器名、端口号，祥见“软件(网络版及单机版)的安装.doc”文档。
三、连接步骤
&1、工作站如同本系列软件“网络版”的局域网连接方法，分区、格式化、安装操作系统，插入网卡，安装各类驱动。
&2、分配工作站IP地址，设置工作站标识(计算机名及组名),
注意准备联网的所有机器的IP地址和机器名应唯一，并且IP地址的前三位数字尽量与影像设备(如CT)的IP地址的前三位数字相同，组名也尽量与影像设备(如CT)的组名相同。注意计算机名是指“完整的计算机名称”而不是其“描述”)。
&3、确保网络正常运行。使用“ping&&
对方IP地址”或者“ping&& 对方
计算机名”命令（有些操作系统也可以使用[查找计算机]查找对方机器名）来检查网络是否连通。从工作站ping影像设备(如CT)，以及从影像设备(如CT)ping工作站都必须成功，因为这时还没有涉及到DICOM通讯，如果ping都不能成功，说明硬件连接（比如高速公路）还没有成功，所以更谈不上后面的通讯了（比如汽车）。如果ping不成功，请检查工作站操作系统的安装，网卡是否正确插好，网卡驱动是否安装正确，不行再换换计算机名和IP地址的设置。有些影像设备(如CT)需要先允许（Enable）并激活（Activate）网络才可进行上面的操作。
&4、设置影像设备(如CT)参数，正如第二、7条所说的那样，通常需要厂家工程师的配合，否则要在不同的菜单中来回查找，找到诸如“Service
Mode”、“NetWork”或“DICOM”选项，或者键盘上有“Setup”之类的按键，绝大多数情况下，需要密码，进入“厂家设置”或者“Service
Mode”或者“NetWork”等，找到诸如 “Storage& Device”
或者“Store& Mode”或者“Remote
Host”之类的项目（不同设备使用的名词不完全一样，大多数都使用黑体字所标的名词），如果没有默认的则创建一个新的。最后设置一些参数，这些参数也会因不同型号的机器而有所不同，但一般需要设置三个参数，即AET、IP地址/远程机名、Port口。“AET”就是工作站软件的名字，默认为“STORESCP”，“IP地址/远程机名”就是工作站的IP地址和/或者计算机名（见上面的第2条），Port口就是工作站的端口号，一般使用104。也可以不改这三个参数，而在工作站软件中将DICOM参数改成该值。另外还可能要设置其他参数，例如影像设备(如CT)自己的AET，选择所提供的服务类，工作站是DICOM
Storage SCP（提供者），影像设备(如CT)是DICOM Storage SCU（使用者）。
&5、运行本软件，这时就可以在影像设备(如CT)上选择一幅图像（image），发送出去（仍然是不同设备使用的名词不完全一样，诸如push
archive或send或copy或transfer或move,等等），可能还要选择一下目标机器，即选择本工作站，然后确认，等待接收结束即可。工作站应处于新建病例后的主界面。
&6、总而言之，首先能ping通网络，其次让影像设备(如CT)与工作站软件的DICOM三个参数（AETitle、机器名/IP地址、Port）一致，最后在影像设备(如CT)上向工作站发送图片即可。
&影像设备(如CT)如果没有默认的
“Storage” /“Host”设备，则创建一个新的，如果“Storage”
设备有默认的DICOM三个参数，推荐不做修改，而修改工作站“系统设置”中的DICOM三个参数，使它与之一致。如果没有默认的DICOM三个参数，则设置它，同样再修改工作站“系统设置”中的DICOM三个参数，使它与之一致。如果涉及到工作站的机器名和/或者IP地址的修改，请退出软件，右击桌面上的[网上邻居]或者[我的电脑]进行修改。简言之，双方的DICOM三个参数必须一致。
&7、务必先在公司里随便找一台计算机代替影像设备(如CT)，与工作站联网，调试网络直到双方都能访问对方为止（ping&
和“查找计算机”两种方法均可实现才行）。
&再用光盘工具文件夹“DICOM发送测试”来模拟影像设备(如CT)发送图片进行测试。“DICOM发送测试”应进入[我的电脑]或者[资源管理器]在文件夹中直接运行DCMSend.exe，请不要创建桌面的快捷方式，否则找不到测试用的DICOM文件。到医院之前最好还要注意准备两种网线，直通的和交叉的。
&8、如果对方机器为Encapsulate（压缩方式），推荐解压后发送。如果非得使用压缩方式不可，则本软件也应改为相应的传输语法，请在参数设置“AE
Tittle\Port”中，在“AE Tittle”和反斜杠之间增加“ +xs ”、“ +xy ”、“ +xx ”或者“ +xr
”其中之一进行尝试，注意前后都有空格。
例如，如果使用默认的AE Tittle和Port，则增加“ +xs ”后为:
&&&&&“STORESCP&
+xs& \104”。
&9、对于发送DICOM图片到其他DICOM设备，例如影像设备(如CT)或者另一台影像工作站，则完全可以参照以上解释来理解，只不过此时本影像工作站成为“发送者”（相当于上面的影像设备(如CT)），而其他DICOM设备成为“接收者”（相当于上面的本影像工作站的角色）。
&附录1：GE CT/e
CT数字工作站的安装：
&1、工作站分区、格式化、安装操作系统，插入网卡，安装各类驱动，分配IP地址，设置工作站标识(计算机名及组名)
&2、先在公司里随便找一台计算机代替影像设备(如CT)，与工作站联网，调试网络直到双方都能ping通对方为止。再用光盘工具文件夹“DICOM发送测试”来模拟影像设备(如CT)发送图片到工作站进行测试（直接运行DCMSend.exe，请不要创建桌面的快捷方式）。
&3、设置CT机。在主界面左击[Image
Works]，再左击[Browser]，找到[Network]菜单项，选择子菜单[Select Remote
Host]，左击[Add]，进入Remote Host参数设置界面。
Name:&&&&&&&&
&&&&填入工作站“设置”里“DICOM参数设置”下显示的“本地计算机名”，例如“A01”。
Address:&&&&&&
填入工作站右击“网上邻居”得到的“TCP/IP.....”属性下的IP地址。
&&&&&&&&&&&&&&&&&&&&&&&&
例如：& 192.168.0.1
Protocol:&&&&&
选择“DICOM”
Number:&&&&&&&&&&
不改，将工作站“设置”里“DICOM参数设置”下的“AETitle\Port”
&&&&&&&&&&&&&&&&&&&&&&&斜杆后数字改为此值，例如“StoreSCP\4005”。
Title:&&&&&&&&&&&&&
不改，将工作站“设置”里“DICOM参数设置”下的“AETitle\Port”
&&&&&&&&&&&&&&&&&&&&&&&&
斜杆前字符改为此值，例如“A01\4005”。
Comment:&&&&&&&&&&&&&&
不改（空）。
Node:&&&&&&&&&
不改（No）。
Image?:&&&&&&&&&&
不改（Yes），此处必须为Yes。
& Query/Retrieve
Image?: 不改（No）。
Search?&&&&&&&&
不改（Off）。
&4、最后工作站和CT机都必须保存参数（Save）后返回，然后选择一个Image，选中刚才创建的“Remote
Host”并选择[Network]子菜单[Send Image]发送即可。工作站应处于新建病例后的主界面。必要时需要重启。
&附录2：Acuson
Sequoia-512 彩超数字工作站的安装：
&1、工作站分区、格式化、安装操作系统，插入网卡，安装各类驱动，分配IP地址，设置工作站标识(计算机名及组名)
&2、先在公司里随便找一台计算机代替影像设备(如彩超)，与工作站联网，调试网络直到双方都能ping通对方为止。再用光盘工具文件夹“DICOM发送测试”来模拟影像设备(如彩超)发送图片到工作站进行测试（直接运行DCMSend.exe，请不要创建桌面的快捷方式）。
&3、设置彩超机。在主界面下按键盘上[Setup]按键，进入[Service
UI]界面，找到[Network Setup]，再左击[Change Network]，创建新的“DICOM
Server”（如果已经有DICOM Server，则不需要创建，直接修改即可），进入DICOM
Host参数设置界面。注意不是“Hostname”“Router”“DICOM Printer”“Network
Host”“Perspective PC”以及“Name Server”。
Name:&&&&&&&&&
如果是空的，则填入工作站“设置”里“DICOM参数设置”下显示的“本地计算机名”，否则不
&&&&&&&&&&&&&&&&
改，请将工作站的机器名改为此值（右击[网上邻居]或者[我的电脑]）。例如“Main”。
Port:&&&&&&&&&
如果是空的，则填入工作站“设置”里“DICOM参数设置”下的“AETitle\Port”斜
&&&&&&&&&&&&&&&&
杆后数字。否则不改，将工作站“设置”里参数改为此值，例如“StoreSCP\999”。
Address:&&&&&&
如果是空的，则填入右击工作站“网上邻居”得到的“TCP/IP.....”属性下的IP地
&&&&&&&&&&&&&&&&
址。否则不改，将工作站的IP地址改为此值。& 例如：157.226.12.105
Title:&&&&&
如果是空的，则填入工作站“设置”里“DICOM参数设置”下的“AETitle\Port”斜杆前
&&&&&&&&&&&&&&&&
字符。否则不改，将工作站“设置”里参数改为此值，例如“Main_Server\999”。
不改（30）。
Services:&&&&&
选择“Store”。
除此之外，还有：
Networking?:&&&&&&&&&&
使其Enable。
& Activate a
network?:&&&&&&&&&
使其Activate。
4、最后工作站和彩超机都必须保存参数（Save）后返回，然后选择一个Image，选中刚才创建的“DICOM
Server”并左击[Copy]发送即可。工作站应处于新建病例后的主界面。必要时需要重启
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。6433人阅读
DICOM（89）
背景：& & & & 最近去医院部署设备，调试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模式。博文（）和博文（）中对该三种模式有简单的介绍，大家可以仔细阅读，此处我选用的是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网络服务的实现流程有一个宏观的认识，期望能够快速找到上述问题的根源。【注】：专栏的前几篇博文中提到过mDCM与fo-dicom、DCMTK的关系，有兴趣的可以进入我的专栏阅读一下。& & & & 从Github上下载mDCM的源码，利用VS打开（如下图）。找到mDCM中关于DICOM网络服务的文件夹Network，可以看到mDCM按照Client和Server将DICOM网络服务的实现类分成了两部分。& & & & 上图中的各个类之间的继承关系如下所示，& & & & 此处通过对PACSServer服务端的实现来剖析一下mDCM的相关类，对于客户端分支的相关分析此处就不做介绍了，客户端的流程比服务端要简单，主要是一个主动连接及被动接收服务端应答的过程，相应的处理函数也比较少，有兴趣的同学可自己浏览mDCM源码。DcmNetworkBaseDcmNetworkBase是mDCM实现DICOM网路服务的基类，类中给出了基类网络服务的基础函数，主要由以下几类：1）可重载的各类请求和应答的响应函数，如OnReceiveEchoRequest/OnReceiveEchoResponse、OnReceiveCMoveRequest/OnReceiveCMoveResponse等等。作为基类，各响应函数内部并未真正实现相应的操作，只是简单的发送终止应答，即调用SendAbort函数。2）不可重载的，可派生的发送各种请求和应答的函数，如SendEchoRequest/SendEchoResponse、SendCMoveRequest/SendCMoveResponse等等。该类函数按照DICOM网络服务协议的要求，封装好了相应的发送操作，派生后可自由使用。3）私有的，限定关键流程的函数，如Process、ProcessNetPDU、ProcessPDataTF、ProcessDimse。这四个函数表明了DICOM服务中信息流的流向，用户不可修改该流程，但是可通过重载相应的请求和应答函数向该流程中添加自己的操作。4）私有的，限定底层网络操作流程的函数，如Connect。用户可通过重载OnInitializeNetwork函数来向连接流程中添加自己的操作。CStoreServiceCStoreService是服务端用来相应C-STORE 请求的类，即C-STORE-SCP类，派生自DcmNetworkBase基类，并对基类中关于C-STORE请求和C-ECHO请求进行了定制。重载实现的函数有：1）OnReceiveAssociateRequest2）OnReceiveCStoreRequest，函数中调用了OnReceiveCStore委托，通过绑定自己的函数可对CStore请求进行定制化操作。例如数据库的写入等。3）OnReceiveEchoRequest4）OnReceiveDimseBegin5）OnReceiveDimseProgress后两个函数可以在DcmNetworkBase基类对DIMSE消息进行处理之前添加自己的操作，两个函数中调用的是OnCStoreRequestBegin和OnCStoreRequestProgress两个委托，例如可进行相关日志的写入操作。CEchoService该类是一个连接测试类，比较简单。重载了OnReceiveAssociationRequest和OnReceiveEchoRequest两个函数。DcmServer&T&where T:DcmSeriveBase该类是我们以后编写PACSServer服务端具体用到了泛型类，该类包含派生自DcmServiceBase的服务类成员，然后通过制定基本的连接流程来实现PACSServer服务端。关于流程的相关函数有，1）共有的，可访问的启动、关闭和端口等相关操作函数，如AddPort、Start、Stop等2）私有的，不可更改的核心流程控制函数，ServerProc。该函数选用Select模式来接收客户端的响应，然后针对获得的客户端socket对象调用派生自DcmServiceBae的服务类来实现PACSServer的功能，具体PACSServer提供的功能由T：DcmServiceBase类来决定。& & & & 从上述表格中我们对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三种网络连接模式的实际测试后记：博文最后提到了&虽然mDCM库中对于信息的发送有的是通过查询数据库来获取目的地IP地址，有的是直接利用客户机的套接字来获取IP地址&，其本质原因应该是：——DICOM网络协议是建立在OSI的TCP/IP协议之上的，之间的信息发送利用Socket套接字完全可以明确双方彼此之间的唯一通路（在C#中有TcpClient和NetworkStream类），详情可参见关于网络传输的相关书籍资料。但是DICOM协议之所以添加了Application Entity Title约束，主要用在C-MOVE请求中，由于C-MOVE服务可能发生三方交互的情景，因此再第三方首次加入会话时刻需要确定其IP地址和端口的，因此采用预登记Application Entity Title方式来回溯查找到第三方的IP地址和端口。后记2： 后记1中提到了“利用Socket套接字完全可以明确双方彼此之间的唯一通路”这种说法也是不完全准确的，因为互联网真实情况比较复杂，在局域网中基本可以断定上述说法是正确的，但是放到外网中，经过各级路由情况就发生了变化，例如近期博文“”中提到的内网与外网的区别，以及C-GET与C-MOVE的区别。这一点要格外注意，尤其是在互联网+深入医疗大环境下，原有医院局域网的情况已经被打破。作者：时间：
&&相关文章推荐
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：898875次
积分：9396
积分：9396
排名：第1815名
原创：152篇
转载：32篇
评论：484条
文章：87篇
阅读：424786}