HP Remote Graphics 4.2.0 User's Guide

60 seconds) or greater are not necessarily practical as the connection usually becomes useless and only frustrates the user with a waiting time that tries their patience.

In the case of the Sender, the RGS Sender property, Rgsender.Network.Timeout.Error, also defines a required maximum network timeout value independent of Receiver settings. Due to legacy issues, the Sender first starts up using the maximum of either the Rgsender.Network.Timeout.Error or Rgsender.Network.Timeout.Dialog property (discussed later) to set an internal error timeout for method invocations between the Sender and Receiver as well as sync- pulse detection.

When the Receiver negotiates its connection, it notifies the Sender of its error timeout value. The Sender adopts the lesser of both timeouts to use for sync-pulse error detection. If the user later adjusts the Receiver value greater than the Sender error timeout, the Sender caps itself to its own timeout value. The total combined error timeout can never exceed the Sender's error timeout value. If a sync-pulse or an invocation between the Receiver and Sender exceeds the lesser of either limit above, then the Sender will disconnect the Receiver. The user must initiate a reconnect to the Sender to restore connectivity. Note that there is no equivalent timeout warning in the Sender that the Receiver will display. The Sender does not inform the Receiver of its error timeout value. The connection simply drops at the end of the computed timeout unless the network stack responds to an earlier network error.

The following examples demonstrate the final behavior. When the Sender error timeout is 30 seconds and the Receiver error timeout is 5 seconds, then the Sender uses 5 seconds for its sync-pulse detection since this is the minimum of both. If the Receiver error timeout is adjusted to 60 seconds, then the Sender uses a value of 30 seconds for sync-pulse detection since this is, again, the minimum of both timeouts. The timeout for invocations between the Sender and Receiver is 30 seconds in both cases.

A larger error timeout for the Sender is not recommended. If the Receiver and Sender connection terminates ungracefully, then the Sender could possibly take as long as its error timeout value to determine the connectivity loss and fully terminate the connection. From the time of actual network disruption until the error timeout expires, the Sender will not send image updates to all other Receivers (if it is serving multiple Receiver connections). This will hang the interactivity of other users for no apparent reason. After the error timeout expires, the Sender removes the one connection and continues updating all other Receivers.

If the network stack determines a network failure has occurred, it can shutdown the connection or entire network interface prior to expiration of the error timeout. For example, if a network cable is pulled on a Receiver system, the Receiver system might determine that it has lost its network and shutdown networking completely. In this case the Receiver application might catch the network exception more quickly than its timeout because the system error flows back to the receiver instead of waiting for recovery. Consequently, this results in a full Receiver disconnection before reaching its timeout threshold.

Dialog timeouts specify the maximum time that a message/response dialog appears or is waited upon between the Receiver and Sender. Invocations between the Receiver and Sender requiring user interaction often need much higher timeout

110