Using Remote Graphics Software

values than normal steady-state timeouts. Authentication or authorization dialogs often require more display time than standard messages and alerts due to their importance. The RGS system supports alternate timeouts for user interaction to separate them from operations such as sending graphics and audio content. This enables usable authentication and authorization experiences as well as more reasonable limits for standard messages and invocations.

The Receiver property, Rgreceiver.Network.Timeout.Dialog, (also available from the Receiver Control Panel Network tab), limits the display of incoming and outgoing query dialogs from the Sender requiring user input and interaction. Similarly, the Sender property, Rgsender.Network.Timeout.Dialog, specifies from its side similar limits for Receiver messages and queries. At startup the Sender uses the maximum of either Rgsender.Network.Timeout.Error or Rgsender.Network.Timeout.Dialog properties to define its networking timeout between the Sender and Receiver.

An example of dialog timeouts follows. If User A attempts to connect to User B's desktop, an authorization dialog prompts User B. The RGS Sender prompts User B on the Sender desktop asking for permission to connect User A to the desktop. The RGS Receiver property Rgreceiver.Network.Timeout.Dialog limits how long the Receiver waits on the invocation between the Receiver and Sender before returning failure. The RGS Sender property Rgsender.Network.Timeout.Dialog limits the display of the authorization dialog on the Sender. If either timeout expires without action, the dialog exits and connection is denied by default or it defaults secure. If the Sender timeout is shorter than the Receiver's timeout, the authorization invocation from the Receiver to the Sender usually times out faster that the dialog times out, so the authorization fails. If the Sender timeout is longer than the Receiver's timeout, the authorization dialog expires faster than the invocation from the Receiver to the Sender and the authorization still fails.

Another example follows for a different type of authentication. When a Receiver connects to a Sender running a Linux or HP-UX operating system, the Pluggable Authentication Module (PAM) authenticates the connection. In this case, the PAM subsystem invokes a PAM conversation/callback function that results in the Sender making invocations back to the Receiver to prompt the user with PAM message dialogs. The Sender receives the responses. Typically the dialogs request a username and password, but any message is possible. The timeout for the PAM message/response dialog invoked by the Sender and displayed by the Receiver is the Receiver's Rgreceiver.Network.Timeout.Dialog value.

The maximum of either the Rgsender.Network.Timeout.Error or Rgsender.Network.Timeout.Dialog properties limits how long the Sender will wait for a response. The Receiver controls the display time for the PAM message/response dialog and the Sender controls how long to wait for a response from the Receiver. If either timeout expires, the connection is denied by default or defaults secure if the timeout is exceeded. If the Sender timeout is shorter than the Receiver's timeout, then the authentication invocation from the Sender to the Receiver expires faster than the PAM Authentication Dialog, resulting in a PAM authentication failure. If the Receiver timeout is larger than the Sender's timeout, then the PAM authentication dialog times out faster than the invocation from the Receiver to the Sender and the PAM authentication still fails.

The property Rgreceiver.Network.Timeout.Dialog does not control all dialogs displayed by the Receiver. For example, the authentication dialog for a Windows Sender connection displayed by the Receiver for username and password does not

111