Building a strong robust client-server system

Question

I need some help with regards to implement a pre-designed system that has 4 components and several constraints. I've spent approximately 50 hours trying to determine the best way to build this system; however, I do not think I have a strong enough solution as of right now.

~~~ The Background Information ~~~

The purpose of this project is to allows for business owners (and their developers) to access data remotely. It has 4 components.

1. A Web Service
2. A Client
3. A Database For the webservice
4. A Database For the Client

The user interface must be in the form of a web service as it is one of the design requirements.

The Client is stored on a business owners computer (Which houses their database). It is a local program programmed in the .net platform.

Business owners access the web service which then accesses a client, requests for data and passes that data to the client.

The above is known and unchangeable (as I am not the person who makes the project specification)

~~~ The Real Problem ~~~

The problem is, The Client may not necessarily be at the same place every time, the IP of the client is subject to change. The Client may also simply not be online at the time of the request from the business owner.

~~~ My Present Solution ~~~

My Present solution to this problem is to create a TCP/IP Server on the Client. When the Client is turned on or started, it can "register" its TCP/IP Server credentials (the information needed to contact it) into the server along with some identification information.

~~~Editted for clarity~~~ When the Web Service gets a request, it can open a random TCP/IP connection and let the client (Remember the TCP/IP Server is on the Client) know it has a request for data. The Client can then get the request, process it and send a response with a 'request Id'.

Based on this request Id, the web service can receive a call, let the client know it has a request, the client can go query the web service for the request, retrieve the request, process the request and send a response back to the web service which can then process the response (extract the request Id from it) and send it back to the appropriate web service caller.
~~~ End Edit ~~~ (wow that sentence is a mouthful to read out loud)

~~~ What I Would Like ~~~

I feel my solution is sketchy and I would really like some feedback as to potential pitfalls that I may not see and better ways of approaching it.

Answer 1

I may be all wet here, but it sounds like the crux of the problem is that you need to initiate a communication from the server to the client.

Your proposed solution (that you are uncomfortable with) is to install a web server on the client machine (the laptop, in my comments) and register the IP address of it with your main server.

Having 2 or more web servers talk to each other on a peer relationship is pretty common and seems to work well. The issue lies in whether or not you're comfortable with any/all infrastructure needed to get that 2nd web server installed and running reliably, and whether or not you'd have firewall issues (many companies block inbound HTTP requests).

A couple other ideas come to mind:

• Simple polling. Have your client poll the main server periodically. Not an ideal solution (you may have thousands of poll requests per successful 'hit'), but it could work. the poll request / 'no' reply could be pretty cheap to implement and should scale well.
• Long polling - your client requests some data from the server. If the server has the data, it returns it. If it doesn't have it, it either blocks or sends little "keep alive" messages back to the client.

There's a good write up in this SO question

See also the Wikipedia entry on Long polling

You didn't mention any scaling issues - how many clients you expect, how quickly they must respond, how often they'll initiate requests, etc. Those answers will probably dictate which approach is appropriate.