I have an application that has a client/server architecture. The
communication between the two is set-up using ip addresses. The server
is started and the client connects to the server by specifying the
server ip address.

This architecture runs into a problem if the meeting server is behind
a network router. This is because the router has an ip address that
represents computers hidden by it. If the server is behind the router
its ip address is meaningless in front of the router. Thus if the
client wants to connect, it can’t.

I realize that the network router can be configured to route certain
network traffic through it to a specific computer such as a webserver.
For this application though I’m trying to stay away from having to
reconfigure the router in order to have everything work properly.

Are there ways to solve this using computer software? If there is no
software solution I would appreciate suggestions on hardware
solutions.

I realize a solution can pose a security risk because this method can
be used to side step a firewall.

	Below is a description of a way to solve the problem. I’m not happy
with the solution because it introduces a whole slew of issues that go
along with hosting your own unique server on the Internet
(reliability, bandwidth, system capacity, cost, administration, etc.)

Possible Solution – Connection Server

	A possible solution to the above problem is to create a software
server that resides out on the general Internet and establishes and
maintains a connection between the server and client(s).

	The following are the steps that would enable connection:
-	Server starts up and connects to Connection Server 
-	Connection Server stores Server information about this connection
(Unique Identifer (UID) of Server, time of connection, etc.
-	Client software is started and Server UID is typed into client
-	Client establishes connection with Connection Server stating its ip
own address and the UID of the server it wants to connect to
-	Connection Server mediates the traffice between the client(s) to
server

In addition to the above architecture I would also like to be able to
support multiple server/client connections using one connection
server. Thus the connection server will probably have to have a client
listener and a server listener. Then it would have to pass off
connections to free ports on the connection server. This would require
port management. For example, reclaiming free ports once a connection
dies.

The solution you have described is pretty much all that can be done,
with the only exception being if the client is able to accept
connections from the net. (ie, it's not behind a NATing router.) In
this case your connection server would be able to inform the server of
the clients IP and the port it's listening on. This would probably
easyiest to manage at the connection server. EG:-

The client connects to the connection server.

The client reads the local IP of the connection and sends this to the
cs

The cs compares the IP of the clients incoming connection to the IP
supplied by the client, if the IPs do not match the client is flagged
as being firewalled.

(The above process could be applied to the server too.)

The client requests a connection to a server:-
  If the server is not firewalled:-
     The server is told to listen for a connection, the server replies
with the listening port number.
     The client is told to connect to the servers IP and port.
     The connection to the client is closed.
  If the server is firewalled but the client isn't
     The client is told to listen for a connection, it responds with
the listening port number.
     The server is told to connect to the clients IP and port.
     The connection to the client is closed.
  If both partys are firewalled:
     The connection is managed by the cs.

You should probably never allow clients to be connected for too long.
(unless they're having a managed connection with a server.)
Servers should be routinely sent a ping request, and the ones that
don't respond in a timely manner should be disconnected.

Hope this is some help.

Ian

It might also be a good idea to use UDP for the server management, as
this would prevent the cs having a large amount of open connections.
(also servers would then  just have to send a ping packet to the cs,
you could delete information on servers that haven't pinged you for
some length of time.)

Having the client do the initial connection negotion this way would
also keep ports free on the cs. Assuming you're using TCP for the data
transfer, when both partys are firewalled they would just be
instructed to connect to the cs for the duration of the transfer.

I have actually implemented something similar to this in java with a
fair degree of sucess. I have a machine(connection server) outside the
firewall running on port 80 listening for http requests. The client
makes http requests to the connection server giving it the destination
server(D.S) name and port. the connection server then makes a tcp
connection(well it can actually be anything!) with the D.S and
maintains it. the client is then given a unique connection CID for
this connection and the client, each time it makes an http request
sends the CID along with the command that has to be sent to the D.S.
client keeps polling the connection server and reads the data which
has arrived from the D.S. if there is any new command to be sent to
the D.S , connection server sends it to the server, if there isn't
any, it just closes the client socket(just what a webserver would do).
both the client and connetion server are multithreaded to handle all
these blocking calls and multiple connections.
               The idea is that no firewalls block connections on port
80. so my client does a http request to get through the firewall. my
connection server acts like a webserver to the client and acts like a
client to the D.S. There will be no persistant connections from inside
the firewall and no opening of multiple sockets on connection server.
shastry

Another way to solve this would be to put a SOCKS proxy server outside
of the firewall. Tell your server application to run it's server
sockets through the SOCKS proxy (Java has support for this built in).
Then tell your clients to connect to the SOCKS proxy server on
whatever port you've decided to run your service on.

If you're implementing this in Java, the upside is that turning on
SOCKS support involves setting some system properties. If you decide
later not to use SOCKS, just stop setting the system properties and
your code will simply bind on the localhost (no recompile necessary).

That said, there are inherent dangers to running a proxy outside of
the firewall.

Hello, to infinitezero-ga

      Sorry for the lag in reply. For some reason I wasn't getting the
emails that indicate an update to my question.

      On to your response. It sounds like you've developed what I
need. Can you please reply back to discuss. What's your price?