本文關鍵詞：醫(yī)學圖像處理，由筆耕文化傳播整理發(fā)布。

背景：

        上一篇專欄博文中針對PACS終端（或設備終端，如CT設備）與RIS系統(tǒng)之間worklist查詢進行了介紹，并著重對比分析了DICOM3.0中各部分對DICOM網(wǎng)絡通訊服務的定義。此次通過結(jié)合早些時間的博文DICOM醫(yī)學圖像處理：基于DCMTK工具包學習和分析worklist，對DCMTK開源庫中提供的storescp.exe和storescu.exe工具的源碼進行剖析，從底層深入了解C-STORE服務的觸發(fā)及響應。

分析思路：

        storescp.exe和storescu.exe分別充當著C-STORE服務的SCP和SCU，因此猜測兩個工具包一定是利用了DCMTK提供的DcmSCP和DcmSCU類來分別實現(xiàn)的。為了驗證自己的想法，從分析storescp.exe源碼文件storescp.cc入手，對比storescp.cc與scp.cc，尋找兩者的共同點。倘若與我們的設想一致，就新建一個C++本地工程，利用DcmSCP類來建立自己的C-STORE SCP端，期望達到與storescp.exe工具包相同的效果。

storescp.cc與scp.cc源碼分析： 1）storescp.cc源碼分析

        storescp.cc是DCMTK提供的storescp.exe工具的源文件。直接打開storescp.cc文件，首先可以看到作者給出的注釋：

        Purpose概括了該工具的主要用途——是存儲服務的提供者，用來響應C-STORE 操作。由于storescp.exe是一個命令行工具，即用戶可以通過不同的參數(shù)設置或組合來實現(xiàn)不同的功能。因此在storescp.cc文件開頭main主函數(shù)外部定義了眾多全局的命令行參數(shù)變量，例如我們上一篇博文DICOM醫(yī)學圖像處理：全面分析DICOM3.0標準中的通訊服務模塊中使用的storescp.exe -d 104 -aet OFFIS命令行中的104相對應的參數(shù)是opt_port， 從參數(shù)opt_前綴亦可以猜出用途。

        由于storescp.exe工具是需要與客戶端進行交互的，接下來進入到main主函數(shù)后的第一件事情就是初始化網(wǎng)絡環(huán)境。如下圖所示，作者利用條件編譯（如下圖中的紅圈所示）以來實現(xiàn)不同系統(tǒng)的網(wǎng)絡環(huán)境的初始化，由于我使用的是Windows7操作系統(tǒng)，因此條件編譯的結(jié)果是調(diào)用WSAStartup初始化Windows 套接字（Socket）的網(wǎng)絡環(huán)境。

        網(wǎng)絡環(huán)境的初始化是main函數(shù)的第一步操作，隨后就是前面提到的命令行參數(shù)的解析，因為storescpp.exe是命令行類型的工具包。從文件260行至992行就是命令行參數(shù)的解析部分，我們暫時直接跳過該部分，簡單地認為該部分實現(xiàn)的功能就是對應參數(shù)的賦值。

接下來正式進入到了DICOM模塊，

第一步，加載DICOM字典文件。該步驟幾乎是所有與DICOM操作相關的文件的第一步。其實就是加載一個預先寫好的包含各種DICOM3.0標準中規(guī)定的字段的文本文件。

第二步，初始化網(wǎng)絡連接，創(chuàng)建網(wǎng)絡連接的一個實例，格式為T_ASC_Network（如下圖），記住該類型，不要與后面出現(xiàn)的T_ASC_Association混淆了。其實在第一步和第二步之間我們省略了部分代碼，該部分主要是用來控制storescp.exe工具的運行機制，是單線程還是多線程。

第三步，進入外層while循環(huán)。在利用ASC_initializeNetwork初始化網(wǎng)絡環(huán)境后，就進入到了while循環(huán)內(nèi)的acceptAssociation函數(shù)。這也是正常情況下，while循環(huán)中唯一的工作函數(shù)。隨后就是待連接斷開后的收尾工作。

第四步，單步調(diào)試進入acceptAssociation函數(shù)內(nèi)部。從函數(shù)前面的注釋了解到函數(shù)是用來接收處理鏈接請求的，注意看函數(shù)的參數(shù)，傳遞進去的是上面我們初始化后獲得的網(wǎng)絡連接變量net，ascfig是通過解析命令行而獲得的配置參數(shù)。

第五步，函數(shù)acceptAssociation內(nèi)部開始通過調(diào)用ASC_receiveAssociation來嘗試獲取客戶端的連接請求，該函數(shù)與socket編程中的accept函數(shù)類似，可以設置阻塞模式和非阻塞模式（關于套接字的阻塞模式和非阻塞模式的區(qū)別可參見《Windows網(wǎng)絡編程》）。調(diào)用該函數(shù)后storescp.exe工具就暫停，等待客戶端發(fā)起鏈接。

第六步，當有客戶端連接進入后，ASC_receiveAssociation函數(shù)返回，隨后會出現(xiàn)眾多以ASC_為前綴的函數(shù)，主要有ASC_acceptContextsWithPreferredTransferSyntaxes、ASC_setAPTitles、ASC_getApplicationContextName，以及如果發(fā)生錯誤情況下會調(diào)用的ASC_rejectAssociation。參照博文DICOM醫(yī)學圖像處理：全面分析DICOM3.0標準中的通訊服務模塊中的分析可知，以ASC_為前綴的函數(shù)屬于DICOM3.0中的Association Managements，主要在第8部分講解。用來實現(xiàn)上層DIMSE與下層DUL（Dicom Upper Layer Protocol）的溝通，所處的位置如下圖（更詳細的介紹可參照上一篇博文）。由此可知該部分是在ASC_receiveAssociation接收到客戶端連接后，所進行的有關連接層的相關配置。（要留意該部分的配置流程，下面的實例講解中會重點介紹由于該部分配置錯誤，導致模擬的工具包無法正常運行【注1】）。

第七步，接收客戶端連接并配置完成后就是發(fā)送確認消息，即調(diào)用函數(shù)ASC_acknowledgeAssociation。此處注意從ASC_receiveAssociation函數(shù)返回后，后續(xù)的相關ASC_函數(shù)操作的參數(shù)就從T_ASC_Network類型的net變成了T_ASC_Association類型的assoc，其代表的是客戶端的連接。

第八步，storescp.exe發(fā)送完確認消息后，接下來就需要處理客戶端發(fā)來的具體請求了。該部分工作包含在processCommands中。

第九步，進入到processCommands函數(shù)內(nèi)部，就是我們所遇到的第二個內(nèi)部while循環(huán)，與第三步中的while外部循環(huán)不同的是該內(nèi)部循環(huán)用來接收客戶端發(fā)來的DIMSE消息的，而第三步中的while循環(huán)是用來循環(huán)等待客戶端連接請求。

第十步，內(nèi)部while循環(huán)內(nèi)，調(diào)用DIMSE_前綴函數(shù)，來實現(xiàn)DIMSE層的信息交互，這也是C-ECHO、C-STORE、C-FIND等請求具體實現(xiàn)的部分。首先調(diào)用DIMSE_receiveCommand接收客戶端的DIMSE消息，隨后根據(jù)DIMSE中的CommandSet的類型，分別進行處理，如下圖所示，可以看出storescp.exe工具能夠?qū)-ECHO和C-STORE進行處理。

        至此，通過上述大致的十步我們對storescp.exe源碼有了一個較深刻全面的認識。從調(diào)用的ASC_和DIMSE_函數(shù)來看，storescp.exe完全按照DICOM3.0的網(wǎng)絡通訊協(xié)議來處理C-ECHO和C-STORE請求的。

        根據(jù)OFFIS官網(wǎng)給出的關于dcmnet網(wǎng)絡通訊包的介紹（），可知DCMTK庫中提供了兩個來實現(xiàn)DICOM網(wǎng)絡通訊兩端的類DcmSCP和DcmSCU。那么storescp.exe為什么沒有直接用DcmSCP來實現(xiàn)C-STORE的服務端呢？利用DcmSCP類是否可以來實現(xiàn)storescp.exe工具的功能呢？

2）scp.cc源碼分析：

        參照OFFIS論壇中的一篇帖子（?f=1&t=4041&hilit=addPresentationContext&sid=d4de67ef5faada44233de627a062d3b7）中對DcmSCP的簡短使用，來具體分析一下DcmSCP類的源碼文件scp.cc。

第一步，DcmSCP的構(gòu)造函數(shù)。如下圖，在構(gòu)造函數(shù)內(nèi)部，完成了對網(wǎng)絡環(huán)境的初始化，這與storescp.exe的main函數(shù)起初的代碼是相同的。

第二步，根據(jù)OFFIS官網(wǎng)提供的類說明文件，在DcmSCP開放的函數(shù)中l(wèi)isten用于實現(xiàn)對客戶端請求的處理。其余的公共函數(shù)從名稱上就可以看出大多是配置和獲取相關參數(shù)的函數(shù)，不是以set為前綴就是get，所以接下來重點分析listen函數(shù)內(nèi)部的實現(xiàn)。

第三步，進入到listen函數(shù)內(nèi)部。發(fā)現(xiàn)listen函數(shù)起始部分是用來加載DICOM字典文件的，與storescp.cc文件中DICOM部分的第一步相同。接下來就是相關的服務開啟模式（單線程or多線程，阻塞or非阻塞）。

第四步，隨后出現(xiàn)了ASC_initializeNetwork函數(shù)，用來初始化網(wǎng)絡連接。

第五步，進入到第一個while循環(huán)，循環(huán)內(nèi)部調(diào)用的是waitForAssociation函數(shù)，用來等待客戶端的實際連接請求，注意此時的參數(shù)也是T_ASC_Network類型的m_net，這一點與storescp.exe情況相同。

第六步，進入到waitForAssociation函數(shù)內(nèi)部，出現(xiàn)的是ASC_receiveAssociation函數(shù)，這與storescp.exe源碼分析中的第五步相同。隨后出現(xiàn)的也是以ASC_為前綴的眾多函數(shù)，用來配置網(wǎng)絡連接的具體參數(shù)。

第七步，參數(shù)配置完成后，就是發(fā)送響應給客戶端，即調(diào)用ASC_acknowledgeAssociation函數(shù)——與storescp.exe源碼分析的第七步相同。

第八步，隨后scp.cc內(nèi)部將處理客戶端指令的操作封裝在了handleAssociation函數(shù)內(nèi)部，需要注意的是此處handleAssociation函數(shù)并不需要傳遞任何參數(shù)進去，因為T_ASC_Association類型的變量assoc是保存在DcmSCP內(nèi)部的私有成員變量——這一點與storescp.exe直接將assoc變量傳遞給processCommands函數(shù)不同【注2】。

第九步，handleAssociation函數(shù)內(nèi)部需要處理的就是DIMSE層面的指令交互工作。因此為了完整接收客戶端的DIMSE指令，同樣出現(xiàn)了第二個while循環(huán)，循環(huán)內(nèi)部調(diào)用了DIMSE_receiveCommand指令——這與storescp.exe中的processCommands函數(shù)內(nèi)部相同。

第十步，最后進入到了handleIncomingCommand函數(shù)內(nèi)部，根據(jù)DIMSE中的CommandSet類型來分別進行C-ECHO和C-STORE的處理。

        至此，DcmSCP的原文件scp.cc分析完成了。通過與storescp.exe的源文件storescp.cc對比發(fā)現(xiàn)，兩者基本是相同的流程，無非一個是用類來進行了封裝，另一個是實現(xiàn)了命令行工具。

3）storescp.cc與scp.cc共同點：

        兩者共同的處理流程如下圖所示，

        從上圖可以看出，我們起初的猜測是正確的，利用DcmSCP是可以實現(xiàn)storescp.exe工具的，那么為什么DCMTK給出的storescp.exe工具包沒有用DcmSCP類來實現(xiàn)呢？猜測有可能是DcmSCP類和storescp.exe工具的開發(fā)者是并行工作的，因此也就無法使用DcmSCP來實現(xiàn)storescp.exe工具了，并且兩者的基本流程是相同的，也沒必要對storescp.exe進行再次修改，畢竟該工具的用途有限。

模擬構(gòu)建自己的C-STORE SCP： 1）直接利用DcmSCP自建C-STORE SCP端：

        通過上一節(jié)的分析，我們決定嘗試利用DcmSCP類來構(gòu)建C-STORE的SCP端，來替代storescp.exe工具。

        利用VS2012構(gòu)建C++的工程，命名為C-STORETest，直接利用DcmSCP類來實現(xiàn)C-STORE的SCP端，具體代碼如下：

// C-STORETest.cpp : 定義控制臺應用程序的入口點。 // #include "stdafx.h" //add the include files of Dcmtk library #include "dcmtk/config/osconfig.h" #include "dcmtk/dcmdata/dctk.h" #include "dcmtk/dcmnet/scp.h" #include "ZSDcmStoreSCP.h" #include "global.h" int _tmain(int argc, _TCHAR* argv[]) { DcmSCP mStoreSCP; mStoreSCP.setAETitle("ZS-TEST"); mStoreSCP.setPort(104); mStoreSCP.setVerbosePCMode(true); mStoreSCP.setACSETimeout(-1); mStoreSCP.setDIMSETimeout(10000); mStoreSCP.setDIMSEBlockingMode(DIMSE_NONBLOCKING); OFList< OFString > transferSyntaxes; transferSyntaxes.push_back(UID_LittleEndianExplicitTransferSyntax); transferSyntaxes.push_back(UID_LittleEndianImplicitTransferSyntax); mStoreSCP.addPresentationContext(UID_CTImageStorage,transferSyntaxes); //mStoreSCP.SET mStoreSCP.listen(); return 0; }

        編譯完成后，打開一個cmd客戶端，啟動storescu.exe與我們自建的C-STORETest進行連接，得到的結(jié)果如下：

        發(fā)現(xiàn)服務端（上圖左側(cè)）給出的錯誤提示顯示“無法處理該類型的DIMSE請求”，而客戶端（上圖右側(cè)）顯示連接被終止（Aborting Association）。這是什么原因呢？后來經(jīng)過自己閱讀OFFIS官網(wǎng)關于DcmSCP類的描述后，找到了問題的原因。原來DcmSCP類的實現(xiàn)還處在測試實驗階段，DcmSCP給出的listen函數(shù)內(nèi)部暫時只能夠處理C-ECHO請求，

        按照官方的提示，要想實現(xiàn)相應C-STORE指令，需要我們手動擴展DcmSCP類。（原來如此，由此看來之所以沒有使用DcmSCP來實現(xiàn)storescp.exe工具的真正原因是DcmSCP功能還不完善，并不能處理C-STORE指令）。

2）擴展DcmSCP類處理C-STORE請求：

        既然找到了問題所在，那么我們就按照官方的說法嘗試對DcmSCP進行擴展，添加處理C-STORE指令的部分。直接的想法是將storescp.exe工程中的針對C-STORE請求的處理函數(shù)提取出來，添加到DcmSCP的擴展類ZSDcmStoreSCP中。因此在ZSDcmStoreSCP類中添加了函數(shù)storeSCP、storeSCPCallback，如下圖所示：

        同樣需要對listen函數(shù)進行擴展。原本以為只需要重載DcmSCP中處理DIMSE具體CommandSet的函數(shù)handleIncomingCommand即可，但是在擴展過程中發(fā)現(xiàn)storescp.exe處理C-STORE的函數(shù)storeSCP和storeSCPCallback都要以T_ASC_association類型為參數(shù)，而DcmSCP的m_assoc是私有變量并且沒有留給我們獲取該私有變量的接口，因此無法將storeSCP、storeSCPCallback函數(shù)直接添加到handleIncomingCommand內(nèi)部。   

        為了實現(xiàn)直接利用storeSCP、storeSCPCallback函數(shù)，我們必須想辦法獲得T_ASC_association變量assoc，通過上述對DcmSCP的源碼剖析我們可知，，在waitForAssociation函數(shù)內(nèi)部調(diào)用ASC_receiveAssociation之后，DcmSCP才從T_ASC_Network出獲得到了客戶端的T_ASC_association連接變量assoc。那么我們是否可以通過重載waitForAssociation函數(shù)來提取出assoc變量呢？在嘗試這給ZSDcmStoreSCP類添加新的成員變量T_ASC_association* zs_assoc后，將waitForAssociation內(nèi)部的調(diào)用基類DcmSCP中m_assoc的地方統(tǒng)統(tǒng)換成zs_assoc，直接替換后發(fā)現(xiàn)，我們需要重載的不只waitForAssociation一個函數(shù)，諸如dropAndDestroyAssociation、negotiateAssociation、refuseAssociation等等函數(shù)都需要重新覆蓋，關鍵是waitForAssociation內(nèi)部的核心函數(shù)handleAssociation也要覆蓋，因為該函數(shù)并不需要任何參數(shù)（見上一節(jié)的【注2】），其內(nèi)部直接調(diào)用的就是DcmSCP的私有成員變量m_assoc，因此為了提取一個m_assoc變量，我們需要將DcmSCP基類中的眾多函數(shù)進行重寫，這還算上的是對DcmSCP的派生擴展么？

        在沒有找到很好的解決辦法之前，我將waitForAssociation函數(shù)和handleAssociation函數(shù)內(nèi)部的源碼直接剪切出來一起放到了listen函數(shù)內(nèi)部，然后用我們自己的zs_assoc替換掉了DcmSCP的m_assoc，如是從ZSDcmStoreSCP外觀上看來我只對DcmSCP類的listen函數(shù)、handleIncomingCommand函數(shù)進行了擴展而已，另外將storescp.exe中的storeSCP和storeSCPCallback函數(shù)添加到ZSDcmStoreSCP類中，為了使得上述兩個函數(shù)能夠順利運行，也添加了些許storescp.exe中定義的命令行參數(shù)變量。

問題分析： 1）ZSDcmStoreSCP無法響應原本DcmSCP能夠響應的C-ECHO：

        將上述完成的ZSDcmStoreSCP類添加到工程中，創(chuàng)建ZSDcmStoreSCP對象，調(diào)用listen()函數(shù)（具體代碼如下），啟動服務端程序，同樣利用storescu.exe進行客戶端模擬，測試發(fā)現(xiàn)連C-ECHO也無法響應。

// C-STORETest.cpp : 定義控制臺應用程序的入口點。 // #include "stdafx.h" //add the include files of Dcmtk library #include "dcmtk/config/osconfig.h" #include "dcmtk/dcmdata/dctk.h" #include "dcmtk/dcmnet/scp.h" #include "ZSDcmStoreSCP.h" #include "global.h" int _tmain(int argc, _TCHAR* argv[]) { ZSDcmStoreSCP mZSStoreScp; mZSStoreScp.setAETitle("ZS-TEST"); mZSStoreScp.setPort(104); mZSStoreScp.setVerbosePCMode(true); mZSStoreScp.setACSETimeout(-1); mZSStoreScp.setDIMSETimeout(10000); mZSStoreScp.setDIMSEBlockingMode(DIMSE_NONBLOCKING); OFList< OFString > transferSyntaxes; transferSyntaxes.push_back(UID_LittleEndianExplicitTransferSyntax); transferSyntaxes.push_back(UID_LittleEndianImplicitTransferSyntax); mZSStoreScp.addPresentationContext(UID_CTImageStorage,transferSyntaxes); //mStoreSCP.SET mZSStoreScp.listen(); return 0; }

        從上圖可以看書，客戶端在發(fā)送完A-ASSOCIATE-RQ消息后，再無響應而直接出現(xiàn)了連接請求失敗。再次利用上一篇博文中使用的RawCap.exe抓取本地回路數(shù)據(jù)包，利用Wireshark查看數(shù)據(jù)包發(fā)現(xiàn)，客戶端在發(fā)送完A-ASSOCIATE-RQ后，服務端并未發(fā)送A-ASSOCIATE-RSP，因此確定問題出在了我們自己封裝的ZSDcmStoreSCP內(nèi)部。

        單步調(diào)試后發(fā)現(xiàn)，在函數(shù)判別過程中，assoc->presentationContextList變量為空，因此猜測對ASC_receiveAssociation接收到客戶端的鏈接assoc后的ASC_相關配置有問題（參見上一節(jié)的【注1】）。

        通過排查發(fā)現(xiàn)在拆解waitForAssociation函數(shù)時將ASC_receiveAssociation函數(shù)后面的眾多ASC_開頭的函數(shù)給漏掉了，將該段代碼補充完全（如下圖所示），

2）ZSDcmStoreSCP響應C-STORE請求有誤：

        重新編譯，利用storescu.exe進行測試，測試結(jié)果如下，通過使用Wireshark觀察RawCap.exe抓取的數(shù)據(jù)包可以肯定此次C-ECHO請求能夠順利響應，但是對于C-STORE的請求在保存dcm文件的時候出現(xiàn)了問題。目前還未查清楚具體問題出現(xiàn)在什么地方。

知識點補充：

        上述storescp.cc和scp.cc中出現(xiàn)了大量的ASC_XXX函數(shù)和DIMSE_XXX函數(shù)，這與我們前一篇博文分析的DICOM網(wǎng)絡通訊服務整體結(jié)構(gòu)是相吻合的，借著此次實現(xiàn)C-STORE請求響應的過程再次熟悉一下DICOM3.0標準中的幾個概念，尤其是第一次出現(xiàn)配置錯誤時的TransferSyntax和PresentationContext，加深一下理解。

（該部分同樣還是直接摘抄自DICOM3.0標準的英文官方版，同樣不做翻譯，實在是英文不好，能力有限，靜候國內(nèi)大牛出現(xiàn)）

Presentation Context– the set of DICOM network services used over an Association, as negotiated between Application Entities;includes Abstract Syntaxesand Transfer Syntaxes.

Transfer Syntax– the encoding used for exchange of DICOM information objects and messages.Examples: JPEGcompressed (images), little endian explicit value representation.

Abstract Syntax – the information agreed to be exchanged between applications, generally equivalent to a Service/Object Pair (SOP) Class.Examples : Verification SOP Class, Modality Worklist Information Model Find SOP Class, Computed Radiography Image Storage SOP Class.

Service/Object Pair (SOP) Class– the specification of the networkor media transfer (service) of a particular type of data (object); the fundamentalunit of DICOM interoperability specification.Examples: Ultrasound Image Storage Service, Basic Grayscale Print Management.

Service/Object Pair (SOP) Instance– an information object; a specific occurrence of information exchanged in a SOP Class.Examples: a specific x-ray image.

Presentation Context consists of an Abstract Syntax plus a list of acceptable Transfer Syntaxes. The Abstract Syntax identifies one SOP Class or MetaSOP Class (a collection of related SOP Classes identified by a single Abstract Syntax UID). By listing the Application Entities with their proposed and accepted Presentation Contexts, the Conformance Statement is identifying the set of Information Objects and Service Classes which are recognized by this implementation。

TransferSyntax是Presentation Context屬性的一種；

TransferSyntax只對DICOM 消息中的Data Set部分生效。

TransferSyntax是描述真實世界中一種或幾種Abstract Syntax的編碼規(guī)則。

備注：

        原本希望通過擴展DcmSCP類來輕松加愉快的仿真storescp.exe工具，但是在實現(xiàn)過程中發(fā)現(xiàn)dcmtk3.6.0版本中的DcmSCP類設計存在著缺陷，使得后續(xù)的繼承和擴展比較費力。搜索OFFIS的官網(wǎng)發(fā)現(xiàn)，在最近新發(fā)布的dcmtk3.6.1版本中，竟然給出了DcmStoreSCP和DcmStoreSCU兩個C-STORE請求處理類，而且分別派生自DcmSCP和DcmSCU，不知道OFFIS的大師是否對DcmSCP類進行了修改？后續(xù)會對新版DcmSCP與舊版DcmSCP的比較，以及DcmStoreSCP和DcmStoreSCU的使用進行分析，期望找到本文中出現(xiàn)問題的解決方法（注：在下一篇博文中再給出完成的ZSDcmStoreSCP類的代碼）。

（未完待續(xù)……）

后續(xù)博文預告：

1）storescp.exe與sotrescu.exe的源碼剖析：學習C-STORE請求（續(xù)）
2）dcmtk3.6.0的DcmSCP與dcmtk3.6.1的DcmSCP分析，以及dcmtk3.6.1的DcmStoreSCP和DcmStoreSCU的使用
3）Dcmtk與fo-dicom保存文件的不同設計模式：單線程VS多線程
4）wlmscpfs.exe與findscu.exe的源碼剖析：學習C-FIND請求

作者：zssure@163.com

時間：2014-09-12

  本文關鍵詞：醫(yī)學圖像處理，由筆耕文化傳播整理發(fā)布。

本文編號：65799