Monitor Dicom Server Port

StevenE · Post by **StevenE** » Thu Nov 17, 2005 11:31 am

Has anyone tried to Monitor a dicom Server port ?

I have tried using the TCP connection but it seems to upset the Dicom Servers.

And I am not sure what else to try, I just need to know that those ports are listening.

Our old Monitoring software Monitored the Dicom Server ports without a problem.

Any Thoughts are appreciated.
Thanks
StevenE

KS-Soft · Post by **KS-Soft** » Thu Nov 17, 2005 12:45 pm

DICOM? Digital Imaging and Communications in -?
What exactly means "upset the Dicom Servers"?

Regards
Alex

StevenE · Post by **StevenE** » Thu Nov 17, 2005 1:03 pm

KS-Soft wrote:DICOM? Digital Imaging and Communications in -?

Yes, that is correct. As far as upsetting the servers.......
We have several different vendors of DICOM Servers that Send/Recieve Dicom Images.

2 of the Vendors when I attemp to monitor them using TCP Connection Test, the test will run for a while then the Dicom Server Service Crash's. If I do not monitor them they run just about forever.

The Other Dicom Servers, the TCP Connection test cause them to open client connections. And then the connections do not close and the Dicom Servers have dozens of client connections listed. The connections eventually do close if I stop the TCP connections Tests.

KS-Soft · Post by **KS-Soft** » Thu Nov 17, 2005 2:50 pm

Looks like servers expect some data packet (its normal) but do not release resources correctly when TCP connection closed by the client (HostMonitor).
Solution? We need to know what data server expects and try to send such packet or .. could you report this problem to developers of the servers? Good server should know what to do when connection lost and how to release resources without crash.

Regards
Alex

StevenE · Post by **StevenE** » Thu Nov 17, 2005 3:01 pm

I asked 2 of them so far already, and the answer I got was that thier servers conform to the DICOM Specifications.

Both of them point me to this Dicom Windows Ping Utility. It is not command line based though.

http://www.unipacs.com/en/dping.html

Steven

KS-Soft · Post by **KS-Soft** » Thu Nov 17, 2005 9:31 pm

and the answer I got was that thier servers conform to the DICOM Specifications

So, server crashes in compliance with DICOM Specifications?
Ok, will try to find DICOM specifications, probably we will need to create new test....

Regards
Alex

StevenE · Post by **StevenE** » Fri Nov 18, 2005 8:15 am

KS-Soft wrote:
So, server crashes in compliance with DICOM Specifications?
Yes, I guess you can say that, I spent a lot of time looking for a command line Dicom Ping Utility. I haven't found one yet.

I have found most Vendors in the Health Care specific industry are very unwilling to talk about thier products in that type of detail or admit there might be a problem.

StevenE

KS-Soft · Post by **KS-Soft** » Fri Nov 18, 2005 9:52 pm

I cannot find DCOM specifications

Found just RFC 3240 that does not provide necessary information..
If you find something, please let me know

Regards
Alex

StevenE · Post by **StevenE** » Mon Nov 21, 2005 8:00 am

I spend a lot of time looking also, I think I may have finally found the info at
http://medical.nema.org/

Thanks
StevenE

StevenE · Post by **StevenE** » Thu Dec 22, 2005 3:28 pm

Any New info on possibly testing a Dicom port to see if it is available.

Thanks
StevenE

KS-Soft · Post by **KS-Soft** » Thu Dec 22, 2005 5:13 pm

Sorry, we are busy with other tasks implementation that were requested by many people: icq, wmi, rcc improvement, web interface improvement, etc
DICOM task has low priority

Regards
Alex

KS-Soft Europe · Post by **KS-Soft Europe** » Sun Dec 24, 2006 3:20 am

DiCOM test utility available at
http://www.ks-soft.net/download/dicom_echo.zip
This is command line utility that can be used with Shell Script test method
http://www.ks-soft.net/hostmon.eng/mfra ... m#chkShell

There are 2 mandatory command line parameters:
-server:<hostname|IP>
-port:<port_number>
and 1 optional parameter:
-timeout:<communication_timeout_ms>

Regards,
Max

StevenE · Post by **StevenE** » Tue Dec 26, 2006 8:55 am

I tried the dicom utility, and get an error when using it.
I think the AE Title information needs to be included on the command line. In all the dicom settings for our applications there is always a sending AE_Title and a recieving AE_title that needs to be configured.

When I use the Dicom utility I get the following messages.

C:\temp>dicom_echo -server:dvs1001 -port:3140
ScriptRes:Bad:ASSOCIATE_RJ service recieved; Reason: No reason

C:\temp>dicom_echo -server:nas1000 -port:104
ScriptRes:Bad:ASSOCIATE_RJ service recieved; Reason: No reason

C:\temp>dicom_echo -server:nas1000 -port:104
ScriptRes:Bad:ASSOCIATE_RJ service recieved; Reason: No reason

C:\temp>dicom_echo -server:nws1000 -port:104
ScriptRes:Bad:ASSOCIATE_RJ service recieved; Reason: No reason

KS-Soft Europe · Post by **KS-Soft Europe** » Tue Dec 26, 2006 9:16 am

StevenE wrote:I tried the dicom utility, and get an error when using it.
I think the AE Title information needs to be included on the command line. In all the dicom settings for our applications there is always a sending AE_Title and a recieving AE_title that needs to be configured.

Thank you for your reply, Steven. Are there any other settings we need to include as command line params? We are going to implement following settings: Called AE Title, Calling AE title, Application Context name.

BTW. What Application Context name is used in your applications? We have been using 1.2.840.10008.3.1.1.1 by default in dicom_echo utility.

Regards,
Max

StevenE · Post by **StevenE** » Tue Dec 26, 2006 9:47 am

None of the applications we use have a setting for Application context Name.

The necessary info we have to enter to communicate with Dicom is the AE_Title sending, AE_Title Recieving, IP/Host Name, Port Number.

Thanks
Steven