Association release use cases

[razvanux]

Hello everybody!

I have a question regarding the association release. There are 4 ways in which such a thing can be performed (not released in the dicom sense, but terminated, if you will).

1. ASC_releaseaAssociation - this looks to me like a graceful-shutdown of the association, with the whole Dicom handshacking and acknowledgements in place.

2. ASC_abortAssociation - initiates the A-ABORT request.

3. ASC_dropAssociation - force-closes the association without any protocol considerations.

4 . ASC_destroyAssociation, which cleans drops the association and cleans up.

I have the following dilemma:
I have to send a whole bunch of files to an SCP and because I don't want to re-negotiate the association for each IOD, I only do this when it is necessary (abstract or transfer syntax change, for instance).

When I do need to do this re-negotiation, which would be the best way to terminate the previous association?

I also want a speed bonus, otherwise I'd go always for the standard request/response ASC_releaseAssociation and I don't want to get into trouble by doing things otherwise.

Is it best to use ASC_releaseAssociation each time I need to renegotiate or can I safely go with ASC_dropAssociation, followed by a re-initialization?

Thank you and best regards,
~~Razvan

[razvanux]

I guess I found the answer to my questions...

I failed to take into account that the association, as an entity is created only in ASC_RequestAssociation and each time I need to do that, I'll have a new association structure created.

So I guess that it's obvious that ASC_destroyAssociation will be the choice before requesting another association...

[Marco Eichelberg]

Think of ASC_destroyAssociation as the destructor of the association structure - it performs only internal cleanup of memory structures. The only legal way of closing the association is the ASC_releaseAssociation primitive, everything else should be used in "emergency" cases only. If you correctly negotiate an appropriate set of presentation contexts, there should rarely be a need to re-negotiate an association. Remember that no matter how you close the association, there will always be a significant overhead for opening a new TCP transport connection, possibly also involving DNS host name resolution.

[razvanux]

Thank you for your reply Marco.

Think of ASC_destroyAssociation as the destructor of the association structure - it performs only internal cleanup of memory structures. The only legal way of closing the association is the ASC_releaseAssociation primitive, everything else should be used in "emergency" cases only. If you correctly negotiate an appropriate set of presentation contexts, there should rarely be a need to re-negotiate an association.

Well, the problem I have is that the program I write must send thousands of IODs in a row to an SCP and there is no a-priori information about the SOP classes in the set. Better said, I can't work on that assumption. So I have to renegotiate associations in certain conditions.
I actually build incrementally a list of maximum 128 Presentation Contexts as new Association/Transfer syntaxes are requested and propose the whole list as the process goes on.

Remember that no matter how you close the association, there will always be a significant overhead for opening a new TCP transport connection, possibly also involving DNS host name resolution.

Indeed. I was actually hoping into working with something similar to a "keep-alive" property.

But anyway, as I realized, using the incremental buildup above it makes little or no sense to go through way too much trouble on this re-negotiation optimization, as far as renegotiation times are concerned.

The approach will be good enough and it will take a crazy set of IODs to significantly slow the SCU down to a noticeable extent, a thing that will never happen in the real-world case I am working on. I know, I know... Never say never....

~~Razvan