Is there any benefits of using .net remoting eventing over .net remoting polling?
Hi Philip,
Eventing is more efficient and more responsive. With eventing, any changes will be pushed to the DataMiner Cube client instantly, so as events happen they would appear on the screen of the Cube client immediately. Polling means that the Cube client will go and check if there are any updates at fixed time intervals, so when events happen there could be a delay (depending on the time interval used for the polling) before they appear in the client UI. Eventing is the default and preferred method, and polling would typically only be applied if there is a firewall for example between the client and the DataMiner nodes, which prevents the node to push data to the client. Note also that if some clients have to use polling (because of a firewall), you can still use eventing for other clients that are not going through that firewall. More details are available also in the DataMiner User Guide.
Polling with 500 ms or 1000 ms should indeed be perfectly fine in most cases. The only situation I’ve seen where it was noticeable, is with spectrum analyzer elements. If you’re looking at the spectrum traces and there are e.g. 4 updated traces per second, with polling on 500 ms, the UI would only update twice per second and each time show a double update… With all the other events coming in, you will never notice the difference.
Thanks Ben,
We do have firewalls preventing this to some networks. I have implemented the ranges behind the firewall to go straight to polling, in the connectionsettings.txt on the servers.
I’m mainly looking for arguments to allow the large random port range through the firewall that’s currently preventing eventing from working, as I don’t think an argument of a minimal delay in the client updating is a strong enough argument in itself.