DC-Chapter-4 : The Socket API

4.1 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 Transmission Control Protocol (TCP) is connection-oriented and transports a stream of data over a logical connection established between the sender and the receiver.

•      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.