Versions prior to 4.0 had only one HostFront server running on a box. The client application was connecting directly to the
HostFront server using an HTTP link or a TCP/IP link. The application had only to specify the HostFront server address and
a port number (the HostFront listening port for TCP/IP connections or the WEB server port for HTTP connections).
As illustrated in the figure below, HostFront Server 5.2 allows you to run more than one HostFront service on the same box
(one per emulation). Moreover, there may also be several boxes making up a cluster, in which case the client application needs
to connect to the cluster service.
With Version 5.2, the client application will need to specify few parameters before establishing a connection. Those parameters
are as follows:
|
• |
Specify whether the client application will use the new version's architecture (Versions 4.0 or later) or that of Version
prior to 3.5.x.
|
|
• |
Specify the address and port of the cluster service (instead of the HostFront server as before in Version 3.5.x) |
|
• |
Specify the type of the connection (i.e., TCP/IP or HTTP). Note that the server-side mode is no longer supported. |
|
• |
Specify the type of emulation to be used, given that more than one emulation (3270 or 5250) may exist on the same box.
|
|
• |
Specify, if needed, the virtual folder and the name of the CGI used for HTTP connection. This applies to both the cluster
and the HostFront servers.
|
Once the above-mentioned parameters have been specified, the Connect() method can be called. A connection is first made
with the cluster service that authenticates the caller and determines which of the HostFront services is available and the
least busy. The address and port of this HostFront service are returned to the client application.
The client application uses the information returned by the cluster service to establish a new connection with the assigned
HostFront service and from this point on communicate directly with this HostFront service without going through the cluster
service, until the disconnect or detach command is sent.
Figure 3: HTTP(S) (non-persistent) connection steps and information
Figure 4: TCP/IP (persistent) connection steps and information
