URLs and URLConnections provide a relatively high-level mechanism for
accessing resources on the Internet. Sometimes your programs require
lower-level network communication, for example, when you want to write
a client-server application.
In client-server applications, the server provides some service, such as
processing database queries or sending out current stock prices. The client
uses the service provided by the server, either displaying database query
results to the user or making stock purchase recommendations to an
investor. The communication that occurs between the client and the server
must be reliable. That is, no data can be dropped and it must arrive on the
client side in the same order in which the server sent it.
TCP provides a reliable, point-to-point communication channel that client-
server applications on the Internet use to communicate with each other. To
communicate over TCP, a client program and a server program establish a
connection to one another. Each program binds a socket to its end of the
connection. To communicate, the client and the server each reads from
and writes to the socket bound to the connection.
What is a Socket ?
Normally, a server runs on a specific computer and has a socket that is
bound to a specific port number. The server just waits, listening to the
socket for a client to make a connection request.
On the client-side: The client knows the hostname of the machine on
which the server is running and the port number to which the server is
connected. To make a connection request, the client tries to rendezvous
with the server on the server's machine and port.
If everything goes well, the server accepts the connection. Upon
acceptance, the server gets a new socket bound to a different port. It needs
a new socket (and consequently a different port number) so that it can
continue to listen to the original socket for connection requests while
tending to the needs of the connected client.
On the client side, if the connection is accepted, a socket is successfully
created and the client can use the socket to communicate with the server.
Note that the socket on the client side is not bound to the port number used
to rendezvous with the server. Rather, the client is assigned a port number
local to the machine on which the client is running.
The client and server can now communicate by writing to or reading from
Definition: A socket is one endpoint of a two-way communication
link between two programs running on the network. A socket is
bound to a port number so that the TCP layer can identify the
application that data is destined to be sent.
The java.net package in the Java platform provides a class, Socket, that
implements one side of a two-way connection between your Java program
and another program on the network. The Socket class sits on top of a
platform-dependent implementation, hiding the details of any particular
system from your Java program. By using the java.net.Socket class
instead of relying on native code, your Java programs can communicate
over the network in a platform-independent fashion.
Additionally, java.net includes the ServerSocket class, which
implements a socket that servers can use to listen for and accept
connections to clients..
Program 9999 Client Program
A server program typically provides resources to a network of client programs.
Client programs send requests to the server program, and the server program
responds to the request.
One way to handle requests from more than one client is to make the server
program multi-threaded. A multi-threaded server creates a thread for each
communication it accepts from a client. A thread is a sequence of instructions that
run independently of the program and of any other threads.
Introduction to TCP/IP
TCP and IP were developed by a Department of Defense (DOD) research project to
connect a number different networks designed by different vendors into a network of
networks (the "Internet"). It was initially successful because it delivered a few basic
services that everyone needs (file transfer, electronic mail, remote logon) across a very
large number of client and server systems. Several computers in a small department can
use TCP/IP (along with other protocols) on a single LAN. The IP component provides
routing from the department to the enterprise network, then to regional networks, and
finally to the global Internet. On the battlefield a communications network will sustain
damage, so the DOD designed TCP/IP to be robust and automatically recover from any
node or phone line failure. This design allows the construction of very large networks
with less central management. However, because of the automatic recovery, network
problems can go undiagnosed and uncorrected for long periods of time.
As with all other communications protocol, TCP/IP is composed of layers:
IP - is responsible for moving packet of data from node to node. IP forwards each
packet based on a four byte destination address (the IP number). The Internet
authorities assign ranges of numbers to different organizations. The organizations
assign groups of their numbers to departments. IP operates on gateway machines
that move data from department to organization to region and then around the
TCP - is responsible for verifying the correct delivery of data from client to
server. Data can be lost in the intermediate network. TCP adds support to detect
errors or lost data and to trigger retransmission until the data is correctly and
Sockets - is a name given to the package of subroutines that provide access to
TCP/IP on most systems.
Network of Lowest Bidders
The Army puts out a bid on a computer and DEC wins the bid. The Air Force puts out a
bid and IBM wins. The Navy bid is won by Unisys. Then the President decides to invade
Grenada and the armed forces discover that their computers cannot talk to each other.
The DOD must build a "network" out of systems each of which, by law, was delivered by
the lowest bidder on a single contract.
The Internet Protocol was developed to create a Network of Networks (the "Internet").
Individual machines are first connected to a LAN (Ethernet or Token Ring). TCP/IP
shares the LAN with other uses (a Novell file server, Windows for Workgroups peer
systems). One device provides the TCP/IP connection between the LAN and the rest of
To insure that all types of systems from all vendors can communicate, TCP/IP is
absolutely standardized on the LAN. However, larger networks based on long distances
and phone lines are more volatile. In the US, many large corporations would wish to
reuse large internal networks based on IBM's SNA. In Europe, the national phone
companies traditionally standardize on X.25. However, the sudden explosion of high
speed microprocessors, fiber optics, and digital phone systems has created a burst of new
options: ISDN, frame relay, FDDI, Asynchronous Transfer Mode (ATM). New
technologies arise and become obsolete within a few years. With cable TV and phone
companies competing to build the National Information Superhighway, no single
standard can govern citywide, nationwide, or worldwide communications.
The original design of TCP/IP as a Network of Networks fits nicely within the current
technological uncertainty. TCP/IP data can be sent across a LAN, or it can be carried
within an internal corporate SNA network, or it can piggyback on the cable TV service.
Furthermore, machines connected to any of these networks can communicate to any other
network through gateways supplied by the network vendor.
Each technology has its own convention for transmitting messages between two
machines within the same network. On a LAN, messages are sent between machines by
supplying the six byte unique identifier (the "MAC" address). In an SNA network, every
machine has Logical Units with their own network address. DECNET, Appletalk, and
Novell IPX all have a scheme for assigning numbers to each local network and to each
workstation attached to the network.
On top of these local or vendor specific network addresses, TCP/IP assigns a unique
number to every workstation in the world. This "IP number" is a four byte value that, by
convention, is expressed by converting each byte into a decimal number (0 to 255) and
separating the bytes with a period. For example, the PC Lube and Tune server is
An organization begins by sending electronic mail to Hostmaster@INTERNIC.NET
requesting assignment of a network number. It is still possible for almost anyone to get
assignment of a number for a small "Class C" network in which the first three bytes
identify the network and the last byte identifies the individual computer. The author
followed this procedure and was assigned the numbers 192.35.91.* for a network of
computers at his house. Larger organizations can get a "Class B" network where the first
two bytes identify the network and the last two bytes identify each of up to 64 thousand
individual workstations. Yale's Class B network is 130.132, so all computers with IP
address 130.132.*.* are connected through Yale.
The organization then connects to the Internet through one of a dozen regional or
specialized network suppliers. The network vendor is given the subscriber network
number and adds it to the routing configuration in its own machines and those of the
other major network suppliers.
There is no mathematical formula that translates the numbers 192.35.91 or 130.132 into
"Yale University" or "New Haven, CT." The machines that manage large regional
networks or the central Internet routers managed by the National Science Foundation can
only locate these networks by looking each network number up in a table. There are
potentially thousands of Class B networks, and millions of Class C networks, but
computer memory costs are low, so the tables are reasonable. Customers that connect to
the Internet, even customers as large as IBM, do not need to maintain any information on
other networks. They send all external data to the regional carrier to which they
subscribe, and the regional carrier maintains the tables and does the appropriate routing.
New Haven is in a border state, split 50-50 between the Yankees and the Red Sox. In this
spirit, Yale recently switched its connection from the Middle Atlantic regional network to
the New England carrier. When the switch occurred, tables in the other regional areas and
in the national spine had to be updated, so that traffic for 130.132 was routed through
Boston instead of New Jersey. The large network carriers handle the paperwork and can
perform such a switch given sufficient notice. During a conversion period, the university
was connected to both networks so that messages could arrive through either path.
Need to Know
There are three levels of TCP/IP knowledge. Those who administer a regional or national
network must design a system of long distance phone lines, dedicated routing devices,
and very large configuration files. They must know the IP numbers and physical locations
of thousands of subscriber networks. They must also have a formal network monitor
strategy to detect problems and respond quickly.
Each large company or university that subscribes to the Internet must have an
intermediate level of network organization and expertise. A half dozen routers might be
configured to connect several dozen departmental LANs in several buildings. All traffic
outside the organization would typically be routed to a single connection to a regional
However, the end user can install TCP/IP on a personal computer without any knowledge
of either the corporate or regional network. Three pieces of information are required:
1. The IP address assigned to this personal computer
2. The part of the IP address (the subnet mask) that distinguishes other machines on
the same LAN (messages can be sent to them directly) from machines in other
departments or elsewhere in the world (which are sent to a router machine)
3. The IP address of the router machine that connects this LAN to the rest of the
In the case of the PCLT server, the IP address is 126.96.36.199. Since the first three
bytes designate this department, a "subnet mask" is defined as 255.255.255.0 (255 is the
largest byte value and represents the number with all bits turned on). It is a Yale
convention (which we recommend to everyone) that the router for each department have
station number 1 within the department network. Thus the PCLT router is 188.8.131.52.
Thus the PCLT server is configured with the values:
My IP address: 184.108.40.206
Subnet mask: 255.255.255.0
Default router: 220.127.116.11
The subnet mask tells the server that any other machine with an IP address beginning
130.132.59.* is on the same department LAN, so messages are sent to it directly. Any IP
address beginning with a different value is accessed indirectly by sending the message
through the router at 18.104.22.168 (which is on the departmental LAN).
What Is a Thread?
All programmers are familiar with writing sequential programs. You've
probably written a program that displays "Hello World!" or sorts a list of
names or computes a list of prime numbers. These are sequential
programs. That is, each has a beginning, an execution sequence, and an
end. At any given time during the runtime of the program, there is a single
point of execution.
A thread is similar to the sequential programs. A single thread also has a
beginning, a sequence, and an end and at any given time during the
runtime of the thread, there is a single point of execution. However, a
thread itself is not a program; it cannot run on its own. Rather, it runs
within a program. The following figure shows this relationship.
Definition: A thread is a single sequential flow of control within a
There is nothing new in the concept of a single thread. The real hoopla
surrounding threads is not about a single sequential thread. Rather, it's
about the use of multiple threads in a single program, running at the same
time and performing different tasks. This is illustrated by the following
The HotJava Web browser is an example of a multithreaded application.
Within the HotJava browser you can scroll a page while it's downloading
an applet or image, play animation and sound concurrently, print a page in
the background while you download a new page, or watch three sorting
algorithms race to the finish. You are used to life operating in a concurrent
fashion...so why not your browser?
Some texts use the name lightweight process instead of thread. A thread is
similar to a real process in that a thread and a running program are both a
single sequential flow of control. However, a thread is considered
lightweight because it runs within the context of a full-blown program and
takes advantage of the resources allocated for that program and the
As a sequential flow of control, a thread must carve out some of its own
resources within a running program. (It must have its own execution stack
and program counter for example.) The code running within the thread
works only within that context. Thus, some other texts use execution
context as a synonym for thread.
The Life Cycle of a Thread
Lets look at the Life cycle of a thread: how to create and start a thread,
some of the special things it can do while it's running, and how to stop it.
The following diagram shows the states that a Java thread can be in during
its life. It also illustrates which method calls cause a transition to another
state. This figure is not a complete finite state diagram, but rather an
overview of the more interesting and common facets of a thread's life. The
remainder of this section uses the Clock applet previously introduced to
discuss a thread's life cycle in terms of its state.
Each thread contained all of the data and methods required for its
execution and didn't require any outside resources or methods. In addition,
the threads ran at their own pace without concern over the state or
activities of any other concurrently running threads.
However, there are many interesting situations where separate,
concurrently running threads do share data and must consider the state and
activities of other threads. One such set of programming situations are
known as producer/consumer scenarios where the producer generates a
stream of data which then is consumed by a consumer.
For example, imagine a Java application where one thread (the producer)
writes data to a file while a second thread (the consumer) reads data from
the same file. Or, as you type characters on the keyboard, the producer
thread places key events in an event queue and the consumer thread reads
the events from the same queue. Both of these examples use concurrent
threads that share a common resource: the first shares a file, the second
shares an event queue. Because the threads share a common resource, they
must be synchronized in some way.
Every Java thread is a member of a thread group. Thread groups provide a
mechanism for collecting multiple threads into a single object and
manipulating those threads all at once, rather than individually. For
example, you can start or suspend all the threads within a group with a
single method call. Java thread groups are implemented by the Thread
Group class in the java.lang package.
The runtime system puts a thread into a thread group during thread
construction. When you create a thread, you can either allow the runtime
system to put the new thread in some reasonable default group or you can
explicitly set the new thread's group. The thread is a permanent member of
whatever thread group it joins upon its creation--you cannot move a thread
to a new group after the thread has been created.
The Default Thread Group
If you create a new Thread without specifying its group in the constructor,
the runtime system automatically places the new thread in the same group
as the thread that created it (known as the current thread group and the
current thread, respectively). So, if you leave the thread group unspecified
when you create your thread, what group contains your thread?
When a Java application first starts up, the Java runtime system creates a
ThreadGroup named main. Unless specified otherwise, all new threads
that you create become members of the main thread group.
Client/server model is a concept for describing communications between computing
processes that are classified as service consumers (clients) and service providers
(servers). The below Figure presents a simple C/S model. The basic features of a C/S
1. Clients and servers are functional modules with well defined interfaces
(i.e., they hide internal information). The functions performed by a client
and a server can be implemented by a set of software modules, hardware
components, or a combination thereof. Clients and/or servers may run on
dedicated machines, if needed. It is unfortunate that some machines are
called "servers." This causes confusion (try explaining to an already
bewildered user that a client’s software is running on a machine called
2. Each client/server relationship is established between two functional
modules when one module (client) initiates a service request and the other
(server) chooses to respond to the service request. Examples of service
requests (SRs) are "retrieve customer name", "produce net income in last
year," etc. For a given service request, clients and servers do not reverse
roles (i.e., a client stays a client and a server stays a server). However, a
server for SR R1 may become a client for SR R2 when it issues requests to
another server (see below Figure). For example, a client may issue an SR
that may generate other SRs.
3. Information exchange between clients and servers is strictly through
messages (i.e., no information is exchanged through global variables). The
service request and additional information is placed into a message that is
sent to the server. The server's response is similarly another message that
is sent back to the client. This is an extremely crucial feature of C/S
The following additional features, although not required, are typical of a client/server
4. Messages exchanged are typically interactive. In other words, C/S
model does not support an off-line process. There are a few exceptions.
For example, message queuing systems allow clients to store messages on
a queue to be picked up asynchronously by the servers at a later stage.
5. Clients and servers typically reside on separate machines connected
through a network. Conceptually, clients and servers may run on the same
machine or on separate machines. However, our primary interest is in
distributed client/server systems where clients and servers reside on
The implication of the last two features is that C/S service requests are real-time
messages that are exchanged through network services. This feature increases the appeal
of the C/S model (i.e., flexibility, scalability) but introduces several technical issues such
as portability, interoperability, security, and performance.
Conceptual Client/Server Model
Client/server applications, an area of vital importance to us, employ the C/S model to
deliver business aware functionalities. C/S applications provide a powerful and flexible
mechanism for organizations to design applications to fit the business needs. For
example, an order processing application can be implemented using the C/S model by
keeping the order processing databases (customers, products) at the corporate office and
developing/customizing the order processing logic and user interfaces for different stores
that initiate orders. In this case, order processing clients may reside on store computers to
perform initial checking and preprocessing, and the order processing servers may exist at
the corporate mainframe to perform final approval and shipping. Due to the critical
importance of C/S applications to business enterprises of the 1990s and beyond, we will
focus on C/S applications in this book.
Client/Server–A Special Case of Distributed Computing
Below Figure shows the interrelationships between distributed computing and
client/server models. Conceptually, client/server model is a special case of distributed-
Interrelationships between Computing Models
A Distributed Computing System (DCS) is a collection of autonomous computers
interconnected through a communication network to achieve business functions.
Technically, the computers do not share main memory so that the information cannot be
transferred through global variables. The information (knowledge) between the
computers is exchanged only through messages over a network.
The restriction of no shared memory and information exchange through messages is of
key importance because it distinguishes between DCS and shared memory multiprocessor
computing systems. This definition requires that the DCS computers are connected
through a network that is responsible for the information exchange between computers.
The definition also requires that the computers have to work together and cooperate with
each other to satisfy enterprise needs Distributed computing can be achieved through one
or more of the following:
1. File transfer model
2. Client/server model
3. Peer-to-peer model
File transfer model is one of the oldest models to achieve distributed computing at a very
minimal level. Basically, programs at different computers communicate with each other
by using file transfer. In fact, e-mail is a special case of file transfer. Although this is a
very old and extremely limited model of distributed computing, it is still used to support
loosely coupled distributed computers. For example, media clips, news items, and
portions of corporate databases are typically exchanged between remote computers
through file transfers; and e-mail is used frequently to exchange files through embeddings
The C/S model is state of the market and state of the practice for distributed computing at
the time of this writing. C/S model, as stated previously, allows application processes at
different sites to interactively exchange messages and is thus a significant improvement
over the file transfer model. Initial versions of C/S model utilized the remote procedure
call paradigm that extends the scope of a local procedure call. At present, the C/S model
is increasingly utilizing the distributed objects paradigm that extends the scope of local
object paradigm (i.e., the application processes at different sites are viewed as distributed
Peer-to-peer model allows the processes at different sites to invoke each other. The basic
difference between C/S and peer-to-peer is that in a peer-to-peer model the interacting
processes can be a client, server, or both while in a C/S model one process assumes the
role of a service provider while the other assumes the role of a service consumer. Peer-to-
peer middleware is used to build peer-to-peer distributed applications.
Client/server architecture provides the fundamental framework that allows many
technologies to plug in for the applications of 1990s and beyond. Clients and servers
typically communicate with each other by using one of the following paradigm
Remote Procedure Call (RPC). In this paradigm, the client process invokes a remotely
located procedure (a server process), the remote procedure executes and sends the
response back to the client. The remote procedure can be simple (e.g., retrieve time of
day) or complex (e.g., retrieve all customers from Chicago who have a good credit
rating). Each request/response of an RPC is treated as a separate unit of work, thus each
request must carry enough information needed by the server process. RPCs are supported
widely at present.
Remote Data Access (RDA). This paradigm allows client programs and/or end-user tools
to issue ad hoc queries, usually SQL, against remotely located databases. The key
technical difference between RDA and RPC is that in an RDA the size of the result is not
known because the result of an SQL query could be one row or thousands of rows. RDA
is heavily supported by database vendors.
Queued Message Processing (QMP). In this paradigm, the client message is stored in a
queue and the server works on it when free. The server stores ("puts") the response in
another queue and the client actively retrieves ("gets") the responses from this queue.
This model, used in many transaction processing systems, allows the clients to
asynchronously send requests to the server. Once a request is queued, the request is
processed even if the sender is disconnected (intentionally or due to a failure). QMP
support is becoming commonly available.
Initial implementations of client/server architecture were based on the "two-tiered"
architectures shown in below Figure (a) through below Figure (e) (these architectural
configurations are known as the "Gartner Group" configurations). The first two
architectures (Figure below (a) and Figure below (b) are used in many presentation
intensive applications (e.g., XWindow, multimedia presentations) and to provide a "face
lift" to legacy applications by building a GUI interface that invokes the older text-based
user interfaces of legacy applications. Figure below (c) represents the distributed
application program architecture in which the application programs are split between the
client and server machines, and they communicate with each other through the remote
procedure call (RPC) or queued messaging middleware. Figure below (d) represents the
remote data architecture in which the remote data is typically stored in a "SQL server"
and is accessed through ad hoc SQL statements sent over the network. Figure below (e)
represents the case where the data exist at client as well as server machines (distributed
Traditional Client/Server Architectures
Although a given C/S application can be architected in any of these configurations, the
remote data and distributed program configurations are used heavily at present. The
remote data configuration at present is very popular for departmental applications and is
heavily supported by numerous database vendors (as a matter of fact this configuration is
used to represent typical two-tiered architectures that rely on remote SQL). Most data
warehouses also use a remote data configuration because the data warehouse tools can
reside on user workstations and issue remote SQL calls to the data warehouse. However,
the distributed programs configuration is very useful for enterprisewide applications,
because the application programs on both sides can exchange information through
OSF DCE–A Client/Server Environment
The Open Software Foundation (OSF) Distributed Computing Environment (DCE)
packages and implements "open" and de facto standards into an environment for
distributed client/server computing. OSF DCE, also commonly known as DCE, is
currently available on a wide range of computing platforms such as UNIX, OS/2, and
IBM MVS. Figure below shows a conceptual view of OSF DCE. The applications are at
the highest level and the OSI transport services are at the lowest level in DCE (at present,
DCE uses the TCP/IP transport services). The security and management functions are
built at various levels and are applicable to all components. The distributed file access to
get at remotely located data, naming services for accessing objects across the network,
remote procedure calls (RPCs), and presentation services are at the core of DCE. As can
be seen RPCs are at the core of DCE. Additional information about DCE can be found in