Thin Client  Concept

 Full Story

  Features

 Concept

 Prices & Options

 Download


The Thin Client delivers performance, low bandwidth requirement and a tight integration with the windows environment.

The Thin Client is based on the client/server concept, providing block mode transmission between the windows and the Unix components of the Thin Client. The utilization of the Thin Client eliminates the key strokes transmissions between the windows application and the host. Most emulation programs that perform such processing are highly sensitive to the network performance and this is highly noticeable on dial up connections. With such an approach, the network performance normally degrades on peek times due to the high demand and the numerous small packets being transmitted back and forth because of the echoing  of the keystrokes performed on individual clients.

The main objective of the Thin Client is to eliminate this sensitivity to the network performance and utilization, to provide comfort and efficiency to the end users at all times, regardless of the type of connection. With the increase demand Vs mobile computing,  it is imperative to provide the users with a predictable response time regardless of the network topology and bandwidth, the Thin Client is highly optimized for all kinds of connections, there are no third party involved, its windows component interact directly with its Unix components to deliver the best possible response time at all times. 

The following flow chart demonstrate a connection using the Thin Client and highlight the different Thin Client components.


Thin Client Connection

This flowchart highlights the different processes involved in a Thin Client connection.

Thin Client requests a connection to the host

 

On the PC Proexec,exe starts the OpenASP.exe version that was last used to connect to this host. If it is the first connection for this host, it will use the default OpenASP.exe which is the last one to start for any host. If it is the very first connection to any host, it will use the last installed OpenASP.exe

Proexec terminates.

The Thin Client (OpenASP) passes information about it's version, this includes versions of all the different PC components associated with the Thin Client.

The PROsync host component receives the Thin Client connection requests

 

It verifies the version information against the versions required by the host, versions required by the host are updated when the Open/36 version is updated.

If the version matches the required version, PROsync will notify the Thin Client that it can proceed with the connection, see Thin Client connects to the host.

If the version do not match the required version, PROsync will notify the Thin Client that it cannot proceed with the connection, that it's version is incorrect, it might mean that an update is required, it can also mean that a different version of the Thin Client should start. Since the Thin Client supports hosts requiring different versions, the required version may already be available on the PC.

 

Thin Client Version Control

 

When the Thin Client is notified of a version mismatch, it will terminate and pass the required versions information to PROsync.exe, responsible for version switching and autoupdate.

PROsync.exe will verify if the components required are already installed on the PC.

If the components are already installed, it will restart PROexec and indicate which version of the Thin Client should be started, PROexec will start the proper OpenASP.exe and terminate.

If one or more of the required components are not present on the PC, PROsync will download it from the host the required components.

When the download is completed and that the required versions are automatically installed, it will restart PROexec and indicate which version of the Thin Client should be started, PROsync will terminate.

PROexec will start the proper OpenASP.exe and terminate.

 

Thin Client Connection to the host

 

When the required version of the Thin Client is started, the Thin Client is ready to initiate a connection to the host.

The Thin Client initiates a connection with the main Thin Client listener on the host (PROcnnct)

PROcnnct will fork the Open/36 processes involved in the session (PROtermx), and pass over the conversation with  the Thin Client to PROtermx which from then on is the only process communicating with the Thin Client.

All data transmission is performed between PROtermx and the Thin Client.

Data is exchanged in block mode, no key strokes are passed from the Thin Client to the host's component until it is required by the program, eliminating echoing and redundancy, limiting packets transmission to the minimum and providing your end users with a local data entry environment, regardless of the network topology and bandwidth.


Thin Client Session

A Thin Client session involves bi-directional transmission of screens and data between the Thin Client and the host components. This flowchart highlights the different processes involved in a Thin Client session for both character and GUI modes.

Thin Client Connection to the host

 

All data transmission is performed between PROtermx and the Thin Client.

The Thin Client receives static and dynamic screen formats from the host, screen formats are composed of major attributes, constants (static), and variable data. Both variable data and constants have attributes such as Output only, Input only, Input/Output, screen positioning, underline, high intensity, data type, etc....

The Thin Client handles all key strokes locally and updates the program I/O buffers locally. When the program logic requires the I/O buffers to be sent back, the Thin Client transmits the buffers back to the host's components and processing continues.

When the Thin Client receives screen formats and data from the host, it determines if the screen format(s) received are character or GUI formats, the Thin Client is able to handle both and will proceed accordingly.

Receipt of Screen Formats (Character Mode)

 

If a character screen format is received, a memory image of the screen is created, when notified that the screen is completed, when all attributes of the various fields have been set, the Thin Client updates the screen from the image it has created. The screen update is fully optimized to generate the minimal about of screen painting, highly important in a terminal server environment for performance and efficiency.
 
The Thin Clients will listen for more transmission or will proceed in data entry mode by enabling the input fields if any are present.

 

Receipt of Screen Formats (GUI Mode)

 

If a GUI screen format is received, it is received in 3 parts. The Thin Client first receives information about the format it is about to receive. Each format is composed of a static portion (screen layout and constants) and dynamic or volatile data (variable screen data). The static portion of a format never changes unless the format is recompiled, this static information is automatically cached on the PC and will never be received again unless it has changed on the host.

Based on the screen information received, the Thin Client verifies if it is already in the cache. If it is, it will only request the variable data from the host. If the format is not in the cache or if the cache does not contain the updated version of the format, it will request both the static and variable data, and it will update the cache with the new static portion of the format so it will not be transmitted until it changes.

Once the caching verification and update is completed, the Thin Client will create all the necessary controls (edit boxes, combo boxes, list boxes, frames, date controls, ...) required by the format.

The Thin Clients will listen for more transmission or will proceed in data entry mode by enabling the input fields if any are present.