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,
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.