TCP I/O problem with storescu

[bkuemmer]

Hello there,

we are trying to send images to a PACS system using storescu, and in some cases (but not always), we get the following error:

Code: Select all

0006:020e DIMSE Failed to send message
0006:031d TCP I/O Error (No error) occurred in routine: writeDataPDU
storescu: SCU Failed:
0006:020e DIMSE Failed to send message
0006:031d TCP I/O Error (No error) occurred in routine: writeDataPDU
storescu: Association Abort Failed:
0006:031d TCP I/O Error (No error) occurred in routine: sendAbortTCP

Basic network connectivity is OK, pinging the PACs host has response times <1ms, a traceroute does not show any anomalies and echoscu also works fine. As I said, we only get this error sometimes (but too often).

Another thing is that the transfer seems to be very slow, even small images take between 15 and 30 seconds to transfer (incoming transfer is much faster). While this question might be above the scope of this forum, maybe you could give me an indication what the reasons for the "TCP I/O Error (no error)" could be.

Thanks for your help
Yours
Bernd

[Michael Onken]

Hi Bernd,

unfortanately we've encoutered the same problem a week ago while extending other network applications. The problem seems to originate from the multi-process code for windows we've integrated from an external patch. We haven't tracked it down completely, but we assume, that the code responsible for creating a new process in dcmnet under windows in dul.cc (receiveTransportConnectionTCP()) causes this error, that leaves some handles unclosed or something like this, what might result in an overflow. The error itself occurs then in dulfsm.cc (sendAssociationRQTCP()), when writing to the network.

As a workaround you might use the "--single-process"-option under windows. Or did you notice the error in single process mode? Don't hope so... I might write another posting in this thread, if I know more. Currently there is little time for DCMTK programming...

Regards
Michael

[bkuemmer]

I forgot to tell you that this is for the storescu from dcmtk 3.5.2, which, as far as I know, does not yet contain the multi-process code...

Any more ideas?

Cheers
Bernd

[Michael Onken]

Uh, that's surprising...are you using windows?

Regards,
Michael

[bkuemmer]

Yes, this is on Windows XP.

We are calling storescu from within out application to send images.

Cheers
Bernd

[Michael Onken]

This is interesting information, that might help fixing this problem. I wonder, that nobody reported this before nor we didn't observe it, if it's already present in 3.5.2...

Michael

[Markus Sabin]

Hi all,

I have encountered the same or a similar problem sending images to a diagnostic workstation with storescu, but I was sure, it could not be an error in the toolkit (until now ). The error occurs with v3.53 and 3.54 of dcmtk.
I have modified DcmTCPConnection::write:

Code: Select all

  int iRet =  send(getSocket(), (char *)buf, nbyte, 0);
  if(iRet <= 0)
  {
        int iLastError = GetLastError();
        LPVOID lpMsgBuf;
        FormatMessage(  FORMAT_MESSAGE_ALLOCATE_BUFFER |
	        FORMAT_MESSAGE_FROM_SYSTEM |
	        FORMAT_MESSAGE_IGNORE_INSERTS,
	        NULL,
	        iLastError,
	        MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT), // Default language
	        (LPTSTR) &lpMsgBuf,
	        0,
	        NULL
	        );		
            iLastError = 0;

  }
  return iRet;

and set a breakpoint to the line iLastError = 0; When the error occurs, the GetLastError() is 10054 (WSAECONNRESET), meaning "An existing connection was forcibly closed by the remote host."

It would be very helpful for me to know if this is the same issue and currently being addressed by the OFFIS team or if this is a different problem

Thanks in advance

Markus

[Michael Onken]

Hi Markus,

since now we've only found this error on side of the server. There we've got another error number:

10053
WSAECONNABORTED The virtual circuit was terminated due to a time-out or
other failure. The application should close the socket as it is no longer
usable.

Perhaps your and Bernds problem (which resides on client side) is not connected to "our" problem... However, I'll write to this thread, if there are some news about this issue.

Regards,
Michael

[Markus Sabin]

Hi Michael,

thank you for your quick reply. The error message you get on the server side might be related to our problem (Currently, I can not see what is exactly going on on the server side). If I find out more, I will post it here as well.

Best regards

Markus

[bkuemmer]

Our problem is also on the client side, and from this discussion I would tend to agree that this is probably not an error in the toolkit, but the connection is for some other reason terminated by the server...

As I said, we are also seeing very slow transfer rates once the association has been established.

Cheers
Bernd

[Michael Onken]

Hi all,

after another surprise - Marco could not reproduce this error on his windows machine - it seems we've found the reason for our server side error. I've tested turning off or quitting some network enabled background processes on my machine - virus scanner, firewall etc.

The solution seems to be the personal firewall, hooray If in memory, every now and then dcmnet ends up in the described error when writing to the socket. Only after completely unloading (not just stopping) the firewall, the error does not occur. I was using Kerio Personal Firewall 4; using the windows firewall I've tested afterwards, this error didn't occur.

So at this time it seems, that this is a curious bug in the firewall I'm using (since now*g*) and there is no bug in DCMTK regarding multiprocess mode under windows. Anyway we might try to find out, why this only happens in multiprocess mode, even if only one or two SCUs are served. If there are more news, I let you know

Regards,
Michael

[bkuemmer]

That's an interesting observation... because I think the machines which show our storescu problem also have a third party firewall installed.

I will check that.

Thanks
Bernd

[ezarowny]

Our company has found that this is most frequently caused by anti-virus software and comes up very often under high-load situations if anti-virus software is installed. It's usually the antivirus software locking files.

[ezarowny]

Actually, we still get the problem without the anti-virus.

Upon further inspection the network interface seems to misbehave. I can't browse to any websites or use the SOAP GUI for our program.