|
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.
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.
|
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.
|
|