We are having issues in Q/R to a repository (x 2 servers) behind a load balancer. We have configured mutliple devices with the SINGLE VIP node and we can QUERY but not retrieve. I don’t believe that we should need to set up 1 QUERY NODE (VIP of load balancer) and then 2 receive nodes with the IP Address/AETitle of the individual servers BUT that is what our network team are telling us…
SO…
Are most DICOM devices/scanners promiscuous in receiving the images from the sending node?
Most articles on DICOM configuration behind load balancers have indicated that Direct Server Return is the most effective method of communication back to the requesting device and we can demonstrate that on some RA600 machines and iMacs running Osirix, it doesn’t have to have the configuration of the individual servers entered…so why is it that we cannot make this work?
Does anyone have any other ideas for us to try as we are being told that configuration to route BACK through the VIP would be complex, messy and not best practice…(not that I would want to configure this)?
This is probably something REALLY simple but I am a little stumped so wondered if anyone in the group could help out with some advice?
Can’t help much other than to say we needed to set up both actual IP for receiving communication from our RIS even though we send to the VIP. The messaging comes from the actual IP of whichever server even though we send to the VIP
Hi Simon, not sure if this helps and this is my best guess how our system works based upon at least 10 years experience in best guessing.
Our config has a load balancer (xxx.150) handling incoming DICOM from modalities The load balancer forwards incoming traffic for processing to 3 DICOM servers x.151, x.152, x.153. Q/R connections are sent to the same load balancer IP (xxx.150) but the response is provided by another “DICOM push” server on a different IP (xxx.159).
Therefore, and now I am wildly guessing, i assume there is some service running that picks up the Q/R and passes it to a DICOM server with the instruction of a C-move. As far as I understand the outgoing DICOM traffic does not pass the load balancer.
Thanks Frank - we have the same issue here where we have to set up both nodes as Retrieves cannot be routed via the Load Balancer. that workaround is good to know.
Yes- I am guessing that the C-MOVE instruction sends from the DICOM Server and back to the CLIENT DEVICE directly however, I am assuming that the configuration for this specific server is NOT needed on the CLIENT device, only the VIP.
Hi Simon, not sur if this is helpful (9and you probably know this aready). Also I am not great with config on load balancers, but, here are two DICOM things to consider.
The DICOM Q/R is impleented by two DICOM network service protocols. C-FIND finds what you can get, and C-MOVE sends it. The entity that does the C-FIND should (having slected what you want from the find results) then instigate the C-MOVE from wherever the image set is (the same for C-GET). The entity answeringthe C-FIND may not be the same as the entity that actually sends the images.
The second part is that these DIMSE-C transactions (C-FIND,MOVE,STORE,GET) require a static IP. The load balancer may not be presentingstatic IPs for all these transactions. The Application entities all need to see the static IP they are expecting in the transaction. If the Load Balancer does not reflect this then I expect the Application entity (sener or receiver) may not like it.
Apologies if you already went through this – but I would check what each entity involved is expecting (IP in the DICOM config) comapred to what the Load Balancer is presenting.
Roll on the wider use of DICOM Web Services is what I say
I agree with your explanation around the needs for STATIC IP addresses however, with the implementation of so many PACS systems across the UK and the fact that the workflow will likely be the server nodes that are sending the DICOM data directly to the CLIENT, why isn’t everyone moaning that they have to set up 3 configuration nodes on each device (1 for Query, 2 for receiving- minimum) for EACH DICOM library or repository that they need to get data from……?
Surely, that would be an administrative nightmare, not to mention confusing for users….an example below.
Am looking for someone to debunk the requirement for (at least) 2 nodes for each Q/R/S….anyone?
An example:
A Macbook that needs to send AND Query/Retrieve from PACS, DICOM Research Archive and External Image Library will have the following nodes set up:
Yes, maybe I am not reading your last post correctly there, but if is saying “just three nodes that do everything” - while this might be notionally possible (each node with one AE title and IP) it would require that AE title (behind that IP) to distinguish and act on the three services (send, query,retrieve) as SCU or SCP as required. In reality I think vendors’ setups are different, a VNA may have even separate applications (and separate AE) for query and move.
It’s the way these DICMS-C internet services work. BUT the good thing about the DICOM model is that the network services are separtate, and now can be implemented using DICOM Web Services. This gets roud the static IP issue (adds the poosibility of secure cnnections) and simplfies the transactions a little. But I fear suppliers’ adoption and use of DICOM web services is still in its infancy (please shoot me down if I am wrong - I would welcome this a good news). The reason that web services (in every business sector) has taken off is that it is simpler to implemement than intricate specialised layer 7 protocols - as is shown in this discussion - how difficult the set-up is to maintain.
If you get to the bottom of it - will you update us?
Hi Simon. I might not have understood your situation correctly, but I’ll have a stab:
Query (C-Find):
multiple clients all query 1 IP (VIP), 1 AET, 1 port
load balancer passes query on to one of several PACS servers
response to query passes back to the client with no incident
response may go through the load balancer or not depending on the config - doesn’t really matter in this scenario
So far, so simple. Essentially this looks like web traffic model, which is what the load balancers are optimised for.
Retrieve request (C-Move):
works exactly as per query
only information as to where the images should be sent is the destination AE Title
Retrieve send (C-Store):
this is initiated by the remote PACS
won’t go through load balancer - doesn’t make any sense to do so
PACS - all of them, but I assume they share a single config - will have a lookup table that matches the requested destination AE Title against the destination IP and port to send to
PACS initiates a C-Store to requesting (destination) ‘client’
Thanks for that. Yes, completely agree with what you have put but the challenge comes at the end when the C-MOVE is initiated and the data does NOT go through the load balancer…
Does the CLIENT DEVICE receiving the data from the PACS SERVER asked to perform the C-STORE, have to have the configuration for THAT server within its OWN node list or is it considered promiscuous and just accepts the images from any source?
E.g. Device (1.1.1.1 Port X) queries from VIP (2.2.2.2 Port Y) and the PACS server A (3.3.3.3 Port A) is instructed to do the C-MOVE to the Device on (1.1.1.1 Port X)
NB- (PACS Server B (4.4.4.4 Port B) and PACS Server C (5.5.5.5 Port C) are available behind the load balancer)
Does Device need to have VIP (2.2.2.2 Port Y) and PACS Server (3.3.3.3 Port A) PLUS all the other servers, in order to receive the data or does it just receive it without that requirement?
The crucial bit “Does the device need to have […] in order to receive the data” is the bit I am not clear on!
For the result of the C-Move request, the Device 1.1.1.1 is the C-Store Service Class Provider (SCP), and the PACS (server A, B or C) is the Service Class User (SCU).
The DICOM software on the device needs to decide on its level of promiscuity. And you can usually choose between the following. All assume that the SCU (the PACS) is configured to know the device’s IP and port:
Accept from anyone, don’t check anything
Accept from anyone who knows our (called) AE Title
Accept from specific (calling) AE Titles and knows our (called) AE Title
Accept from specific (calling) AE Titles and knows our (called) AE Title and has a source IP address in our allow-list (or that corresponds to the AE Title being used in our config)
If your QR client software on your device 1.1.1.1 is fixed on being so fussy that it needs to know the source IP address when deciding whether to accept a C-Store request, then you are a bit stuck. In this situation you might like to configure the load balancer in reverse - BUT - you really don’t want to do that. Your IT team are right!
Hopefully, the software on your device, be it a modality, or a mac running Osirix or whatever, is able to be set to anything above the bottom option on that list. Then there is no need to worry about the source IP, and the load balancer is irrelevant.
Hi Ed, very useful and it does make sense, but I’ve not come across any application (bar from the ClearCanvas PACS server many years ago) that provided that level of configuration.
Not quite the same.