GUI ScreenIO Client/Server

How the GUI ScreenIO Network Client Works

All classical client/server applications work pretty much the same way.  Very little data is exchanged between the client and the server, because they only transmit data that's going to be displayed on the client. 

All of the application's I/O and processing occurs on the server, and all of the user interface processing occurs at the client. 

  1. The server runs the GUI ScreenIO Server daemon, which listens for incoming connections from clients.

  2. When a GUI ScreenIO Client sends a connection request to the server, the server daemon verifies that the client is an authorized user and, if so, establishes a two-way connection with the client.
    If the client is a Licensed Client, an encrypted connection is negotiated.

  3. The server then sends the client a list of applications the client is authorized to run.  The client displays the list of applications on a menu. 

    (If your client is registered, you can configure it so that it connects and immediately launches an application instead of displaying a menu.)

  4. When the user selects one of the applications, the client sends the server a request to run that application. 

  5. The GUI ScreenIO Server daemon launches the application and passes it the connection used to communicate with the client.  When licensed clients are uses a new encryption key is negotiated between the server and client.

    Whenever the application (running on the server) calls GUI ScreenIO to display a panel, the GUI ScreenIO server layer detects that the panel is to be displayed remotely, and sends the panel data over the network to the client. 

    The client displays the panel and interacts with the user.  The server is free to process other clients' requests while it waits for a response from this client.

  6. When an event of interest to the application occurs (for example, the user presses a button or selects a menu item), the client sends the panel data to the application on the application running on the server, which processes the event and probably displays another panel...

  7. This back-and-forth communication continues until the user closes the application.  When that happens, the client closes the application panel and redisplays the menu, and the application on the server terminates.
  8. The server daemon then waits for the client to request another application or to disconnect.

2000-2006 Norcom, all rights reserved 


Send feedback to Norcom