February 20, 2019
Hot Topics:

Objects and Client/Server Connections

  • May 8, 2006
  • By Matt Weisfeld
  • Send Email »
  • More Articles »

Identifying the Client

One very useful piece of information that the Server can collect is some sort of client ID. We can actually embed this in the Employee object itself. This ID can take the form of a simple ID number or we can inspect any attribute on the object. In this example, rather than use the employeeNumber attribute, let's use the employeeName attribute. This will make it easier for us to read and identify the client more easily.

We have already created an Employee object with the employeeName name of Joe, so let's create one with the employeeName of Mary. We can use the following line of code in the 2nd client application.

        	 Employee mary = new Employee(250, "Mary");

On the server side, we can add a line of code to print out the name of the specific Employee object.
         	employee = (Employee )serverInputStream.readObject();

                System.out.println("Serving " + employee.getEmployeeName());

Figure 6 shows what happens when we use two clients. The first Client has the name of Joe and the second the name of Mary. You can see the specific information printed in the client Command Prompt. The Server Command Prompt is more interesting. Note that the Server handles the message from both Joe and Mary and then prints their name. This illustrates that the Server can indeed handle multiple clients. It is important to realize how nicely all of this is packaged into the objects and how the objects are marshaled across the network.

Click here for a larger image.

Figure 6 - Identifying Multiple Clients

Using another Machine on the Network

At this point, rather than using the loopback IP address (""), it is interesting to find another computer on the network and connect to the server from a different machine. There will be no change to the client code except for updating the IP address. To find the specific IP address of the machine, you can use the ipconfig command at the Command Prompt of the Server.

         C:column22cs> ipconfig

This command will provide the appropriate IP address for the server. Simply change the loopback string, "", to the IP address of the Server.

Keeping things in Sync

Getting this client/server system to work requires that both sides use the same classes. This may seem obvious, but it is easy for the two sides to become out of sync. This has to do with one of the strengths of Java. As is often the case, a specific strength can lead to some potentially significant problems if you are not careful.

For example, let's make a change to the Client. Let's say that we want to add a last name to the Employee object as seen in Listing 5.

import java.io.*;
import java.util.*;

public class Employee implements Serializable {

        private String employeeLastName;
        private int employeeNumber;
        private String employeeName;
        Employee(int num, String name) {
                employeeNumber = num;
                employeeName= name;
        public int getEmployeeNumber() {
                return employeeNumber ;
        public void setEmployeeNumber(int num) {
                employeeNumber = num;
        public String getEmployeeName() {
                return employeeName ;
        public void setEmployeeName(String name) {
                employeeName = name;
        public String setEmployeeLastName() {
                return employeeName ;
        public void getEmployeeLastName(String name) {
                employeeName = name;

Listing 5: The Employee with lastName added.

Note the lines in bold. These lines add the functionality of the lastName. However, this obviously changes the Employee class. For example, if the Client compiles on one machine with this change and the Server compiles on another with the old version of Employee, a problem will arise (see Figure 7).

Figure 7 - Incompatible Employee Class

The Server reports the following exception:

java.io.InvalidClassException: Employee; local class incompatible: stream classd
esc serialVersionUID = -2555159439224478262, local class serialVersionUID = 1247

The Employee class the Server uses is different than the one that the Client uses - and this is not allowed. The fact that this can even happen is because Java dynamically loads all classes - there is no linked executable. This is a tricky configuration management issue. If you update a class you must make sure that all distributions of that class get updated.

In this example, the Employee class was updated on the Client, but not the Server. Since the Server was expecting a specific Employee class, an exception was generated when it received a different one. The interesting thing to look at is the fact that a class is assigned a serialVersionUID. When these two serialVersionUIDs do no match, a problem is identified. This is as much a security issue as it is a programming issue.

The Sun documentation states the following regarding the serialVersionUID:

The serialization runtime associates with each serializable class a version number, called a serialVersionUID, which is used during deserialization to verify that the sender and receiver of a serialized object have loaded classes for that object that are compatible with respect to serialization. If the receiver has loaded a class for the object that has a different serialVersionUID than that of the corresponding sender's class, then deserialization will result in an InvalidClassException.


In this article, we expanded upon the basic concepts involved with creating a simple Client/Server model. The code is a complete and functional model.

As we have seen, moving an object from one place to another is often a tricky proposition. In languages such as Java and the .Net languages, while the ability to load objects dynamically is a major strength, we have to deal with the problem of keeping the class versions in sync.

While the example of this article is complete and useful, it is quite basic. There are many more fascinating topics to explore regarding client/server applications.


  • Tyma, Paul, Gabriel Torok and Troy Downing: Java Primer Plus. The Waite Group, 1996.
  • www.javasoft.com

About the Author

Matt Weisfeld is a faculty member at Cuyahoga Community College (Tri-C) in Cleveland, Ohio. Matt is a member of the Information Technology department, teaching programming languages such as C++, Java, and C# .NET as well as various web technologies. Prior to joining Tri-C, Matt spent 20 years in the information technology industry gaining experience in software development, project management, business development, corporate training, and part-time teaching. Matt holds an MS in computer science and an MBA in project management. Besides The Object-Oriented Thought Process
, which is now in it's second edition, Matt has published two other computer books, and more than a dozen articles in magazines and journals such as Dr. Dobb's Journal, The C/C++ Users Journal, Software Development Magazine, Java Report, and the international journal Project Management. Matt has presented at conferences throughout the United States and Canada.

Page 3 of 3

Comment and Contribute


(Maximum characters: 1200). You have characters left.



Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date