Network Application Architectures

Network Application Architectures

Before diving into software coding, you should have a broad architectural plan for your application. Keep in mind that an application’s architecture is distinctly different from the network architecture (e.g. the five-layer internet architecture). From the application developer’s perspective, the network architecture is fixed and provides a specific set of services to applications. The application architecture, on the other hand, is designed by the application developer and dictates how the application is structured over the various end systems. In choosing the application architecture, an application developer will likely draw on one of the two predominant architectural paradigms used in modern network applications: the client-server architecture or the peer-to-peer (P2P) architecture.

Client-Server Architecture

In a client-server architecture, there is an always-on host, called the server, which service requests from many other hosts, called clients. A classic example is the web application for which an always-on web server services requests from browsers running on client hosts. When a web server receives a request from an object from a client host, it responds by sending the requested object to the client host. Note that with the client-server architecture, clients do not directly communicate. Another characteristic of the client-server architecture is that the server has a fixed, well-known address, called an IP address. Because the server has a fixed, well-known address, and because the server is always on, a client can always contact the server by sending a packet to the server’s IP address. Some of the better-known applications with client-server architecture include web, FTP, Telnet, and e-mail. The client-server architecture is shown in fig. 2.2(a).

Often in a client-server application, a single-server host is incapable of keeping up with all the requests from clients. For example, a popular social-networking site can quickly become overwhelmed if it has only one server handling all of its requests. For this reason, a data center, housing a large number of hosts, is often used to create a powerful virtual server. The most popular internet service – such as search engines (e.g. Google and Bing), internet commerce (e.g. Amazon and e-Bay), web-based email (e.g. Gmail and Yahoo Mail), social networking (e.g. Facebook and Twitter) – employ one or more data centers. Google has 30 to 50 data centers distributed around the world, which collectively handle search, YouTube, Gmail, and other services. A data center can have hundreds of thousands of servers, which must be powered and maintained. Additionally, the service provides must pay recurring interconnection and bandwidth costs for sending data from their data centers.

P2P Architecture

In a P2P architecture, there is minimal (or no) reliance on dedicated servers in data centers. Instead the application exploits direct communication between pairs of intermittently connected hosts, called peers. The peers are not owned by the service provider, but are instead desktops and laptops controlled by users, with most of the peers residing in homes, universities, and offices. Because the peers communicate without passing through a dedicated server, the architecture is called peer-to-peer. Many of today’s most popular and traffic-intensive applications are based on P2P architectures. These applications include file sharing (e.g BitTorrent), peer-assisted download acceleration (e.g. Xunlei), Internt Telephony (e.g. Skype), and IPTV (e.g. Kankan and PPstream). The P2P architecture is illustrated in fig. 2.2(b). We mention that some applications have hybrid architectures, combining both client-server and P2P elements. For example, for many instant messaging applications, servers are used to track the IP addresses of users, but user-to-user messages are sent directly between user hosts (without passing through intermediate servers).

One of the most compelling features of P2P architecture is their self-scalability. For example, in a P2P file-sharing application, although each peer generates workload by requesting files, each peer also adds service capacity to the system by distributing files to others. P2P architectures are also cost effective, since they normally don’t require significant server infrastructure and server bandwidth (in contrast with client-server designs with datacenters). However, future p2P applications face three major challenges:

  1. ISP Friendly : Most residential ISPs (including DSL and cable ISPs) have been dimensioned for “asymmetrical” bandwidth usage, that is, for much more downstream than upstream traffic. But P2P video streaming and file distribution applications shift upstream traffic from servers to residential ISPs, thereby putting significant stress on the ISPs. Future P2P applications need to be designed so that they are friendly to ISPs
  2. Security : Because of their highly distributed and open nature, P2P applications can be a challenge to secure.
  3. Incentives : The success of future P2P applications also depends on convincing users to volunteer bandwidth, storage, and computation resources to the applications, which is the challenge of incentive design