Dicom Medical Graphics Processing: Storescp.exe and Storescu.exe source analysis, Learning C-Store request (cont.)

reprint:http://blog.csdn.net/zssureqh/article/details/39237649 Background:

In the previous blog post, after parsing the source file scp.cc of the STORESCP tool source file storescp.cc and the Dcmscp class, it was concluded that both could implement the functionality of the response C-echo and C-Store (need to extend the DCMSCP Class) request. However, when the DCMSCP class is extended, it is expected that the simulation implements its own Storescp.exe tool when there is a problem, the client prompts the service to break the link, and the service side display save failed, as shown in. This blog post by excluding the issue once again to storescp.cc and scp.cc contrast, mainly from presentation Context, Abstractsyntax, Transfersyntax and other details, seriously learn dicom communication services.

Troubleshooting: 1) Compare and analyze debug information for the Storescp.exe Toolkit and custom toolkits

In order to eliminate the problem of Storescu.exe client, roughly determine the scope of the problem, decide to use Storescp.exe as the client again, use Storescu.exe to send C-Store request to view the debugging information of the Storescu.exe client. Compare the debug information with our custom tool server.

The debug information in the comparison, where the red part of end A-ASSOCIATE-AC indicates that the server has successfully completed the handshake with the client, that is, the network has successfully responded to the client's connection. The Blue section indicates that the C-STORE-RQ request sent by the client has also successfully reached the service side, and the only difference is the yellow Circle-marked section, which indicates that there is a problem dealing with the C-STORE-RQ request after the server has received it. And our own encapsulated ZSDCMSTORESCP class for C-STORE-RQ's handler function is a direct copy of the STORESCP and Storescpcallback functions within the Storescp.exe tool. It is therefore possible to determine the extent to which the problem may occur.

2) Single Step debugging

Inside the Handleincomingcommand function, call the STORESCP instruction to insert a breakpoint into the single-step debug state. Using the new Debug tool "parallel stack" provided by VS2012, find the first return state Cond.bad () to True, that is, the function Asc_findacceptedpresentationcontext, as shown in:

Continue to step into the Asc_findacceptedpresentationcontext function, and find out where the error really occurred is Findpresentationcontextid, the function's The parameter presentationcontextid is always zero.

guess: It is possible that the Presentationcontextid parameter failed in a certain part of the delivery process, causing the program to fail. To verify our idea, open the Storescp.exe project, go to debug mode, view the numerical status of the parameter, as shown in the Storescp.exe Toolkit, the value of the Presentationcontextid parameter is 41. This proves that we have an error in the process of passing the Presentationcontextid parameter.

3) parameter passing direction

In order to determine the error link in the specific transfer process, we take a backtracking approach to determine the exact location of the problem by backtracking the source of the Presentationcontextid parameter in the Findpresentationcontextid function.

(Note: In order to facilitate the picture rotation of 90 degrees, I would ask everyone crooked neck to look at the next AH)

From this we can see that the final source of the T_asc_presentationcontextid parameter is the Handleincomingcommand function that we overload the DCMSCP base class. So in contrast to the Storescp.exe, a closer look at the part of the code reveals a major problem , It turns out that when we disassemble the contents of the Processcommands function in the Storescp.exe tool to the inside of the Handleincomingcommand function, we comment out the extra dimse_receivecommand function, Missing the comment out T_asc_association local variables , so that the original should be obtained through the Dimse_receivecommand function Presid variable is covered by the local variable to 0--this problem found.

So since we commented out the extra Dimse_receivecommand function, where do we get the Presid parameter? Look at the header of the Handleincomingcommand function The parameter of the T_asc_presentationcontextid type is not found in the function parameter. But comparing the functions that scp.cc originally handled C-echo requests Handleechorequest we found that the Presid values in the scp.cc class were stored in dcmpresentationcontextinfo variables of presinfo type. So we modify the STORESCP call and pass the Presinfo.presentationcontextid into the initial value as the Presid.

After the modification is completed, the debug Discovery program runs normally and the client receives the Dimse Message back from the server. And on the server side of the directory also saw the Storescu.exe passed the DCM file (of course, within the STORESCP function based on the time and other information to rename the file).

The problem with the blog post Self-simulation Storescp.exe toolkit has been solved so far, and the functionality of the Storescp.exe Toolkit can be easily implemented using our own encapsulated ZSDCMSTORESCP class.

Summary analysis:

This debug troubleshooting process found that in the combination of different files to move the code to pay extra attention to the details section. By the way, with the loss of the t_asc_association type parameter, we analyze in detail the role of the T_asc_associaton type parameter of the delivery failure, why the simple one parameter pass failure, will cause c-store function invalidation?

1) Presentation Context, Abstractsyntax, transfersyntax details Learning

        in the previous blog post we extracted the explanations of the DICOM3.0 standard in terms of presentation Context, Abstractsyntax, Transfersyntax, In layman's terms, the presentation context represents an environment (often called a context) in which two application entities (Ae=applicaiton entity) interact. It contains the following abstractsyntax and Transfersyntax nouns. Abstractsyntax and Transfersyntax easier to confuse is because the English word contains syntax, in fact, the two are completely different concepts , Abstractsyntax is concerned about the upper information, Which is the interaction between the two Interactive AE, which is the type of service object pair (SOP) referred to in the standard, by viewing the Dcuid.h file, Abstractsyntax has Store, query/retrive, worklist types, such as the store type uid_ctimagestorage  , query/retrive type uid_ Findpatientrootqueryretrieveinformationmodel , worklist type of uid_ Findmodalityworklistinformationmodel and so on. These are some of the things we use in C-echo, C-Store, C-find services, and Transfersyntax is concerned with the encoding rules of the information transfer interaction, explicit or implicit, is Littleendian or Bigendian , common with Uid_littleendianimplicittransfersyntax, uid_ Littleendianexplicittransfersyntax and so on, you can view the dcuid.h file yourself. The Presid parameter that passes the loss above is the two most important interaction information included. This can cause the entire C-Store service to fail.

2) storescp.cc and scp.cc overall re-comparison

So what is the Storescp.exe Toolkit and the DCMSCP class ? Where to set these parameters? Here we will compare the implementation of the two tools to analyze the process (details can be referred to the previous post Dicom medical image processing: Storescp.exe and Storescu.exe source analysis, Learning C-Store request).

2.1 scp.cc Source file

Use the pictures from the previous blog post to analyze the specific operations in the DCMSCP class for presentation Context (that is, Abstractsyntax and Transfersyntax).

The specific location and functions used in the DCMSCP class to set presentation context contexts are given in.

2.2 Storescp.exe Source file

Presumably the setup process in the Storescp.exe Toolkit is basically similar, so let's look at the diagram from the previous blog post.

Compare two images we can see that both DCMSCP and Storescp.exe are configuring the presentation context context of the connection before processing the real DIMSE message. Where is the storage of so many UID (either Abstractsyntax or transfersyntax, defined in the Dcuid.h file with a uniform uid) ? in conjunction with the analysis of the previous blog post, we know that the main core function has a t_asc_association type parameter assoc (storescp.exe) or M_ASSOC (DCMSCP Class) after the outer loop starts, and a look at t_asc_ The definition of the association type, and the step-by-step open, can be found, as we expected, that the variable stores all the UID of the connected context, as shown in:

At this point our analysis of the source code of DCMSCP and Storescp.exe tools is finally over, I hope you can have a more profound understanding of DICOM network communication services.

3) Preliminary conjecture on realization of DCMSCP and DCMSTORESCP in new DCMTK

Through the use of the DCMSCP class of engineering found that the design of the class is defective, the Open interface is not reasonable enough to easily implement the extension to respond to other requests such as C-Store. Guess the new DCMTK will definitely be modified, By looking at the official notes of dcmtk3.6.1, we found that the new version of the DCMTK Open Source Library does make great changes to the DCMSCP and Dcmscu base classes, opening up a number of new interfaces (such as) to facilitate user expansion, and a new version of the library directly gives the encapsulated DCMSTORESCP and Dcmstorescu class , so people do not use the code I gave ZSDCMSTORESCP class, only for testing, the specific use is or hurriedly install the latest version of the DCMTK Open Source Library bar.

Example Project code Download:

1) csdn Resources Download:

Connection: http://download.csdn.net/detail/zssureqh/7906309, need 1 points Austria.

2) GitHub free download

Connection: Https://github.com/zssure-thu/CSDN

Next Column blog post trailer:

1) DCMSCP analysis of dcmtk3.6.0 DCMSCP and dcmtk3.6.1, and dcmtk3.6.1 DCMSTORESCP and Dcmstorescu use

2) different design modes for DCMTK and fo-dicom save files: Single thread vs multithreading

3) Wlmscpfs.exe and Findscu.exe source analysis: Learning C-find Request

Dicom Medical Graphics Processing: Storescp.exe and Storescu.exe source analysis, Learning C-Store request (cont.)