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.
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 uses 4 different variables to identify distinct connections:
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
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!
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: