The basic purpose is : If you can't connect with the
client then do the client connect with you.

This is simple: Do than the client connect in permanent
way with your public server.

Now, 'our public server' must to send the commands to
the client computer, by the connection initializated by the client to
obtain the data for remote control. This is the traditional schema used
by a tipical remote control program. To refer to this connection, we can
name it as 'primary client connection'.

But our target is do it web accesible by a simple navigator.
It implies to consider other circumstances imposed by the Web navigation.
The first thing to consider is how to do than the commands sended by our
navigator go to the client machine. We must remember than the client haven't
any open port or listen connection. So We must do it through the 'primary
client connection'. In addition, there is another aspects used by the
Navigators, for example it can do several request at the same time. Each
of this request is composed by this main steps:

Connect to the server

Send the http command

Wait for response

Disconnect from the server

So, in any way, we must have a web service in any computer
to ask by the navigator. As we can't have the web service in the client
computer ( There is not any open listen thread port ). Then we must have
the web service in the bridge machine.

In this way, the navigator send the http commands to
this 'bridge' web service, and it 'resend' the command to the client .
Wait for the client response. And send this response to the navigator.
Then we have the effect than the result came from Bridge computer, but
really it was generated by client machine.

Serveral user can access to the web service in the same
time. And each of them can do simultaneous request to the server. This
request in parallel are procesed in sequential form ( one after another
one) through the 'primary client connection'. We can say than the 'bridge'
actue as a funnel (several request are canalized in only one connection).

You have a computer client A with GranPrimo (Gp A) installed but you
can not access to it, (because it is behind a firewall or router). You
have another computer B (with Gp B) that can be accessed by you and the
computer A.

Then Gp A can open a client connection with Gp B. Gp B opens a random
listen port that relays the http connections to Gp A (like a bridge) ,
and captures the result in Gp A to send it as response. Then you connect
(by your internet browser) with Gp B ( to the normal bridge listening
port). You obtain the common menu access to Gp B and a linked list of
other Gp connected to it. With this link ( that is a random port in Gp
B) you access to the another computer and emulate a full connection to
computer A that cannot be accessed by you.

A special situation is when you cannot access to computer A, but computer
A can access to you. Then your own computer can work as Gp B. Gp A opens
a 'Bridge' connection to you. Then you access to your local GP (with 127.0.0.1
direction) and can link with computer A

How actue the GpIndy bridge ?

The TGpIndySSL component is listening connections in any port or doble
port (SSL and Normal) connections ( To determine what listen ports you
want, use the modoserver property (gpsnone, gpsnormalonly, gpsSSLonly,
gpsboth). A client connection is a permanent connection which is initializated
by a TcooLink component to the GpServer.

When start a client connection, it keep on-line as an indy thread ( really
is a TIdPeerThread in Indy9 and TIdContext in Indy10 ). And linked with
it, gp generate a new Tcp/ip listen server in a apropiate port
which is the bridge. This bridge server process the incomming
request by sending this to the client thread connections, and waiting
for result to serve the request. That is, emulate a little web server
which actue as a virtual server of the remote client connection. So, any
support person in local area or who have access to this bridge listen
port, have the access to the client supported.

For acept the connections, the client must send the correct user/password
to the server. But the client can define its own password too. ( to confirm
the support asistance).

TGpIndySSL handle the client connections and/or the normal gp request
It can be defined in service property: ServeGranprimo for all kind of
connections and ServeBridge for only bridge connections. (You no need
all the gp functionally to use it as a bridge, so for only bridge purposes,
is more secure if you only active the bridge features )

TGpIndySSL

Create a listening thread which actue as
bridge to the persistent connection of another Gp client.