Understanding Client-Server Applications -- Part I

Learn the basics of client-server applications and how to develop them. In this Part I of our series on Understanding Client-Server Applications, we discuss the fundamentals of client-server applications, and explore a simple temperature monitoring application to help you understand what you need to consider when creating a client-server application. In Part II, you learn how to develop code samples from scratch as we discuss technologies to speed this process.

What is a client-server application?

Client-server describes an application architecture in which the client requests an action or service from the provider of service, the server. Consider a Web browser and a Web server. When you address a URL in the browser window, it (client) requests a page from a Web server. The server returns an html page to the client, which parses the page (data) and displays it on your computer.

When developing a client-server application, like the Web browser and Web server, you need to consider how you are going to handle developing your application in a team environment and how you are going to handle long-term maintenance. Developing client-server applications parallels developing modular programs. Modular programming separates large applications into smaller constituent pieces to ease development in teams and provide better maintainability. In a client-server application, a module does not have to be part of the same program or even run on the same computer. Each modular function can run on a different device.

How does a client perform?

Client programs request service from a server by sending it a message. Referring back to the Web example, a Web browser is a client we use everyday to request Web pages. For example, when you clicked the link to read this article, your browser sent a message to a Web server in Austin, TX. In response, your browser received the html page you are now reading. A Web browser represents many client programs, which manage the graphical user interface (GUI) or display portion of an application; determining the presentation of the service provided by an application.

What is a server's function?

Server programs process client requests by performing the tasks requested by clients. For example, in a Web browser the Web server returns the html page requested by the client. But client requests and server programs are not always so simple. Consider a more complicated application in which you buy a product on a Web page. In this case, the client informs the server what you are purchasing and the server updates a database with the purchase request. Then, the server informs the client that the order has been placed.

Servers are generally passive as they wait for a client request. During these waiting periods servers can perform other tasks or perform maintenance. Unlike the client, the server must continually run because clients can request service at any time. Clients on the other hand only need to run when they require service. Many server applications allow for multiple clients to request service. For example, while you are reading this page others interested in client-server programming could also request and read the same Web page.

Designing a Temperature Monitoring Application

With a basic understanding of client-server applications, how do you implement this technology for your needs? We touch on a simple application of acquiring temperature readings from a thermocouple. First we break this application into three modules making the project easier to develop and maintain. The first module acquires the readings from the thermocouple, the second module analyzes the raw data and relates it to temperature, and the third module provides a graphical user interface or display. Each module must provide data in a format that is understood by the next module.

After dividing the project into manageable pieces, you have a couple of options. You can write one program to perform all three of these functions on the same computer, or you can distribute the process over multiple machines by running each of the individual routines or functions on different machines. At this point, you need to consider your goals. For example, you may need a client-server architecture if you must access the temperature remotely from a different computer than is collecting the temperature data. In this situation, you can create an architecture in which one computer acquires and analyzes the data and another computer or client queries the data to display it. Figure 1 illustrates how the client and server interact.

The actual architecture of the application depends on your particular needs. If you are acquiring a large number of data points, it may be better to run the acquisition and analysis modules on separate computers. Thus the display client would request the temperature from the computer processing the raw data, reducing interruptions to the data acquisition process.

Server Considerations

In a temperature monitoring application there are certain considerations for designing the server. These include:
· Is there more than one client?
· Are multiple clients served one-at-a-time or simultaneously?
· Are different clients prioritized or treated differently?

In the simplest application, only one remote client requests the temperature from the temperature acquisition computer. In this case the server waits for a request and returns the temperature to the requesting client.

If multiple clients are serviced, the server continually monitors for service requests. The server queues each request as it is received, ensuring all the clients receive the temperature data they request. The application queues each client and services it in a first-come-first-serve (First In First Out -- FIFO) manner. Once the queue is empty, the server continues to wait for new clients. The monitoring process is best broken into two components. One component detects the requests and queues up each client. The second component processes each queued client and performs the task requested one at a time. In this case, the server returns the temperature.

Processing clients one-at-at-time may be suitable for a simple temperature monitoring application. Simultaneously servicing clients is important for more complicated requests that can take a longer time, or if you expect a large number of clients. However, client requests still need to be queued however you design the component that processes the actual request. Servicing each client in different and independent threads or processes can accomplish this.

Some applications require that you give different clients different priorities. A temperature monitoring system can have passive clients, which display the temperature at any given time, and active clients that query the temperature and process it as part of a larger application. You may need to prioritize the active clients over the passive clients. To do this the server must have a method to identify, differentiate, and authenticate the clients requesting service.

To be serviced effectively, the client program must work with the interface or protocol defined by the server. The client program for each of the application architectures described is very similar. In each case the client program must send a temperature request message and must understand the reply from the server. In the case of a server servicing a single remote client or a server servicing multiple clients in a FIFO manner, the client programs have no noticeable difference in architecture. However, a client program interacting with a server that prioritizes different clients has a request mechanism that includes parameters for identification and authentication. This could be as simple as adding two parameters to the temperature request message for an ID and a password that the server can verify.

The server defines the interface for communication between the client and server programs. A well designed interface only exposes how to send messages, what messages are supported, and what the response to each message is to the client. The server is also developed in a modular fashion, separating the message handling mechanism from the functional component processing the request itself. Therefore, you can update the functional component of the server without affecting any clients. This modular approach to a client-server application provides a distributed application for remote temperature monitoring that you can maintain and update without affecting each client and server component.

See Also:
DataSocket

Conclusion

Related Links:
Understanding Client-Server Applications -- Part II

Reader Comments | Submit a comment »

Good Work ! ..
- Ahmad , EMU. - Jul 16, 2008

Great, Thanks
Its very helpful, good explanation.
- Vidya, ....... pavani_net@yahoo.co.in - Feb 15, 2008

was indeed a helpful package! learnt a lot from this article n will appreciate the matter provided!!
- Feb 13, 2008

Very nice. Can make people understand the very basics of Client-Server architecture.
- Siddhartha Sinha. siddhartha.biet@gmail.com - Jan 26, 2008

good
concept was made very clear
- Mallikchiru@yahoo.ca - Aug 24, 2007

Excellent
I fully understood the client/server concept on one reading of this article. Thank you for explaining so clearly.
- Chet, HDA. - Nov 11, 2006

Excellent
- Deepa - Apr 21, 2006

very helpfull for non techno peoples
- ashok, mphasis. tashok2001@rediffmail.com - Dec 28, 2005

Complicated topic in simple terms
Complicated topic in simple terms. Great work. Keep it up
- kumar1997b@yahoo.com - Jul 5, 2005

Good Explanation!
- Merl - Feb 25, 2005

easy to understand
very easy to understand since it contains examples. nice work.
- vilas, quest. vilas.g@quest-global.com - Dec 20, 2004

A very good article for the beginners... waiting for the next part...
- Anirban. anth2@rediffmail.com - Dec 31, 2003

Simply super.......
you done the hard work for this, and you work is very usefull for all. it used for me also so, i would like say thanks to you.
- Venu Gopal. venu_6gopal@yahoo.com - May 22, 2002

Good ! waiting for the next part(s)...
- BEN HAFSIA, CS SI. mohamed.benhafsia@c-s.fr - Sep 24, 2001

Very good Explanation
the analysis of the article is really good
- dileep, Okie world corp. dileep_ch@hotmail.com - Jul 10, 2001

Well Written Waiting for more detailed Version
- Walied Khan, Zebra Technologies. wkhan@zebra.com - Jun 28, 2001

Terrific
Very good. Next month I'll be here.
- ALBERTO P. DA COSTA, INFRANAV IND. E COM. alberto@infranav.com.br - Jun 19, 2001

EXCELLENT!
I am really looking forward to read the Part II!!!
- Nikolai Teofilov, University of Ulm. nikolai.teofilov@physik.uni-ulm.de - Jun 18, 2001

Well written article. I am waiting for more details.
- Ganesh Devaraj, Soliton Automation. ganesh@solitonautomation.com - Jun 3, 2001

Can't wait for part II .
Nice job, refreshed all the basics there is to client-server apps. Having done some temp.measurement myself, i look forward to the next part and see, if I missed sth somewhere :) andres
- Andres Mellik, Cognuse Inc.. amellik@yahoo.com - Jun 3, 2001

EXCELLENT ARTICLE BUT HURRY UP WITH THE 2ND PART PLEASE!!!
This article is excellent for an introduction to CLient-Server applications. I woould like you to include examples of Labview interacting with Datasocket and security.
- Carlos Martinez, I.T.V.. cemp_tec@hotmail.com - May 31, 2001

Very basic start.
Why wait another month for the second part? I need the information now. The NI web site is very short on COM activeX info, especially real instrument interacing. If you want to interface to Excel, no problem. Look forward to second part. any chance of seeing it sooner? Thanks Les Cronin
- Les Cronin, Spectronic Devices Ltd.. les@SpectronicDevices.com - May 26, 2001

Great
Whoever designed this whole thing should get a raise, this made all of the information easy to find and easy to read, thank you for having such a wonderful programmer on this job....
- Bob Fuller, NTB. HBFuller3@aol.com - May 25, 2001

Thanks for the big picture, non-techno lingo.
- Robert Trask, PE, Corning Incorporated. traskre@corning.com - May 23, 2001

Terrific article!
I'm very impressed! The article was very informative, and developed the subject in a logical way. GREAT JOB!
- Mark Maxfield, TSIWerks. Mark@siwerks.com - May 11, 2001