DICOM医学图像处理:fo-dicom网络传输之 C-Echo and C-Store

背景:

        上一篇博文对DICOM中的网络传输进行了介绍,主要参照DCMTK Wiki中的英文原文。通过对比DCMTK与fo-dicom两个开源库对DICOM标准的具体实现,对理解DICOM标准有一个更直观的认识。此篇博文是对上一篇博文的补充,因为专栏前面的示例大多是利用DCMTK工具包来进行的,此次借着分析fo-dicom源码结构的机会,参照fo-dicom的README.md,给出C-ECHO 和C-STORE服务的具体实现。在实现的同时给出DICOM3.0标准中的相关介绍,帮助我们理解。

C-ECHO的fo-dicom实现:

1)C-ECHO参数说明:

        C-ECHO又叫验证服务(即Verification),是用来验证DICOM服务两端的交流是否畅通。DICOM3.0的第7部分给出了C-ECHO服务的参数,如下图1所示:

DICOM医学图像处理:fo-dicom网络传输之 C-Echo and C-Store_第1张图片

【注意】:这里讲解一下DICOM3.0标准的阅读方法。以DICOM3.0标准的第7、8部分为例,【第7部分】中第9章开始讲解DIMSE-C的各种服务,依次为C-STORE、C-FIND、C-GET、C-MOVE、C-ECHO(上图1就是我在该部分的C-ECHO小节中截取的),其中前半部分主要给出了DIMSE-C各种服务的参数,这里仅仅是罗列出DICOM3.0标准的要求,目的是让你明白各个服务参数是否是必要的(分别用M、U、=表示);后半部分开始讲解DIMSE-C各种服务的协议及实现流程(即Protocol和Procedures),在PROTOCOL中给出的是具体的DIMSE-C服务的各种指令在传输过程中的格式,该部分也就是你利用抓包工具能够直接抓取的真实数据流;在Procedures中给出的是SCU和SCP之间的交互流程,通常为了说明服务是由谁发起的,由谁响应。在介绍Protocol的时候对于比较复杂的、可变的区域(Variables Fields)通常会放在附录中,例如第7部分的附录C和E等;【第8部分】与【第7部分】类似,从第7章开始介绍ACSE的各种服务的参数(如下图2所示),依次为A-ASSOCIATE、A-RELEASE、A-ABORT、A-P-ABORT、P-DATA;第9章给出的是ACSE中各种服务的结构,即STRUCTURE,该部分与【第7部分】中的PROTOCOL相同,给出的是具体ACSE PDU在传输时刻的数据格式,该部分也是可以通过抓包工具直接获得的;同样对于比较复杂的STRUCTURE介绍也会单独放到附录中,例如第8部分的附录E。

DICOM医学图像处理:fo-dicom网络传输之 C-Echo and C-Store_第2张图片

        fo-dicom对于DIMSE消息的实现基类是DicomMessage,针对请求和响应分别派生出了DicomRequest和DicomResponse,最后根据不同的DIMSE服务派生相应的类。C-ECHO是其中最简单的,fo-dicom已经给出了SCP和SCU的具体实现。参照fo-dicom中的README.md文件,给出C-ECHO SCP和SCU的代码,详情如下:

2)C-ECHO代码实例:

        C-ECHO SCP的代码是直接利用了fo-dicom给出的DicomCEchoProvider类,通过创建DicomServer<DicomCEchoProvider>(12345)对象,开启C-ECHO SCP服务,其中参数12345表示C-ECHO服务的端口号。C-ECHO SCU和C-ECHO SCP的代码分别如下所示:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading;
using System.Threading.Tasks;
using Dicom;
using Dicom.Network;

namespace CEchoSCU
{
    class Program
    {
        static void Main(string[] args)
        {
            var client = new DicomClient();
            client.NegotiateAsyncOps();
            client.AddRequest(new DicomCEchoRequest());
            client.Send("127.0.0.1", 12345, false, "SCU", "ANY-SCP");
            Console.ReadLine();

        }
    }
}

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.Threading;
using Dicom;
using Dicom.Network;
namespace CEchoSCP
{
    class Program
    {
        static void Main(string[] args)
        {
            var server = new DicomServer<DicomCEchoProvider>(12345);
            Console.ReadLine();

        }
    }
}


        实际运行结果如下:

DICOM医学图像处理:fo-dicom网络传输之 C-Echo and C-Store_第3张图片

C-STORE的fo-dicom实现:

1)C-STORE参数说明:

        C-STORE就是存储服务,在医疗信息系统中最常见的服务之一,尤其是PACS系统中。与C-ECHO服务相同,DICOM3.0标准第7部分也给出了C-STORE服务的参数列表,如下图4所示:

DICOM医学图像处理:fo-dicom网络传输之 C-Echo and C-Store_第4张图片

        该参数列表的目的同样是为了介绍C-STORE服务中各参数的必要性,真正的参数消息格式在后续的C-STORE PROTOCOL中介绍,如下图5所示:

DICOM医学图像处理:fo-dicom网络传输之 C-Echo and C-Store_第5张图片

        图5中给出的仅仅是C-STORE RQ的实际消息格式,该消息由C-STORE服务的SCU(客户端)流向C-SOTRE服务的SCP(服务端);与之相对应的C-STORE-RSP消息是从SCP流向SCU,DICOM3.0标准中也有C-STORE-RSP的详细介绍,如下图6所示。

DICOM医学图像处理:fo-dicom网络传输之 C-Echo and C-Store_第6张图片

2)C-STORE代码实例:

        在fo-dicom的说明文档README.md中只给出了C-STORE的SCU示例,如下图7所示:

DICOM医学图像处理:fo-dicom网络传输之 C-Echo and C-Store_第7张图片

        上一篇博文对fo-dicom源码结构分析的基础上可知,实现DIMSE众多服务的SCU端很容易,首先创建DicomClient实体类,代表一个客户端,然后通过AddRequest添加不同的请求即可实现各种DIMSE的客户端,如图7中C-STORE SCU的实现为:

        client.AddRequest(new DicomCStoreRequest(@"test.dcm"));

        DicomCStoreRequest类是DicomRequest的派生类,上述代码通过制定DCM文件路径来构建了一个DicomCStoreRequest对象,在DicomCStoreRequest内部通过打开指定的DCM文件提取获得上述参数中的Affected SOP Instance UID等参数。

        既然fo-dicom中没有提供线程的C-STORE SCP实现,我们先利用DCMTK的storescp.exe工具来验证一下fo-dicom给出的C-STORE SCU的正确性,测试代码如下:

  • SCP端利用storescp.exe,在控制台下输入:storescp.exe –d –od c:\ 12345
  • SCU端利用fo-dicom中的C-STORE SCU,具体代码如上图7所示,然后双击生成后的storescu.exe

        最后可以得到如下结果,如图8所示:

DICOM医学图像处理:fo-dicom网络传输之 C-Echo and C-Store_第8张图片

        同时在C盘根目录下可以看到被重命名的test.dcm文件,如下图9所示:

        之所以被重命名我们在之前分析DCMTK开源库源码时提到过,通常DCMTK会根据SOP Instance UID(-uf,默认的)对接收到的DCM文件进行重命名,当然也可以通过选项设置重命名的方式,例如按照时间(-tn)、特定前缀(-fe)等等,如下图10所示。

        由此说明fo-dicom中给出的C-STORE SCU功能正常,接下来我们尝试利用fo-dicom构建C-STORE SCP。

3)构建C-STORE SCP

打开C-ECHO SCP的实现DicomCEchoProvider.cs文件,我们看到DicomCEchoProvider类通过派生DicomService服务类来实现了Dicom服务的基本框架,然后通过实现IDicomServiceProvider和IDicomCEchoProvider接口,完成了C-ECHO 的服务端,仔细查看DicomCEchoProvider的代码可以发现,其实就是在接收到A-ASSOCIATE-RQ消息后,判别Presentation Context中的Abstract Syntax,根据实际请求消息来决定是否建立连接,另外当接收到C-ECHO SCU发起的C-ECHO Request时,向其会送DicomCEchoResponse确认信息即可。

既然通过实现两个接口函数就可以完成C-ECHO SCP的构建,那么我们就自己尝试来完成C-STORE SCP的搭建,仿照DicomCEchoProvider的方式,DicomCStoreProvider的代码如下:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using Dicom;
using Dicom.Log;
using Dicom.Network;
using System.Threading;
using System.IO;
namespace CStoreSCP
{
    class CStoreSCPProvider : DicomService, IDicomServiceProvider, IDicomCStoreProvider
    {
        public CStoreSCPProvider(Stream stream, Logger log) : base(stream, log) { }

        public DicomCStoreResponse OnCStoreRequest(DicomCStoreRequest request)
        {
            return new DicomCStoreResponse(request,DicomStatus.Success);
        }
        public void OnCStoreRequestException(string tempFileName, Exception e)
        {

        }
        public void OnReceiveAssociationRequest(DicomAssociation association)
        {
            foreach (var pc in association.PresentationContexts)
            {
                if (pc.AbstractSyntax == DicomUID.Verification)
                    pc.SetResult(DicomPresentationContextResult.Accept);
                else
                {
                    //pc.SetResult(DicomPresentationContextResult.RejectAbstractSyntaxNotSupported);
                }
                if (pc.AbstractSyntax == DicomUID.CTImageStorage)
                {
                    pc.SetResult(DicomPresentationContextResult.Accept);
                }
            }
            SendAssociationAccept(association);

        }
        public void OnReceiveAssociationReleaseRequest()
        {
            SendAssociationReleaseResponse();

        }
        public void OnReceiveAbort(DicomAbortSource source, DicomAbortReason reason)
        {

        }
        public void OnConnectionClosed(int errorCode)
        {

        }


    }
}

        然后通过var server = new DicomServer<CStoreSCPProvider>(12345);Console.ReadLine(); 来构建一个C-STORE SCP应用。

        下图11是先运行CStoreSCP.exe,然后运行CStoreSCU.exe得到的结果:

DICOM医学图像处理:fo-dicom网络传输之 C-Echo and C-Store_第9张图片

        从图11的输出结果可以看出,此次C-STORE SCP和SCU两端的通讯顺利完成,那么我们发送的C:\test.dcm文件会被CStoreSCP.exe存储到那里呢?由上一篇博文分析我们知道fo-dicom库中将DICOM的服务基本框架放在了DicomService类中,查看其中处理P-DATA服务的核心函数ProcessPDataTF,可以看到如下代码:

var file = new DicomFile(); 
file.FileMetaInfo.MediaStorageSOPClassUID = pc.AbstractSyntax; 
file.FileMetaInfo.MediaStorageSOPInstanceUID = _dimse.Command.Get<DicomUID>(DicomTag.AffectedSOPInstanceUID); 
file.FileMetaInfo.TransferSyntax = pc.AcceptedTransferSyntax; 
file.FileMetaInfo.ImplementationClassUID = Association.RemoteImplemetationClassUID; 
file.FileMetaInfo.ImplementationVersionName = Association.RemoteImplementationVersion; 
file.FileMetaInfo.SourceApplicationEntityTitle = Association.CallingAE;
_dimseStream = CreateCStoreReceiveStream(file);

        转到CreateCStoreReceiveStream函数内部,通过函数的说明就可以知道fo-dicom对C-STORE服务默认情况下是在系统中创建了一个临时文件,用来接收C-STORE SCU的数据,因此可以推断我们的test.dcm文件应该也在临时文件夹中,打开我本机的temp文件夹,可以看到有一个后缀为tmp的临时文件,如下图12所示。文件大小与我们测试用的test.dcm相同,尝试修改.tmp的扩展名,修改后可以使用DICOM Viewer软件正常打开,因此说明我们的C-STORE SCP顺利成功。

DICOM医学图像处理:fo-dicom网络传输之 C-Echo and C-Store_第10张图片

DICOM数据流分析:

C-ECHO服务数据流分析:

1)工具:

        在本地测试,为了抓取127.0.0.1回路数据包,需要使用RawCap.exe工具包。RawCap.exe是控制台程序,在抓取本地回路数据包时很便捷。当抓取完成后我们需要借助于WireShark的强大分析功能,来实现C-ECHO数据流的详细分析,WireShark可以直接打开RawCap.exe抓取的.pcap数据包。

        WireShark是功能强大的数据包统计分析工具,当然本身也可以抓取网络数据包(本地回路数据包不方便)。WireShark支持众多协议,其中包括DICOM协议。下面以C-ECHO的数据包为例,简单介绍一下如何使用WireShark来自动识别并解析DICOM数据包。首先打开抓取的本地C-ECHO数据包cecho.pcap。如图13,在Protocol中右键选择"Protocol Preferences “中的"Data Preferences…”,会弹出一个协议设置窗口如图13。在左侧列表中找到DICOM协议,勾选图14中红色部分。该部分的意思是除了检测DICOM协议默认端口104的数据包的同时也检测其他端口的数据包。之所以需要选择此项是因为很多DICOM服务并未使用协议默认的104端口。设置完成后,重新查看Protocol列,可以看到出现了DICOM字样,如图15所示,最上方的带DICOM字样的数据包就是我们抓取到的C-ECHO服务的本地回路数据包。

DICOM医学图像处理:fo-dicom网络传输之 C-Echo and C-Store_第11张图片

DICOM医学图像处理:fo-dicom网络传输之 C-Echo and C-Store_第12张图片

DICOM医学图像处理:fo-dicom网络传输之 C-Echo and C-Store_第13张图片

2)C-ECHO数据流分析:

        利用RawCap.exe和WireShark两大强大的工具,我们已经可以直观的看到抓取的DICOM数据包了,接下来我就按照DICOM标准第7部分和第8部分中的内容,逐个数据包来分析一下,通过观察真实的数据包来加深一下对DICOM协议的理解。

        从图15中可以看到,最顶部DICOM协议包含6个数据包,分别是连接建立(A-ASSOCIATE RQ/A-ASSOCIATE AC)、数据交互(P-DATA-TF)、连接释放(A-RELEASE RQ/A-RELEASE RP),这与DICOM协议第8部分中介绍的ACSE控制流程相符。

A-ASSOCIATE RQ/A-ASSOCATE AC分析:

        双击第一个DICOM数据包,该数据包是A-ASSOCIATE RQ的真实数据流,如图16所示:

DICOM医学图像处理:fo-dicom网络传输之 C-Echo and C-Store_第14张图片

        按照DICOM协议第8部分中第9章对A-ASSOCIATE RQ PDU的描述,我们来逐项对比(DICOM协议可参照图17):第一项1个字节的PDU-type,图中为01H,说明该数据包代表的是A-ASSOCIATE RQ;第二项一个字节的保留,数据流为00H;第三项是四个字节的PDU-length,图中为00 00 00 ff,转换为无符号整数正好为255,这也是整个图中蓝色部分后续的数据包长度;第四项是两个字节的Protocol-Version,图中为00 01,对应版本为1;第五项为两字节保留;第六项和第七项是我们熟悉的AE Title,从WireShark的数据流中也可以看出分别是ANY-SCP和ECHOSCU;第8项又是一堆保留字节,用00H填充;第9项是一个可变区域(Variable Fields),该项是复合项,内部包含多个独立的子项。由图16可以看出该复合项内部含有Application ContextPresentation Context(2个,ID分别是1、3)、UserInfo三个子项;而UserInfo又是一个复合项,其内部又包含了Max PDU LengthImplentationUIDImplentationVersion三个子项。从WireShark的分析来看,Application Context子项类型为10H、Presentation Context子项类型为20H、UserInfo子项为50H(其内部的嵌套子项的类型分别为,Max PDU Length-51H、Implentation UID-52H、Implentation Version-55H)。各个子项的类型与DICOM协议第7、8两部分中的附录D相对应,例如图19中我截取的是Max PDU Length子项的格式。A-ASSOCIATE AC的数据包分析与A-ASSOCIATE RQ类似,只是A-ASSOCIATE AC的数据流更简单一些,这里就不做详细介绍了。(最终数据域DICOM协议的对应结果如图18)。

DICOM医学图像处理:fo-dicom网络传输之 C-Echo and C-Store_第15张图片

DICOM医学图像处理:fo-dicom网络传输之 C-Echo and C-Store_第16张图片

DICOM医学图像处理:fo-dicom网络传输之 C-Echo and C-Store_第17张图片

A-RELEASE RQ/A-RELEASE RP分析:

        连接释放的数据包格式简单,下面图20和图21分别是DICOM协议第8部分中给出的连接释放请求和应答数据包的格式:

DICOM医学图像处理:fo-dicom网络传输之 C-Echo and C-Store_第18张图片

DICOM医学图像处理:fo-dicom网络传输之 C-Echo and C-Store_第19张图片

        双击WireShark中的连接释放数据包,可以看到两者的数据包类型分别为05H和06H,这与上图中DICOM协议的规定完全一致。

DICOM医学图像处理:fo-dicom网络传输之 C-Echo and C-Store_第20张图片

P-DATA-TF:

        在上一篇博文中(http://blog.csdn.net/zssureqh/article/details/41016091)我已经分析了,DICOM协议第7部分中规定的DIMSE消息(Command和Dataset)是通过第8部分中ACSE协议中的P-DATA-TF服务以PDV的形式来传输的。下面就让我们来分析一下DIMSE消息中C-ECHO RQ 和C-ECHO RSP的格式:

        双击WireShark数据包中间两个,从数据流向可以断定一个是C-ECHO RQ消息,一个是C-ECHO RSP消息。先打开第一个,按照上一篇博文的分析,首先该数据包是一个P-DATA-TF PDU,因此需要符合下图23中的格式。

DICOM医学图像处理:fo-dicom网络传输之 C-Echo and C-Store_第21张图片

        通过分析最外层的是代表P-DATA-TF类型的04H,然后是由DIMSE消息填充的PDV区域,该项是复合项,第一子项是Item-length,此处为46H;第二子项为Presentation-context-ID,此处为01H;第三子项又是一个复合项,是DICOM标准第4部分中给出的DIMSE消息结构,包括Message Control Header、Command和DataSet三部分。此处的MessageControlHeader为03H,即表示是Command数据而不是DataSet,且是最后一个PDV,即Last Fragment。具体的对应关系如图24所示:

DICOM医学图像处理:fo-dicom网络传输之 C-Echo and C-Store_第22张图片

C-STORE服务数据流分析:

1)工具:

        依然使用RawCap.exe+WireShark来解决。

2)C-STORE数据流分析:

        按照C-ECHO中的分析方式,同样可以看到DICOM数据包,如图25所示:

DICOM医学图像处理:fo-dicom网络传输之 C-Echo and C-Store_第23张图片

A-ASSOCIATE RQ/A-ASSOCIATE AC:

        对于A-ASSOCIATE RQ/A-ASSOCIATE AC的分析与C-ECHO中基本类似,唯一不同的就是对于C-STORE服务需要不同的Presentation Context描述上下文,如图26所示,此处C-STORE需要的是CT Image Storage服务,其SOP Class UID为1.2.840.10008.5.1.4.1.1.2。

DICOM医学图像处理:fo-dicom网络传输之 C-Echo and C-Store_第24张图片

A-RELEASE RQ/A-RELEASE RP:

        与C-ECHO中的相同,这也说明了博文中的C-ECHO 和C-STORE服务实现成功,连接能够正常释放。

P-DATA-TF:

        此处着重分析一下C-STORE服务中的P-DATA-TF数据包,因为传输一个DCM文件需要多个PDU,自然也需要多个PDV。所以我们通过分析C-STORE的P-DATA-TF数据包可以更形象的学习Message Control Header和DIMSE的知识

        同样传输的每个数据包首先符合P-DATA-TF的格式要求,第一项是PDU类型,即04H;随后是保留项、PDU-length、PDV复合项……,这与C-ECHO中的分析相同。按照上一篇博文的分析,C-STORE PROTOCOL的流程是CSTORE SCU向SCP发送C-STORE RQ消息,但是打开图中的第一个P-DATA数据包时我们看到的却不是C-STORE RQ,而是其中的一个数据片段,如下图27所示。

DICOM医学图像处理:fo-dicom网络传输之 C-Echo and C-Store_第25张图片

        依次查看后面的几个P-DATA数据包,都是类似的情况。最后倒数两个分别是C-STORE RQ中DCM文件数据的最后一个数据包(Last Fragment)和SCP向SCU发送的C-STORE RSP,具体分析如图28所示:

DICOM医学图像处理:fo-dicom网络传输之 C-Echo and C-Store_第26张图片

        从最后数据包Command中的(0000,0100)的值域8001H可知该指令就是C-STORE RSP。

        看到这里你或许会很兴奋,因为我们终于也看到了C-STORE服务的真实数据流,但是在上图中的所有DICOM对应的数据包中我们并未找到C-STORE SCU发起的C-STORE RQ数据包,那么C-STORE RQ数据包在哪里呢

        让我们将cstore.pcap的所有数据包按照时间排序,出现了大量标记为[TCP segment of a reassembled PDU]的TCP数据包。

DICOM医学图像处理:fo-dicom网络传输之 C-Echo and C-Store_第27张图片

        打开第一个标记为[TCP segment of a reassembled PDU]的TCP数据包,其内部的真实数据分析如下图30所示:

DICOM医学图像处理:fo-dicom网络传输之 C-Echo and C-Store_第28张图片

        至此我们顺利找到了C-STORE SCU端发送的C-STORE RQ消息,之所以没有在WireShark中以DICOM协议显示,可能是由于WireShark在识别多个连续分片的数据时不够智能。博文中的示例图和文字较多,仔细阅读后应该对DICOM3.0中的协议会有更进一步的了解。通过分析数据包的方式在更直观的学习和掌握DICOM3.0标准的同时,对后期排查DICOM网络传输相关错误也会有帮助。

备注:

再次说明一下阅读DICOM3.0标准的方式:

        以DICOM3.0标准的第7、8部分为例,【第7部分】中第9章开始讲解DIMSE-C的各种服务,依次为C-STORE、C-FIND、C-GET、C-MOVE、C-ECHO(上图1就是我在该部分的C-ECHO小节中截取的),其中前半部分主要给出了DIMSE-C各种服务的参数,这里仅仅是罗列出DICOM3.0标准的要求,目的是让你明白各个服务参数是否是必要的(分别用M、U、=表示);后半部分开始讲解DIMSE-C各种服务的协议及实现流程(即Protocol和Procedures),在PROTOCOL中给出的是具体的DIMSE-C服务的各种指令在传输过程中的格式,该部分也就是你利用抓包工具能够直接抓取的真实数据流;在Procedures中给出的是SCU和SCP之间的交互流程,通常为了说明服务是由谁发起的,由谁响应。在介绍Protocol的时候对于比较复杂的、可变的区域(Variables Fields)通常会放在附录中,例如第7部分的附录C和E等;【第8部分】与【第7部分】类似,从第7章开始介绍ACSE的各种服务的参数(如图2所示),依次为A-ASSOCIATE、A-RELEASE、A-ABORT、A-P-ABORT、P-DATA;第9章给出的是ACSE中各种服务的结构,即STRUCTURE,该部分与【第7部分】中的PROTOCOL相同,给出的是具体ACSE PDU在传输时刻的数据格式,该部分也是可以通过抓包工具直接获得的;同样对于比较复杂的STRUCTURE介绍也会单独放到附录中,例如第8部分的附录E。

实例工程及抓取的数据包:

代码:搜索我上传的资源

数据包:搜索我上传的资源

后续专栏博文介绍:

利用PHP Skel结合DCMTK开发WEB PACS应用

利用oracle直接操作DICOM数据

C#的异步编程模式在fo-dicom中的应用

VMWare三种网络连接模式的实际测试



作者:[email protected]

时间:2014-11-18

你可能感兴趣的:(DICOM,fo-dicom,C-STORE,C-ECHO)