next »

[.]

Hi everyone,

Wondering if someone has any suggestions to make our GDC client (2.11) more stable over a VPN connection.

The VPN connection is renegotiating frequently (and that is being looked at by Cisco) but this instability seems to cause the GDC to crash with connection time out, even though the VPN tunnel is still up but pauses for upto a second.

I have been running standard setting of gui.connection.timeout = 30 and gui.protocol.pingTimeout = 600 in the fglprofile so would imagine it should be fine.

Not all clients go down - normally each one though is down every 10-15 minutes especially if they were typing at the time the connection pauses.

Any help would be greatly appreciated.

(We have 2.30 at the back end so we can try upgrading the GDC if you think it might help).

Thanks

Jeff

[.]

Jeff,

first of all, using a GDC 2.11 with a FGL 2.30 is not supported. Today, only GDC (starting from 2.21) is able to deal with an older version of FGL, down to 2.11. So beside your specific issue, it's highly recommended to use only matching versions.

Then, when using direct connection, the mechanism relies on the socket, so it will depend on how the socket is reported to be broken, and this really depends on your system. Maybe a Wireshark run could help you understanding if the socket is really down or not.
If the socket is down, there is unfortunately no way to recover, as there is no reconnection mechanism in direct mode.

There, the solution may be to move to a GAS based architecture - but 2.30 based: the GAS mechanism is based on http queries, and a new connection is made often (depends on the http keep-alive configuration). So in case your vpn goes down and the connection is broken, GDC will re-send the previous message and GAS will re-send the previous answer.
Again, this needs 2.30 GDC and GAS, as older versions where not able either to resend (GDC) or to understand a resent request (GAS).

Another idea to test would be to use an ssh tunnel, maybe ssh has less problems with a weak connection than we have.


Regarding the entries in fglprofile:
gui.connection.timeout : it only defines the timeout for the initial connection, i.e. the first time fglrun connects to GDC/GAS.
gui.protocol.pingTimeout : the front end has to send a message every x seconds. If no message has been sent before the timeout defined in gui.protocol.pingTimeout, the runtime considers the front-end died silently ; this is mainly used to free the license, as the socket connection may still be considered as up by the system.
So in your case, these two entries would not help.

Regards,
Pierre-Nicolas