Storescu "hang" problem

[Jiri Bartl]

Hi,

I am sending daily hundreds of pictures to PACS with storescu (DCMTK 3.5.4) and very often I have problem with storescu "hang":

Requesting Association
Association Accepted (Max Send PDV: 65524)
--------------------------
Sending file: PI.1.3.12.2.1107.5.6.1.12345.30650107041107121550000000033
Transfer: LittleEndianExplicit -> LittleEndianExplicit
Store SCU RQ: MsgID 1, (PI)
XMIT:.

After killing and repeating of storescu command is all Ok. "Hang" verbose output is always with PDV: 65524, OK repeated storescu is always width PDV: 16372. (It seems as "hang" of storescu during the association abort - a known bug in the 3.5.2 DCMTK version).
I thank you in advace for your advice.

Jiri

[Michael Onken]

Hi Jiri,

so far we (at least me) don't know of such a bug in DCMTK 3.5.4. The transmission seems to start and at least one data package is sent on the association (the last '.' in your output). I wonder that your PACS seems to offer different PDV sizes to storescu for sending. It's difficult to say, what could be the problem here. However, I have some more questions and recommendations:

1. Which Operating System?
2. Are you sending more than one image per association?
3. Are other images successfully transferred on this associaton?
4. Is this always the last image sent by storescu?
5. Are there other images transferred before with the same PDV size?
6. Do you have some DICOM log information from the PACS?
7. Did you try to force storescu using a smaller PDV size (e. g. --max-send-pdu 16384)? Perhaps the PACS runs into problems receiving its own proposed PDV size...
8. Is it possible to reproduce the problem when playing with the max pdu size or by sending the same images with the problematic pdu size?
9. Are there any firewalls running? We had a problem with storescp that only occured from time to time. At the end, the packet filter of the firewall was responsible for that.

Perhaps we could track down your problem a bit.

Regards
Michael

[Jiri Bartl]

Hi Michael,

1. Linux Fedora Core 2
2. Only one image per association
3. -
4. I never seen this case.
5.
storescu -v --max-send-pdu 65536 -aet AET -aec AEC pacs port PI.1.3.12.2.1107.5.6.1.123456.30650107041116462046800000030
Requesting Association
Association Accepted (Max Send PDV: 65524)
--------------------------
Sending file: PI.1.3.12.2.1107.5.6.1.123456.30650107041116462046800000030
Transfer: LittleEndianExplicit -> LittleEndianExplicit
Store SCU RQ: MsgID 1, (PI)
XMIT:.
C-Store RSP: MsgID: 1 [Status=Success]
AffectedSOPClassUID: =PETImageStorage
AffectedSOPInstanceUID: 1.3.12.2.1107.5.6.1.123456.30650107041116462046800000030
Data Set: Not Present
Releasing Association

6. PACS log: association aborted by peer.
7.
storescu -v --max-send-pdu 16384 -aet AET -aec AEC pacs port PI.1.3.12.2.1107.5.6.1.123456.30650107041114594728100000006
Requesting Association
Association Accepted (Max Send PDV: 65524) <----- with --max-send-pdu 16384 !!!
--------------------------
Sending file: PI.1.3.12.2.1107.5.6.1.123456.30650107041114594728100000006
Transfer: LittleEndianExplicit -> LittleEndianExplicit
Store SCU RQ: MsgID 1, (PI)
XMIT:...
C-Store RSP: MsgID: 1 [Status=Success]
AffectedSOPClassUID: =PETImageStorage
AffectedSOPInstanceUID: 1.3.12.2.1107.5.6.1.123456.30650107041114594728100000006
Data Set: Not Present
Releasing Association

8. see point 7
9. Probably Sidewinder on Windows Server - common for hospital internet connection

Today last "hang with verbose output, storescu parameter --max-send-pdu 16384 (5. image, there is 201 images left):

Requesting Association
Association Accepted (Max Send PDV: 65524)
--------------------------
Sending file: PI.1.3.12.2.1107.5.6.1.123456.30650107041114594728100000006
Transfer: LittleEndianExplicit -> LittleEndianExplicit
Store SCU RQ: MsgID 1, (PI)
XMIT:...

Any idea for solution?

Regards
Jiri

[Michael Onken]

Hi Jiri,

thanks for the details.

Hi Michael,
Association Accepted (Max Send PDV: 65524) <----- with --max-send-pdu 16384 !!!

This is OK: The PACS tells us only to send 65524 bytes maximum and storescu accepts this. However, when sending PDV packages to the PACS, the packages are split by storescu (i.e. dcmnet) to match the size given with --max-send-pdu.

2. Only one image per association

I first thought you would send all images over one association. If all images are sent by newly invoking storescu, I think the number of images transferred is not important.

By the way, you also could enable more storescu output by using the "--debug" option. Maybe this could reveal some more interesting detail (though I don't expect that in this case).

For me this sounds more like a "network bug" (is it possible to disable the firewall for testing purposes or to simulate the transfer on a safe network without firewall?) than a bug in storescu. Or maybe the PACS is not able to handle so many associations in a short time..? If you are using a script to initiate transfer, try to insert a short delay between each storescu invocation. I don't have any further ideas at the moment, sorry. Perhaps my colleagues can add some more

Regards,
Michael

[Jiri Bartl]

Hi Michael,

with option +v I got today storescu "hang" output (posted shorted, only the end):

Association Accepted (Max Send PDV: 65524)
--------------------------
Sending file: PI.1.3.12.2.1107.5.6.1.123456.30650107041214194281200000076
Transfer: LittleEndianExplicit -> LittleEndianExplicit
Store SCU RQ: MsgID 1, (PI)
XMIT:DIMSE Command To Send:

# Dicom-Data-Set
# Used TransferSyntax: UnknownTransferSyntax
(0000,0000) UL 0 # 4, 1 CommandGroupLength
(0000,0002) UI =PETImageStorage # 28, 1 AffectedSOPClassUID
(0000,0100) US 1 # 2, 1 CommandField
(0000,0110) US 1 # 2, 1 MessageID
(0000,0700) US 2 # 2, 1 Priority
(0000,0800) US 1 # 2, 1 DataSetType
(0000,1000) UI [1.3.12.2.1107.5.6.1.123456.30650107041214194281200000076] # 54, 1 AffectedSOPInstanceUID
DIMSE sendDcmDataset: sending 150 bytes
DIMSE sendDcmDataset: sending 35858 bytes
.
DIMSE receiveComman

Regards,
Jiri