Onis doesn't send A-RELEASE-RQ after finishing C-FIND service

Forums > Onis operations > Database
Search the Forums
Keyword :
Hi guys,

Version: Onis 2.3.5 Free Edition

Onis doesn't release DICOM associations correctly when using C-FIND with other servers.
(A-RELASE-RQ is not sent after a proper C-FIND service, Onis simply disconnects)

This is generally noncritical since all the work between application entities is already finished. I suppose it might cause problems with some other servers.

This is what we do exactly:

1. Start Onis
2. Select previously configured DICOM source
3. Enter some patient name and hit enter

Now Onis sends a proper DICOM C-FIND-RQ and reads the answer properly. After doing that Onis disconnects instead of releasing DICOM association (it should send A-RELEASE-RQ)

I attach log from simplified association (searching for a patient that is not in our database):

On our side (ZDAJCOMSRV) is server under development. Nontheless it's already working correctly with several DICOM applications.

P.S. I would happilly attach logs from our side but the overzealous forum engine blocks them as potentially dangerous (expecting SQL injection)


Bartosz Meglicki

National Centre for Nuclear Research
Department of Nuclear Equipment
ul. Andrzeja Sołtana 7
05-400 Otwock, Poland
11/7/2011 8:51:54 PM

Hello Bartosz,

I have checked the source code and you are right, Onis does not send a release request after a C-FIND RQ operation.

The reason is that originally, we even didn't close the socket right away, leaving it available with the association still in place to handle a new C-FIND request without loosing time and resource in re-associating the same thing. Only when a timeout occurred, the association was released.

This way was ok but it was consuming a socket and resource on the server side for nothing until the timeout if no new request were coming from Onis. Then we quickly change the behavior and kill the socket right after the request. To respect the specification more closely, it is better to send a release request first. We will probably modify it. However, we didn't get any problem with that with a number of servers, which is normal since a socket can be suddenly close for any kind of reason (the client computer lost power for example). If a DICOM server would not be able to bear this, it would be a big problem.

To summarize, we believe that this is not a problem (it works fine with any server till now) but we agree with you that it would be cleaner to release the association properly. We will take care about this.


11/8/2011 11:03:01 AM

Hi Madric,

It is ok in the functional sense, the communication is finished so disconnecting doesn't hurt. But Onis knows that it has finished.

From the second DICOM AE side it looks like "the association was prematurely dropped". DICOM AE doesn't know why so the question arises: should we inform the user? Should we log the problem? Was some information lost?

DICOM A-RELEASE-RQ is like I want to finish, I am ready, I have nothing more to say.

Even after sending A-RELEASE-RQ the DICOM AE can keep on receving P-DATA-TFs (not sending). This is because the second side hasn't said "I have nothing more to say" (A-RELEASE-RSP) (from DICOM PS 3.8-2011 7.2.2)

If some problem occurs DICOM AE uses A-ABORT and tries to indicate the reason.

DICOM ABORT is like "something bad happened, we cannot continue, information can be lost!"

Now, when the connection is simply dropped DICOM AE may assume that something exeptional has happened (something happened and other side couldn't even ABORT association).

"If a DICOM server would not be able to bear this, it would be a big problem."

True, but servers are non-interactive and have to be prepared for network problems. Now if the server logs errors should it treat dropped connection as properly finished association or a network error?

Kind regards,


11/8/2011 7:59:58 PM

Hello Bartosz,

I will not argue since I agree with you. But since it does not make any real problem in the real environments, we will modify this only in the next version of Onis.

In the meantimes, if you need to solve your issue regarding the log, maybe you can assume that if you have sent the last response without any network error and if you receive a socket close event with also no network error, then it is fine (I agree that this is not 100% certain but as the server point of view, your operation was completed anyway, you had nothing more to say).

Kind regards,

11/8/2011 8:25:14 PM

Hello again,

The new version send a release request now. I can send it to you if you want to test.

Kind regards,

11/9/2011 5:44:43 PM
About us | Contact us | Terms and Conditions | Privacy policy | Copyright policy
Copyright © Digitalcore 2009-2022. All rights reserved.