Please, Dojo - I'm trying to detail the exact behaviour of a CUBE client connecting to a DMA via
.NET-Remoting>Eventing (this to facilitate FW configs).
On connection to a DMA, I seem to get at least one connection established, however the client switches to polling mode.
The output of a netstat on the client would show something like this:
It seems the ports in the "high port range" (49152 through 65535) are allowed on the client - the connection is actually "ESTABLISHED" to port 8004 of the server - via client port 51134, but then why the client has a second connection open in "TIME WAIT" and eventually switches to polling?
Is more than one port required on the client for eventing?
Or could the server be configured to use polling regardless of the connection successfully established between client port 51134 and server port 8004?
Cube settings for the above test were like this:
Any steer will be helpful
Need to resume testing on this – I seem to have different numbers of connections depending on the environment – I will update the thread as soon as I gather some more data
Hi Alberto,
I see that this question has been inactive for a long time. Do you still need more information about this? If not, could you select the best answer to indicate that no further action is needed here?
As this question has now been inactive for a very long time, I will close it. If you still want more information about this, could you post a new question?
Do note that eventing connections are set up from the server towards a random port that was opened by the client process (Cube). If Cube opened port 12345 for listening on, it is the server that will try to reach this port to send events to.
The "Switching to polling" popup will show up in Cube if Cube did not receive any event over this port after about 30 seconds of subscribing with the server. Cube will then start polling for events.
On server side, a similar mechanism kicks in that will stop it from trying to send events over a failing callback connection. You'll see information events with text "Fallback to polling for xxxxxx: xxxxxx [xxxxx:12345]" as well as logging in SLNet.txt "Removing eventing callback for xxxxxx (XXXXX) because of xxxxxxx"
Using ConnectionSettings.txt or Cube settings to force polling can prevent the connection from trying to use eventing. In that case, polling should be used straight away and you should not see the popup.
Some documentation links that might be useful:
Thanks for the links, Wouter
I had checked these before – I undertstand only one connection is required on the client to receive the EVENTING information flow from the server port 8004
Not too clear as to why my test client shows the connection successfully established via one of the ports in the high dynamic range (let’s say “54321”), a netstat shows even more ports opened, but then the clients goes to polling.
Will add a new answer with an additional screenshot from today’s checks – could it be that at OS layer the ports are opened but then are not used due to network firewalls, hence why more than a port is open for listening on the client side?
Hi Alberto,
Concerning your last question: this is configurable in the ConnectionSettings file on the server. In your case you can use below
* type=RemotingConnection;polling=1000;zip=true
Thanks Jen – will verify on the related agents.
It makes sense that the server side options can overwrite the client side preference, but I’m not clear on the connection established – would the the high port range still be used even for polling if enabled on the client?
Wouter, Rene, Jens adding an additional trace here.
Based on this drawing, I'm led to think that only 1 connection is required from a CUBE client random port (random but in the 49152-->65535 range)
towards port 8004 on the server
however this netstat output shows me more than one port open towards server port 8004 and I'm not able to explain why multiple ports are used - actually 11 ports have an established connection in this example - so a bit strange to see the client reverting to "polling" mode when 11 connections are established towards server port 8004 - any other checks I may have to do?
If the connection is "Established" can I exclude there are any FW still blocking the required port?
Hi Alberto,
Since you are connected with ‘polling’ instead of ‘eventing’, your Cube client is represented on the left-hand side in the schematic you added in your answer here above, and you only have connections going from your client to the server (towards port 80/443 and port 8004 of that server). The originating ports from where your client machine is initiating the connection, are always random. And there can indeed be multiple connections made at the same time to allow multithreading. A webbrowser will also make multiple connections to port 80/443 of a website when navigating to it, and this will also be originating from a random port in the higher ranges. So the connections we are seeing here, have nothing to do with eventing if I’m not mistaken…
I’m not understanding why the client connects through polling though.
Options have been added to apply the case in the middle of this diagram.
The server is configured to allow eventing by default, and so are my client side options (configured in CUBE) – the netstat output would also show that the connection is established though one of the client ports in the eventing range – so, when connections are even established, what could still trigger the failback to polling?
.NET Remoting is not really firewall friendly, so I believe it might be difficult what you are trying to achieve here. .NET Remoting is also deprecated, and therefore we have a replacement, namely gRPC. This new communication channel only requires 443 and therefore it's going to be a lot easier for firewall configurations...
gRPC is currently available in preview in the latest release (10.3.2) and will be supported in production in one of the upcoming releases. So, it might be worth looking at that as a more decent solution instead of losing time on this .NET Remoting which is EOL anyhow...
Could not agree more, Bert – indeed it is quite a large range of ports that Microsoft designed in .NetRemoting for eventing to work, but once that is allowed, I’ve always been able to get it to work – we are using DM 10.2.10.0 now, but can surely check a newer version of DM if this set-up becomes redundant once https comms are in place.
As for more recent versions of CUBE & DataMiner, are there any additional restrictions added on a client Windows Firewall when CUBE is installed?
Sharing a screenshot in a new reply
(cannot upload images in comments – https://community.dataminer.services/new-feature-suggestions/add-image-in-comments/ )
Bert, Rene, Jens
Sharing an inbound rule I wasn't aware of - found it while looking into the Inbound rules on the local Windows firewall: is this a rule added by default when installing recent versions of Cube?
The origin on my test client seems to be the folder where CUBE is installed:
Alberto,
You can configure Cube to only use polling see (Eventing or polling | DataMiner Docs). This is less performant but should align with what you are trying to achieve if I understand correctly?
Thanks, Rene
We’re trying to move away from this set-up, as clients don’t seem to cope very well while handling the polling required to handle alarms during storms.
Long story short, I believe this was a shortcut that was used when the monitored network was sufficiently small, but it is way bigger now, so we’d rather restore the eventing mechanism as the default behaviour, so that the load on the server doesn’t increase linearly (on SLNet) with the number of connected clients.
Based on testing, I believe 9 ports are open on the client side in the attempt to establish the communication for Eventing - sadly, none of them is working for me, but based on testing with DM 10.2.10.0-12242, I can see 9 ports towards 2 different DMAs:
1) .7 is my client IP, .11 is the DMA where connection with port 8004 is expected;
I can see 9 ports, seven are in Time_Wait while two ports show an established connection - nevertheless, Cube switches to polling
2) same here, .7 is my client, .213 is the DMA, where 8004 seems to be in communication with 9 ports open on the client side - still no joy, Cube fails eventing and switches to "polling" again 
Hi Alberto,
I see that this question has been inactive for some time. Have you found a solution for this yet? If yes, could you share some more information about this, and select the best answer (using the ✓ icon)? If not, you can also contact techsupport@skyline.be for assistance.