-
Notifications
You must be signed in to change notification settings - Fork 113
Update state machine; send/receive P-DATA PDUs only #714
Description
The implementation of the Drop trait for [Async](Server/Client)Association has resulted in problems when the association is released.
An easy way to reproduce is to use a wire dump tool such as wireshark, then open a dicom-storescp server and use the dicom-echoscu on it. Example output with wireshark, using dicom as display filter follows. The client is 10.0.0.11 and the server is 10.0.128.11.
No. Time Source Destination Protocol Length Info
4 0.000197660 10.0.0.11 10.0.128.11 DICOM 318 A-ASSOCIATE request ECHOSCU --> ANY-SCP
6 0.000531384 10.0.128.11 10.0.0.11 DICOM 276 A-ASSOCIATE accept ECHOSCU <-- ANY-SCP
8 0.000929172 10.0.0.11 10.0.128.11 DICOM 148 P-DATA, C-ECHO-RQ ID=1
9 0.001465826 10.0.128.11 10.0.0.11 DICOM 132 P-DATA, C-ECHO-RSP ID=1 (Success)
10 0.008328674 10.0.0.11 10.0.128.11 DICOM 78 A-RELEASE request
11 0.008474849 10.0.128.11 10.0.0.11 DICOM 78 A-RELEASE response
13 0.008605302 10.0.128.11 10.0.0.11 DICOM 78 ABORT ECHOSCU <-- ANY-SCP (Not specified)
The problem is the last packet, numbered 13. The association is already released; it makes no sense to send an abort.
This appears to be a consequence of the Drop trait implementation for [Async]ServerAssociation, which unconditionally performs an abort().
Similarly, the Drop trait for [Async]ClientAssociation unconditionally performs a release().
Not sure how this should be handled. I think that removing the Drop trait and leaving the release or abort up to the user is the natural thing to do. Another, more complex option is to keep the association's state machine properly updated and take it into account at drop time, to see if the association is still open before deciding whether to abort or release it.
Pinging @naterichman as the author of the commit that introduces the Drop trait for the association objects.