Some of the general characteristics of clients and server applications are, in general, client applications have the following characteristics:
They are applications that become a client temporarily when remote access is needed, but perform other computation locally.
They are invoked by a user and execute for one session.
They run locally on the user's local computer.
They actively initiate contact with a server and so must know the server details.
They can access multiple services as required.
In general, server applications have the following characteristics:
They are special-purpose applications dedicated to providing one service.
They are invoked automatically when a system boots, and continue to execute through many sessions.
They generally run on a shared computer.
They wait passively for contact from remote clients.
They accept contact from clients, but offer a single service.
Note that the word server here is referring to a piece of software. However, a computer running one or more server applications is often also referred to as a server.
We will now write a client/server application pair where:
The Client will take some data from the user and validate it (as in Finger)
The Client will then send this data to the Server for processing (as in Finger)
The Server will process the data and return the results
The Client will receive the results and display the results in some form.
For our example here We will do this by building a Date/Time Service. The client will simply call the server and ask it for the current date and time.
The Date Client/Server Overview
The Date Server is possibly the most complex part of this application, in this case consisting of three main classes:
DateTimeService class - A basic class to get the current date and time when it is called
ConnectionHandler class - This class is used to handle any requests that arrive to the DateServer. This class is specially designed to allow a further transition to a threaded server in later chapters.
DateServer class - This is the main server application, that simply listens for connections and creates a
ConnectionHandler object when a connection occurs to the server
We will choose the port 5050 as the port to which we send and listen to for our service. Both a client and a server need to create their own sockets. On the server we listen to port 5050.
The Date Client is very similar to the Finger client we looked at in the section called “The Finger Client” except that the data transfer uses an Object Stream to send and receive data - we will discuss this later.
We will first discuss what occurs in the client/server application before looking directly at the code. First off, the server is started by typing the command java ee402.DateServer on the BeagleBone/Server machine. The
DateServer starts and begins listening for connections on server port 5050. In Figure 7.6, “The Date Client Creates a Connection to the Date Server.” the
DateClient class is executed by using the command java ee402.DateClient theServer where theServer is the hostname of the physical machine on which the
DateServer class is located. The
DateClient creates a socket and connects to the
DateServer server socket running at port 5050. The
DateServer should accept this connection provided it is not busy.
Figure 7.6. The Date Client Creates a Connection to the Date Server.
Next, as in Figure 7.7, “The Date Server creates a
ConnectionHandler object.” the
DateServer class creates a
ConnectionHandler object to which it passes a reference to the
DateClient's socket details. The
ConnectionHandler class then creates an instance of the
DateTimeService. It also establishes an input/output stream to the
Figure 7.7. The Date Server creates a HandleConnection object.
Next, as in Figure 7.8, “The Date Client passes the command to the
ConnectionHandler .” the
DateClient passes a command to the
ConnectionHandler . In this case the command is a
String object that contains the text
"GetDate". When the
ConnectionHandler receives the
String object it compares it to see if it is a valid command. In our case the only valid command is "GetDate" so if it is this command then the
DateTimeService is called to request the date/time. At this time, since we have not threaded our server application the
DateServer is not actually listening to port 5050, rather it is waiting for a response from the
Figure 7.8. The Date Client passes the command to the HandleConnection.
in Figure 7.9, “The
ConnectionHandler gets the Date/Time and sends it to the Client.” the
DateTimeService sends the data/time details back to the
ConnectionHandler object where it is then passed on to the
DateClient as a
String object such as
"Mon 15th...". The
DateClient will then display the returned data on the client's machine.
Figure 7.9. The
ConnectionHandler gets the Date/Time and sends it to the Client.
Finally as in Figure 7.10, “The
ConnectionHandler shuts down. The DateServer starts listening again.” the
ConnectionHandler object shuts down connection and is destroyed. Control is returned to the
DateServer class and the server once again begins listening to port 5050. The client is now disconnected after having received the data. It now shuts down in our case. The next client is now free to connect to port 5050 on the
DateServer and everything happens again. The
DateServer will listen forever unless we shut it down by typing CTRL-C in the terminal window.
Figure 7.10. The
ConnectionHandler shuts down. The DateServer starts listening again.