Communication between clients and servers.

August 30, 2006

In these posts here , here and here , software architects have been contemplating best ways to communicate between clients and servers – for notification, PUSH or programmatic interaction needs.

In this post, I will highlight the problems we face today and the options we have to overcome the same.

#1 Proxy, Firewall, NAT : Clients (even on extranets) could be separated from the server by proxies, firewalls and could have NATting. This means that (unless you are on the same private LAN- and I wont discuss about that) – the server cannot talk to the client, as it does not know the real IP address of the client (it knows the proxy’s address or that natted by the client network), the client does not have a legal IP address and that it cannot invoke connection to the client ( even if it happened to know the IP address – due to client side firewall – which could be a personal desktop firewall). Hence, a socket connection is completely out of question. The only options available are client pulling (and possibly polling for a simulated push) the information via HTTP and HTTPs protocols only. Now there is a caveat here – that I “believe” that HTTPS protocol has a loophole that lets you establish a socket with the server (HTTP Tunneling) and potentially, server could write on the socket and have a push. Since I do not know any details about it and because I  seem to find any published APIs ( and because I am too old to do socket programming), so I will skip this option. This leaves client initiated HTTP and HTTPs only and Push is a “polled” pull. However, this doesn’t limit your options a lot. You have Queues which work like that, you have SQL Server replication happening via this method, you have web services, you have .NET remoting happening via HTTP and recently you have REST and you could use other data interchange methods like EDI, RSS and the works.

Problem #2: Cross platform/ cross version client support: It is likely that you will have clients which are different operating systems and versions ( even if its the same technology), it is likely that you want to support clients using a different technology as well ( like a .NET server publishing services being consumed by JAVA or LAMP clients). Once you add the support for cross platform client support to your requirements, you will need to cut out custom protocols like .NET remoting. ( unless you publish an SDK in all supported languages for that). However it leaves web-services, REST, other forms of XML interchange, possibly Message Queues as they will have support/APIs in many different languages, possibly it leaves SQL Server Anywhere replication as well as all programming languages will be able to connect to it. Also custom message formats could be included only if parsers are available in all consuming languages.

Problem #3: Control on client environment. With the increasing popularity of Microsoft’s one click technologies, the distribution of thick clients has become a lot easier, however it is far from solved. For example – can we assume that clients will have admin privilages to install the application? Can we assume that the clients will have Windows CD available to potentially install MSMQ if needed? Can we assume that the client environment will support SQL Server? Do they have required ports free? Possibly the user will have admin privilages but no windows CD. This could cut out some projects from the list of options we have.

Problem #4: Complexity: The more the dependencies for the application to work, the higher is the complexity. Possibly, it is best oto use a simple protocol like REST ( requiring simple HTTP post requests and simple XML response with no SOAP envelopes etc.)

Problem #5: Data structure: Is the data structure simple to parse? Or is it too complex? Maybe its better to use SOAP envelope which will do the parsing for you and lets you deal with objects at both ends.

Problem #6: Performance , data size and number of calls: Do we know enough about client hardware to say that they can support MS SQL Server (or the dependency we impose)? Do the replication method we choose provide notification as fast as we need them to? Will the message size and number of interactions make some methods (like XML Parsing) too expensive? Is the throughput requirement very very high?

Problem #7: Message delivery guarantee: What is the tolerance for lost messages? Can the applications retry ?

Once you answer all these questions, you are in a better position to decide which communication method to use.

Personally, I have seen that web services fare best today ( except for some extreme performance requirements). Document style web services and/or REST fare slightly better on performance as well. You need to consider a queue only if the message delivery needs to be guaranteed. 


One Response to “Communication between clients and servers.”

  1. Ruissein Mahon Says:

    Good morning,

    I am a student, who is trying to find some research information about why synchronous data transfer is better than asynchronous data trnsfer, and was wondering if you can possibly help me. Thanks very much in advance for your kind assistance.

    Ruissein Mahon

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: