HP t505 RDP Connection Drop Detection - Page 3

Advantages of connection drop detection, Tuning or disabling the timeout values, Similarly

Get HP t505 PDF manuals and user guides View all HP t505 manuals
Add to My Manuals
Save this manual to your list of manuals

Page 3 highlights

Advantages of connection drop detection With conventional RDP connections before RDP 8.1, there is no end-to-end connectivity check. This means that the data on the screen might not be current. This might be unimportant for a kiosk displaying advertising, but it might be critical in an application such as financial trading or medical diagnosis. Most commonly, lack of connection-drop notification leads to the frustrating situation of a system that appears unresponsive to user input. Connection drop events are logged in the ThinPro connection logs. Logged information can sometimes be helpful in problem diagnosis. For example, if an RDP server becomes unresponsive each night at 2 a.m. while a backup of the server is being performed, a connection loss might be noted in the connection logs. Tuning or disabling the timeout values While the default timeouts were chosen to be reasonable for most RDP environments with a solid LAN connection to a moderately loaded server, no set of timeouts will be optimal for all situations. For instance, in a kiosk it might be more desirable to live with a momentarily-frozen connection than to display the warning dialog. In those cases, the warning can be fully disabled in the RDP connection settings dialog. On a WAN or a noisy network, packet drop and retransmittal may mean that the six-second warning timeout is too short and a 10-second or 15-second timeout might be more appropriate. On the other hand, in an environment where it is absolutely essential that the data be known to be current, a four-second warning timeout might be desirable. Similarly, it might be desirable to adjust the recovery timeout to give more time for natural network recovery (without forcing a quick reconnect). The error timeout can be lengthened to accommodate known periodic network or server outages. For instance, if it is known that the server is going to become unresponsive each night for three minutes while network switches are reconfigured, an error timeout of six minutes would allow time for that outage with the potential for full recovery. Finally, to enter a state where no connection drop checks are performed at all, all three timeouts could be disabled. Note All timeout values are in milliseconds, so you have to divide by 1000 for their equivalent in seconds. 3

  • 1
  • 2
  • 3
  • 4
Advantages of connection drop detection
With conventional RDP connections before RDP 8.1, there is no end-to-end connectivity check. This means that the data on
the screen might not be current. This might be unimportant for a kiosk displaying advertising, but it might be critical in an
application such as financial trading or medical diagnosis. Most commonly, lack of connection-drop notification leads to the
frustrating situation of a system that appears unresponsive to user input.
Connection drop events are logged in the ThinPro connection logs. Logged information can sometimes be helpful in
problem diagnosis. For example, if an RDP server becomes unresponsive each night at 2 a.m. while a backup of the server is
being performed, a connection loss might be noted in the connection logs.
Tuning or disabling the timeout values
While the default timeouts were chosen to be reasonable for most RDP environments with a solid LAN connection to a
moderately loaded server, no set of timeouts will be optimal for all situations. For instance, in a kiosk it might be more
desirable to live with a momentarily-frozen connection than to display the warning dialog. In those cases, the warning can
be fully disabled in the RDP connection settings dialog. On a WAN or a noisy network, packet drop and retransmittal may
mean that the six-second warning timeout is too short and a 10-second or 15-second timeout might be more appropriate.
On the other hand, in an environment where it is absolutely essential that the data be known to be current, a four-second
warning timeout might be desirable.
Similarly, it might be desirable to adjust the recovery timeout to give more time for natural network recovery (without
forcing a quick reconnect).
The error timeout can be lengthened to accommodate known periodic network or server outages. For instance, if it is known
that the server is going to become unresponsive each night for three minutes while network switches are reconfigured, an
error timeout of six minutes would allow time for that outage with the potential for full recovery.
Finally, to enter a state where no connection drop checks are performed at all, all three timeouts could be disabled.
Note
All timeout values are in milliseconds, so you have to divide by 1000 for their equivalent in seconds.
3