Bridge connection

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





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







Teléfono: 978-610539 - Fax: 978-610861 -Trav.Agustina Aragón 1,1e 44002 Teruel ( España ).webmaster

Copyright © 1997-2004 , [Multi-Informatica Teruel, S.L].La información contenida en este documento está sujeta a modificaciones sin previo aviso. Otros productos u organizaciones mencionadas aquí son marcas comerciales o marcas registradas propiedad de sus respectivas organizaciones o propietarios.