Are there any "client side" settings that can prevent CUBE from using Eventing even when the related connection is established?
We've got a default connection set-up that works as expected through
when connecting, the client ".4" can almost instantly start receiving element states and severities
We have the same connection settings configured also for another client, same subnet, same destination DMA, however for the ".7", even if the netstat shows that connections are established via ports of the high dynamic range, this other client keeps reverting to polling:
The Windows Defender settings are not accessible to the user - but given that the connection is "established" at the netstat output, what could be still causing the failback to polling?
Any application log that can give a hint in this specific case?
Filtering the netstat list on port 8004 may not give the full picture. When a client connects to the server using .NET Remoting, an outgoing TCP connection is established from that client to TCP port 8004 on the server. The clientside TCP port will be a randomly assigned port (blue). For the eventing callback channel, the client will start listening on a random TCP port and inform the server of the port number (red, port 63843). The server will then try to establish an outgoing TCP connection to that port, using a random port number on the server side, not 8004.
Incase there is a firewall on the client blocking the incoming callback connection, the client will fall back to polling mode over the outgoing blue connections.
You can better diagnose what is going on by filtering netstat on the process ID of Cube, e.g. netstat -anop tcp | find "16216". This should reveal the listening TCP port, waiting for incoming callback connections from the server, and whether any connection has been established on that port.
(or use Process Explorer like in my first screenshot)