Association Release Collision States obsolete? [Community feedbackrequested] - DICOM

This is a discussion on Association Release Collision States obsolete? [Community feedbackrequested] - DICOM ; The DICOM association protocol state machine as defined in P.S. 3.8-2008 documents a couple of states (Sta 9, Sta 10, Sta 11, Sta 12) to handle release request collision. A collision can occur when both sides try to release an ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Association Release Collision States obsolete? [Community feedbackrequested]

  1. Association Release Collision States obsolete? [Community feedbackrequested]

    The DICOM association protocol state machine as defined in P.S.
    3.8-2008 documents a couple of states (Sta 9, Sta 10, Sta 11, Sta 12)
    to handle release request collision. A collision can occur when both
    sides try to release an association at the same time and send an A-
    RELEASE-RQ PDU to each other.


    But in P.S. 3.7-2008 appendix A the DICOM standard defines:

    A.5 ASSOCIATION RELEASE FOR DICOM AE
    Only the DICOM AE Association-requester may initiate an orderly
    release of the Association. This shall be accomplished by using the A-
    RELEASE service defined in PS 3.8. The DICOM AE Association-requester
    shall not release the Association until all operations invoked have
    been confirmed.


    This means that while there is a mechanism to handle collisions, this
    mechanism is never used as the only side that can orderly release an
    association is the association requestor (often the SCU). The
    association acceptor (often the SCP) can thus only shutdown an
    association by using the A-ABORT service.

    Does anybody know if there is a use-case scenario that would require
    the release requests collision states?

  2. Re: Association Release Collision States obsolete? [Communityfeedback requested]

    On Jul 29, 3:00*pm, vbade...@gmail.com wrote:
    > The DICOM association protocol state machine as defined in P.S.
    > 3.8-2008 documents a couple of states (Sta 9, Sta 10, Sta 11, Sta 12)
    > to handle release request collision. A collision can occur when both
    > sides try to release an association at the same time and send an A-
    > RELEASE-RQ PDU to each other.
    >
    > But in P.S. 3.7-2008 appendix A the DICOM standard defines:
    >
    > A.5 ASSOCIATION RELEASE FOR DICOM AE
    > Only the DICOM AE Association-requester may initiate an orderly
    > release of the Association. This shall be accomplished by using the A-
    > RELEASE service defined in PS 3.8. The DICOM AE Association-requester
    > shall not release the Association until all operations invoked have
    > been confirmed.
    >
    > This means that while there is a mechanism to handle collisions, this
    > mechanism is never used as the only side that can orderly release an
    > association is the association requestor (often the SCU). The
    > association acceptor (often the SCP) can thus only shutdown an
    > association by using the A-ABORT service.
    >
    > Does anybody know if there is a use-case scenario that would require
    > the release requests collision states?


    I would rather like to skip the constraint in PS 3.7, because it
    contradicts the bi-directional nature of the DUL protocol (after the
    Association Negotiation) as defined in PS 3.8 and hinder advanced
    applications to utilize the potential of a peer-to-peer protocol
    compared to simpler client-server protocols. For instance, Association
    Pooling becomes more robust, if both sides can smoothly release idle
    Associations, instead only can terminate them by an unspecific UL
    service-user A-ABORT.

    Gunter Zeilinger
    Agfa Healthcare Vienna

  3. Re: Association Release Collision States obsolete? [Communityfeedback requested]

    Hi Gunter, thanks for the feedback

    At the moment we have identified 3 use cases when an association-
    acceptor needs to close an association.

    1) Our UL service-provider detects a protocol error (invalid pdu,
    invalid-pdu-parameter, etc)

    2) The application\device that hosts the association is restarted.

    3) The association-acceptor detects that an association is idle for a
    certain time and wants to close the association to reclaim the
    resources attached with the association (tcp-socket, memory, etc)

    Currently our implementation sends an ABORT PDU with the reason
    number: 0x (service provider – reason x) for case 1 and 00 (service
    user – reason not specified) for case 2 and 3. Unfortunately DICOM
    doesn’t define abort reasons such as “idle-time-out” and “forced-
    shutdown” to better inform the remote peer.

    Sending an ABORT PDU keeps our design simple and conform the current
    DICOM standard. In those 3 cases we want to close the association as
    soon as possible and the abort procedure doesn’t require waiting for a
    response.

    If the association-acceptor uses abort reason 00 and the association-
    requestor doesn’t see those aborts as a bad thing (it doesn’t log it
    as an error or reports it to its end-user) then closing the
    association with an abort is much simpler then with the RELEASE
    procedure. The release procedure is more complex as it requires the
    release requestor to wait for the release-rp pdu. During this waiting
    it has to handle timeouts and the answer to the request will always be
    “release accepted”.

    Victor Derks

  4. Re: Association Release Collision States obsolete? [Communityfeedback requested]

    On Aug 4, 9:23*pm, vbade...@gmail.com wrote:
    > Hi Gunter, thanks for the feedback
    >
    > At the moment we have identified 3 use cases when an association-
    > acceptor needs to close an association.
    >
    > 1) Our UL service-provider detects a protocol error (invalid pdu,
    > invalid-pdu-parameter, etc)
    >
    > 2) The application\device that hosts the association is restarted.
    >
    > 3) The association-acceptor detects that an association is idle for a
    > certain time and wants to close the association to reclaim the
    > resources attached with the association (tcp-socket, memory, etc)
    >
    > Currently our implementation sends an ABORT PDU with the reason
    > number: 0x (service provider – reason x) for case 1 and 00 (service
    > user – reason not specified) for case 2 and 3. Unfortunately DICOM
    > doesn’t define abort reasons such as “idle-time-out” and “forced-
    > shutdown” to better inform the remote peer.
    >
    > Sending an ABORT PDU keeps our design simple and conform the current
    > DICOM standard. In those 3 cases we want to close the association as
    > soon as possible and the abort procedure doesn’t require waiting for a
    > response.
    >
    > If the association-acceptor uses abort reason 00 and the association-
    > requestor doesn’t see those aborts as a bad thing (it doesn’t log it
    > as an error or reports it to its end-user) then closing the
    > association with an abort is much simpler then with the RELEASE
    > procedure. The release procedure is more complex as it requires the
    > release requestor to wait for the release-rp pdu. During this waiting
    > it has to handle timeouts and the answer to the request will always be
    > “release accepted”.
    >
    > Victor Derks


    But you have to support correct release initiation - which includes to
    be prepared to receive further P-DATA PDUs after the emission of the A-
    RELEASE RQ PDU before receiving the A-RELEASE RSP PDU - in any case.
    It's just the question, if only by the association initiator, or also
    (optional) by the association acceptor.
    My main argument is the possibility to distinguish between regular and
    exceptional close of an association. And using association pooling,
    dropping idle associations is nothing exceptional - different to
    terminating a hanging association initiated by a modality.

    gunter


+ Reply to Thread