DICOM uses TCP (transmission control protocol) as its underlying network transport layer, and despite its widespread and generally successful use around the world for most Internet use, TCP does have some significant limitations. In practice, these limitations are extremely rarely encountered in real life, but they can sometimes be seen in stress test scenarios, and it is then important to to be able to distinguish between those failures which are due to the DICOM application being tested, and those which are intrinsic to TCP itself.

TCP Connection queue

When a server “listens” for incoming connections, those incoming requests are initially handled by the operating system (e.g. Windows) and each then needs to be “accepted” by the server. In order to handle this sensibly however (especially if web servers get hit by DDOS - distributed denial of service - attacks), there is a limit to the number of connections (Associations in DICOM terms) which can be queued waiting for acceptance by the server. In theory, a server can specify the length of this queue, but in practice Windows normally limits the value to the default figure of 5. Since a good DICOM application will at least accept the TCP connection very quickly (this is all prior to DICOM negotiation) this is almost never a problem in live scenarios, but can occasionally cause connections to fail if a test program decides to fire multiple “simultaneous” requests at a server.

TCP Port exhaustion

TCP uses 4 different variables to identify distinct connections:

• Source IP address
• Destination IP address
• Source TCP port
• Destination TCP port

Of these, when a single client is making connections to a single server (listening on the known port such as 104), then 3 of these values are fixed, and only the source port can vary. If many connections are being made very quickly, then this can become a limitations since

1. Windows only uses ports 1024-5000 for outgoing connections (this can be altered using registry values)
2. Each combination of the 4 variables as above may not be re-used for 4 minutes after it was last used.

In practice therefore, any TCP based communication which make > 1000 new connections per minute (to be exact, 3076 in 4 minutes), will always fail, whether that it is using DICOM, http, FTP or any other service based on TCP. Some of these issues can be reduced by “tuning” Windows parameters - see here for a link, but the basic problem will still be hit in extreme testing!

Avoiding these issues

As explained above, these problems are mainly confined to artificial test scenarios, but whatever the situation, it is useful to know ways to reduce them, as listed below:

1. Reduce the number of DICOM associations (i.e. TCP connections). In general, it is always a good thing to send multiple images on one association, and sending one image per association is nearly always a bad idea, both from the point of view of performance and the TCP issues above.
2. If testing the load from multiple clients to a server, make sure that the clients are genuine independent machines (with different IP addresses!) not just multiple instances of a test program, or multiple threads within one program, all running on the same machine.
3. If necessary, “tweak” the Windows registry values as above.