Introduction

• The socket API is an Inter process Communication (IPC) programming interface originally
provided as part of the Berkeley UNIX operating system.
• It has been ported to all modern operating systems, including Sun Solaris and Windows
systems.
• It is a default standard for programming IPC and is the basis of more sophisticated IPC
interface such as remote procedure call and remote method invocation.
• On UNIX-based systems such as BSD or Linux, the API is part of the kernel, or core, of the
operating system.
• Socket is a term borrowed from telephone communications. In the early days, a person
wishing to make a call another person had to go through a human operator, who manually
establishes a connection by physically inserting the two ends of a cable into two specific
receptacles, each assigned to one of the two parties, on a panel of sockets.

4.2 The Socket Metaphor in IPC

Borrowing from the terminology of telephony, the designer of the socket has provided a
programming construct termed a socket. A process wishing to communicate with another
process must create an instance of such a construct (see Figure 4.1). Unlike early
telephony, however, the communication between the parties may be connection-oriented or
connectionless.

Fig 4.1 The conceptual model of the socket API

4.3 The Datagram Socket API

• There are two key protocols at the transport layer of the Internet architecture: User
Datagram Protocol (UDP) and Transmission Control Protocol (TCP).
• The User Datagram Protocol (UDP) allows a packet to be transported using connectionless
communication. The data packet thus transported is called a datagram. In accordance with
connectionless communication, each datagram transported is individually addressed and
routed, and may arrive at the receiver in any order.
 The Java socket API, as with all other socket APIs, provides socket programming constructs that make
use of either the UDP or TCP protocol. Sockets that use UDP for transport are known as datagram
sockets, while sockets that use TCP are termed stream sockets.

4.4 The Connectionless Datagram Socket

• Datagram sockets can support both connectionless and connection-oriented communication at the
application layer. This is so because even though datagrams are sent or received without the notion of
connections at the transport layer, the run-time support of the socket API can create and maintain
logical connections for datagrams exchanged between two processes.

• In Java, two classes are provided for the datagram socket API:

1. The DatagramSocket class for the sockets

2. The DatagramPacket class for the datagrams exchanged

• A process wishing to send or receive data using this API must instantiate a DatagramSocket object or
a socket in short. Each socket is said to be bound to a UDP port of the machine local to the process.

• To send a datagram to another process, a process creates an object that represents the datagram
itself. This object can be created by instantiating a DatagramPacket object which carries:

1. the payload data as a reference to a byte array, and

2. the destination address (the host ID and port number to which the receiver’s socket is bound).

• Once the DatagramPacket object is created and loaded with payload data and destination, the
sending process then invokes a call to the send method in the DatagramSocket object, specifying a
reference to the DatagramPacket object as an argument.

In the receiving process, a DatagramSocket object must also be instantiated and bound to a local port, the
port number must agree with that specified in the datagram packet of the sender.

• To receive datagrams sent to the socket, the process creates a DatagramPacket object which references
a byte array and calls a receive method in its DatagramSocket object, specifying as argument a
reference to the DatagramPacket object.
 Fig 4.2 Connectionless and Connection-oriented Datagram Socket

Figure 4.3 illustrates the data structures in the programs for the two processes, while figure 4.4 illustrates
the program flow in the two processes. With connectionless sockets, a socket bound to a process can be
used to datagrams to different destinations. It is also possible for multiple processes to simultaneously
send datagrams to the same socket bound to a receiving process, in which case the order of the arrival of
these messages will be unpredictable, in accordance with the underlying UDP protocol.
 4.3 The data structures in the sender and receiver programs

Fig 4.4 The program flow in the sender and receiver programs

Figure 4.5(a) illustrates a scenario where a process, A, uses a single connectionless socket to
communicate with two other processes in a session. For example, A may receive a datagram ml from B,
followed by a datagram m2 from C, then m3, m4 from B, followed by m5 from C, and so forth.
Alternatively, it is also possible for A to open a separate socket for each of processes B and C, so that
datagrams from the two processes can be addressed and received via 2 separate sockets as shown in fig
4.5(b)

4.5 The Stream-mode Socket API

• The datagram socket API supports the exchange of discrete units of data (that is, datagrams).
• The stream socket API provides a model of data transfer based on the stream-mode I/O of the UNIX
operating systems. By definition, a stream-mode socket supports connection-oriented communication
only.
In stream mode input-output, data is transferred using the concept of a continuous data stream flowing from a
source to a destination (also called a sink).
• Data is inserted or written into a stream by a process that controls the source and data is extracted or
read from the stream by a process attached to the destination. Figure 4.7 illustrates the concept of a data
stream.

Fig 4.7 Using a stream mode socket for data transfer

• Note that the continuous nature of stream allows data to be inserted and extracted at different rates.
Hence the unit of data written and read each time need not match.
• The stream-mode socket API (Figure 4.8) is an extension of the stream-mode I/O model. Using the API,
each of the two processes individually creates a stream mode socket.
• A connection between the sockets is then formed. Data, as a stream of characters, are written into the
sender's socket, which can then be read by the receiver via its socket.
• This is similar to the connectionless datagram socket API, except for the difference in the discrete nature
of the data transported in datagram sockets.

Fig 4.8 The stream-mode socket API

• In Java, the stream-mode socket API is provided with two classes:

– Server socket: for accepting connections; we will call an object of this class a connection socket.
Socket: for data exchange; we will call an object of this class a data socket

Using this API, a process known as the server establishes a connection socket and then listens
for connection requests from other processes.
• Connection requests are accepted one at a time. When a connection is accepted, a data
socket is created for the connection.
• A process that wishes to communicate with the server is known as a client. A client creates
a socket; then, via the server's connection socket, it makes a request to the server for a
connection.
• Once the request is accepted, the client's socket is connected to the server's data socket
so that the client may proceed to read from and/or write to the data stream.
• When the communication session between the two processes is over, the data socket is
closed, and the server is free to accept the next connection request.

4.6 Operations and Event Synchronization

There are two main classes in the stream socket API: the ServerSocket class and
the Socket class. The ServerSocket class is for the establishment of connections, while the
Socket class is for the transfer of data.
For event synchronization, the following operations are blocking:
• Accept (accepting a connection): If no request is waiting, the server process will be
suspended until a request for connection arrives.
• Reading from the input stream associated with a data socket: If the amount of data
requested is not currently present in the data stream, the reading process will be blocked
until a sufficient amount of data has been written into the data stream.

Figure below shows the event diagram for the execution of programs using a socket.

• The ConnectionAcceptor process starts its execution first. The process is suspended when
the blocking accept method is called, then unsuspended when it receives the connection
request from the Requestor.
• Upon resuming execution, the Acceptor writes a message to the socket before closing both
the data socket and connection socket.

The execution of the ConnectionRequestor proceeds as follows:

• A Socket object is instantiated and an implicit connect request is issued to the Acceptor.
Although the connect request is nonblocking, data exchange via the connection cannot
proceed until the connection is accepted by the process at the
• Once the connection is accepted, the process invokes a read operation to read a message
from the socket.
• Because the read operation is blocking, the process is suspended once again until the data
for the message is received, whereupon the process closes the socket and processes the
data.

The figure below shows the program flow in a connection listener and connection requestor
in a stream mode socket API.

4.7 Sockets with Nonblocking I/O Operations

• The APIs discussed till now are basic socket APIs, which provide asynchronous
(nonblocking) send operations and synchronous (blocking) receive operations. Using these
APIs, a process that reads from a socket is subject to blocking.
• To maximize concurrency, threads can be used so that a read operation is performed in a
waiting thread while a separate thread remains active for processing other tasks. However,
in some applications that require extensive use of threads, the overhead can affect the
performance or even the working of the application.
• Alternatively, there are socket APIs that provide nonblocking I/O operations. Using such an
API, neither send nor receive will result in blocking, and it is necessary for the receiving
process to use a listener to be notified of the arrival of the data.
• Asynchronous sockets are available with Winsock and Java1.4 also provides a new I/O
package, java.nio (NIO), that offers sockets with nonblocking I/O operations.

4.8 Secure Socket API

• Secure socket APIs are the socket APIs enhanced with data security measures. Using
conventional socket APIs, data is transmitted as bit streams over network links. The bit
streams, if intercepted by means of tools such as network protocol analyzers, can be
decoded by someone who has knowledge of the data representation of the data
exchanged.
• Hence it is risky to use sockets to transmit sensitive data, such as credit information and
authentication data. To address the problem, protocols have been introduced to secure the
data transmitted using socket APIs. Some of the well-known protocols: Secure Sockets
Layer (SSL) and The Java™ Secure Socket Extension (SSE).

The Secure Socket layer

Secure Sockets Layer (SSL) was a protocol developed by Netscape Communications
Corporation for transmitting private documents over the Internet. An SSL API has methods
or functions similar to the socket API, except that data is encrypted before it is transmitted
over an SSL connection. SSL is supported by modern browsers. When run with the SSL
protocol selected, these browsers will transmit encrypted data using the SSL socket API.
Many Web sites also use the protocol to obtain confidential user information, such as credit
card numbers. By convention, the URL of a Web page that requires an SSL connection
starts with https, instead of http.

The Java Secure Socket Extension

The Java™ Secure Socket Extension (SSE) is a set of Java packages that enable secure
Internet communications. It implements a version of SSL and TLS (Transport Layer
Security) protocols and includes functionalities for data encryption, server authentication,
message integrity, and optional client authentication. Using JSSE, developers can provide
for the secure passage of data between two processes.