storescu: DUL Finite State Machine Error: No action defined, state 1 event 8

[eludias]

Hi,

STORESCU.EXE doesn't recover when sending a bunch of files and one of them is not accepted at the other end:

storescu --verbose --no-halt localhost 3010 *.DCM

... (first 100 files are sent OK) ...

Code: Select all

Sending file: 427633A9.DCM
Transfer: LittleEndianImplicit -> LittleEndianExplicit
Store SCU RQ: MsgID 171, (RF)
XMIT:...
C-Store RSP: MsgID: 171 [Status=Error: CannotUnderstand]
  AffectedSOPClassUID: =XRayFluoroscopyImageStorage
  AffectedSOPInstanceUID: 1.3.46.670589.6.1.0.00523244.2005020210164149
  Data Set: Not Present

Sending file: 427633AA.DCM
Transfer: LittleEndianImplicit -> LittleEndianExplicit
Store SCU RQ: MsgID 172, (RF)
XMIT:...
storescu: Store Failed, file: 427633AA.DCM:
0006:0317 Peer aborted Association (or never connected)

Sending file: 427633AB.DCM
Transfer: LittleEndianImplicit -> LittleEndianExplicit
Store SCU RQ: MsgID 173, (RF)
XMIT:storescu: Store Failed, file: 427633AB.DCM:
0006:020e DIMSE Failed to send message
0006:0303 DUL Finite State Machine Error: No action defined, state 1 event 8

Sending file: 427633AC.DCM
Transfer: LittleEndianImplicit -> LittleEndianExplicit
Store SCU RQ: MsgID 174, (RF)
XMIT:storescu: Store Failed, file: 427633AC.DCM:
0006:020e DIMSE Failed to send message
0006:0303 DUL Finite State Machine Error: No action defined, state 1 event 8

... (now at the rest of the files, it always gives 'state 1 event 8') ...

The file at which it errors (427633A9.DCM) is known bad and therefore not accepted by localhost. But that's no reason to not trying to import the remaining files.

What to do?


Regards,
Rutger Nijlunsing.

[Marco Eichelberg]

The main problem here is that the SCP aborts the association (closes the network connection) immediately after the failed transmission. The behavior of storescu is not correct here - the tool should not continue to try sending images once the network connection is down, because this is of course guaranteed not to work, but the reason why further images do not get transmitted is actually the SCP side.

[eludias]

I know the SCP is 'the reason', however the documentation of '--no-halt' suggests that it would not halt, i.e. continue succesfully (probably by re-establishing the association). So as an item on the TODO list of DCMTK would be great

Rutger.

[Marco Eichelberg]

--no-halt indeed causes storescu not to halt when one image transmission is unsuccessful - in this case storescu does not even halt when continuing transmissions is pointless. I do not think, however, that a feature that would simply re-establish the connection is too useful. For a real "reliable transmission" function one would need to maintain lists of objects successfully sent and objects still pending transmission, would have to retry a configurable number of times after configurable timeouts, and might even implement more clever association negotiation techniques to eliminate unsuccessful transmissions caused by transfer syntax selection or the limitation of presentation contexts to 128. This would, however, be much more than simply fixing the "--no-halt" thing.