Application paradigms and sockets

The lecture places the application layer at the top of the TCP/IP suite. It provides services to Internet users and receives services from the transport layer. The other four layers make the application layer’s services possible.

Each lower layer has a narrower job:

• The data link layer (Layer 2) is node to node communication.
• The network layer (Layer 3) is host to host communication.
• The transport layer is process to process communication. It provides logical communication between applications or processes running on different hosts.

At the application layer the connection between two processes is logical. The two ends behave as if they talk directly, though the data crosses every layer below.

The layered design lets the Internet add, remove or replace a protocol in any layer. The lecture gives the conditions:

• A protocol added to a layer must use the services of a protocol in the layer below.
• Removing a protocol means changing whichever protocol in the next layer up used its services.
• Application layer protocols provide services to no other protocol in the suite, so they can be removed easily.
• New application layer protocols can be added easily as long as they can use the services of the transport layer protocols.

In the client-server paradigm the service is provided by a server process, and that process must be running all the time. The client initiates contact and requests service. The server provides the requested service. The lecture’s examples are the World Wide Web, the file transfer protocol (FTP) and email.

In the peer-to-peer (P2P) paradigm there is no central server. Responsibility is shared between peers, and a computer can both provide and receive services. The lecture’s examples are Skype, BitTorrent, IPTV and Internet telephony.

A client-server program needs a set of instructions that tell the lowest four layers of the TCP/IP suite to open the connection, send and receive data from the other end, and close the connection. These instructions form an Application Programming Interface (API). It sits between the process at the application layer and the operating system, which encapsulates the lower four layers.

The socket interface is one such API. A socket is not a physical entity. It is an abstraction, created and used by the application program. The application can use a socket the same way it uses other data sources and sinks.

For process-to-process communication, the application layer sees only two sockets. The client treats its socket as the thing that gives the response. The server treats its socket as the thing that sends the request. Two processes communicate through a pair of socket addresses.

When you write a new application you decide which transport protocol it uses, and the choice seriously affects what the application processes can do. The lecture lists the two options:

• TCP: connection-oriented, reliable, with flow control, error control and congestion control.
• UDP: connectionless, unreliable, simple, small delay and low overhead.

The standards table in the lecture pairs common applications with their protocol. Its columns extracted interleaved from the slide, so the pairing below follows the row order of the extraction.

Applications differ in what they need from the transport layer: whether data loss is acceptable, how much bandwidth they use, and whether timing matters. The lecture’s table is badly scrambled in the extraction, so only the readings that are unambiguous are given here.

• Email, web and file transfer need no data loss, take elastic bandwidth (they use what is available) and are not time sensitive.
• Remote access needs no data loss, with elastic bandwidth and a timing need under 150 ms.
• VoIP is loss tolerant. The lecture quotes 150 ms with an ITU-T reference, and audio and video bandwidth ranges (5 Kb to 1 Mb for audio, 1 Kb to 5 Mb for video as the slide prints them).
• Interactive games are given as ~100 ms. Financial applications are marked “Depends” for timing.