DCMTK

See below
It seems that for example storescu is not behaving correctly if the SCP issues a release or abort request. In both cases the tool fails with errors like that:

storescu: Store Failed, file: pixeltest.dcm:
0006:020e DIMSE Failed to send message
0006:031d TCP I/O Error (Success) occurred in routine: writeDataPDU
storescu: SCU Failed:
0006:020e DIMSE Failed to send message
0006:031d TCP I/O Error (Success) occurred in routine: writeDataPDU
Aborting Association
storescu: Association Abort Failed:
0006:031d TCP I/O Error (Connection reset by peer) occurred in routine: sendAbortTCP

Further in case of association release collisions (SCU/SCP issue release request at the same time), there is a specific protocol to follow, at least when reading part 8 7.2.2.7

7.2.2.7 An A-RELEASE service procedure collision results when requestors in both AEs simultaneously
issue an A-RELEASE service primitive. In this situation, both UL service-users receive an unexpected
A-RELEASE indication primitive. The following sequence shall occur to complete the normal release of
the association:
a) The association-requestor shall issue an A-RELEASE response primitive.
b) The association-acceptor waits for an A-RELEASE confirmation primitive from its peer. When
it receives one, it shall then issue an A-RELEASE response primitive.
c) The association-requestor receives an A-RELEASE confirmation primitive.

However, reading the finite state machine aborting the association when receiving an unexpected a-release seems to be also correct. I'm not sure whether the standard is consistent here, but I'm sure at least that we do not handle SCP release requests in the SCUs correctly.