2.1 – Principles of Network Applications
- At the core of network applications development is writing programs that run different end-systems and communicate with each other over the network.
- You need to write software that run on multiple end-systems.
- Don’t need to write software for network-core devices
2.1.1 Network Application Architectures
- Application architecture is distinctly different from the network architecture.
- The application developer’s perspective is that the network architecture is fixed and provides a specific set of services to applications
- The application architecture is designed by the application developer and dictates how the application is structured over the various end-systems.
- The developer will likely draw on one of the two predominant architectural paradigms used in modern network applications:
- The client-server architecture
- Peer-to-peer architecture
- Client-server architecture:
- An always-on host (server) which services requests from many other hosts (clients)
- Clients to not directly communicate with each other.
- The server has a fixed, well-known address called an IP address. Which means clients can always contact the server by sending a packet to the server’s IP address.
- Some well known client-server applications:
- A single-server is often incapable of keeping up with all the requests from clients, this we get data centers housing a large number of hosts whom create a large virtual server.
- P2P architecture:
- Minimal (or no) reliance on dedicated servers in data centers. Instead the application exploits direct communication between pairs of intermittently connected hosts (peers). The peers are not owned by the service provider, but are instead desktop and latops controlled by users.
- Many of todays most popular and traffic-intensive applications are based on PTP architecture
- It has a very good self-scalability.
- Each peer generates workload by requesting files, each peer adds service capacity to the system by distributing files to other peers.
- Cost-efficient
- Face challenged of security, performance and reliability due to their highly decentralized structure.
- There exists hybrid architectures too. Like instant messaging applications where servers are used to track IP addresses of users, but messages are sent directly Peer-to-Peer
2.1.2 – Processes Communicating
- In the jargon of operation systems, it is not actually programs, but processes that communicate.
- A process can be thought of as a program that is running within an end system.
- When processes are running on the same end-system they can communicate with each other with interprocess communication using rules that are governed by the end-systems OS.
- Processes on two different end system communicate with each other by exchanging messages across the computer network.
- A sending process creates and sends messages into the network; a receiving process receives these messages and possibly responds by sending messages back
- A network application consists of pairs of processes that send messages to each other over a network.
- For each pair of communicating processes we typically label one of the two processes as the client and the other process as the server.
- Definition of the client and server processes:
- In the context of a communication session between a pair of processes, the process that initiates the communication (that is, initially contacts the other process at the beginning of the session) is labeled as the client. The process that waits to be contacted to begin the session is the server.
- A process sends messages into, and receives messages from, the network through a software interface called a socket.
- A socket is the interface between the application layer and the transport layer within a host. It is also referred to as the Application Programming Interface (API) between the application and the network, since the socket is the programming interface with which network application are built
- The developer has control of everything on the application-layer side of the socket, but has little control of the transport-layer side of the socket.
- What the Dev. Can control on the transport-layer:
- Transport protocol
- The ability to fix a few transport-layer parameters such as maximum buffer and maximum segment size
- To identify the receiving process, two pieces of information needed to be specified:
- The address of the host
- An identifier that specifies the receiving process in the destination host
- The host is identified by its IP address who uniquely identifying the host.
- A destination port number serves the purpose of identifying the receiving process
- F.ex. Http = port 80, SMTP = port 25
2.1.3 – Transport Services Available to Applications
- If a protocol provides such a guaranteed data delivery service, it is said to provide reliable data transfer.
- A transport-layer who doesn’t provide reliable data transfer may be acceptable for loss-tolerant applications such as multimedia applications (video/audio)
- Applications that have throughput requirements are said to be bandwidth-sensitive applications.
- Many multimedia applications are bandwidth sensitive, although some may use adaptive coding techniques to encode the audio/video.
- Elastic applications can make use of as much, or as little throughput as happens to be available. F.ex. E-mail, File transfer and Web transfer.
- A transport-layer protocol can also provide timing guarantees.
- Example: Every bit that the sender pumps into the socket arrives at the receiver socket no more than 100msec later.
- A transport protocol can provide an application with one or more security services.
- Example: In the sending host, a transport protocol can encrypt all data transmitted by the sending process, and in the receiving host, the transport-layer protocol can decrypt the data before delivering the data to the receiving process.
- It can also provide other security services in addition to confidentiality, including data integrity and end-point authentication.
2.1.4 – Transport Services Provided by the Internet
- The Internet makes two transport protocols available to applications, UDP and TCP.
- TCP service model includes a connection-oriented service and a reliable data transfer service:
- Connection-oriented service:
- TCP has the client and server exchange transport-layer control information with each other before the application-level messages begin to flow. This is so-called handshaking procedure alerts the client and server, allowing them to prepare for an onslaught of packets. After the handshaking phase, a TCP connection is said to exist between the sockets of the two processes. The connection is a full-duplex connection in that the two processes can send messages to each other over the connection at the same time. When the application finishes sending messages, it must tear down the connection.
- Reliable data transfer service.
- The communicating processes can rely on TCP to deliver all data sent without error and in the proper order. When one side of the application passes a stream of bytes into a socket, it can count on TCP to deliver the same stream of bytes to the receiving socket, with no mission or duplicate bytes.
- TCP also includes a congestion control mechanism, who throttles a sending process when the network is congested between sender and receiver.
- UDP is a no-frills, lightweight transport protocol, providing minimal services. UDP is connectionless, so there is no handshaking before the two processes start to communicate.
- UDP provides an unreliable data transfer service, that is, when a process sends a message into a UDP socket, UDP provides no guarantee that the message will ever reach the receiving process.
- Messages that do arrive at the receiving process may arrive out of order
- UDP does not include a congestion-control mechanism. UDP can pump data into the layer below at any rate it pleases.
- Throughput and timing guarantees is not provided by todays Internet transport protocols.
- A lot of telephony applications use UDP, but also use TCP as a backup if UDP is blocked in the firewall or some other problems occurs.
2.1.5 – Application-Layer Protocols
- An application-layer-protocol defines how an application’s processes, running on different end systems, pass messages to each other. In particular, an application-layer protocol defines:
- The types of messages exchanged, for example, requests messages and response messages
- The syntax of the various messages types, such as the fields in the messages and response messages
- The semantics of the fields, that is, the meaning of the information in the fields
- Rules for determining when and how a process sends messages and responds to messages
- Some application-layer protocols are specified in RFCs and are therefor in the public domain.
2.1.6 – Network Applications Covered in This Book