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