Introducing Web Applications

Web Applications

Web Applications

After knowing the fundamental of Computer Network, we move to web applications. Most people know the Internet through its applications: the World Wide Web, email, streaming audio and video, chat rooms, and music (file) sharing. The Web, for example, presents an intuitively simple interface. Users view pages full of textual and graphical objects, click on objects that they want to learn more about, and a corresponding new page appears. Most people are also aware that just under the covers, each selectable object on a page is bound to an identifier for the next page to be viewed. This identifier, called a uniform resource locator (URL), uniquely names every possible page that can be viewed from your Web browser. For example,

http://www.sharetelecommunication.blogspot.com/computer-network

is the URL for a page representing this book at Morgan Kaufmann: The string http indicates that the HyperText Transfer Protocol (HTTP) should be used to download the page, www.facebook.com is the name of the machine that serves the page, and computer-network uniquely identifies the page at the publisher’s site.

What most Web users are not aware of, however, is that by clicking on just one such URL, as many as 17 messages may be exchanged over the Internet, and this assumes the page itself is small enough to fit in a single message. This number includes up to six messages to translate the server name (www.sharetelecommunication.blogspot.com)  into its Internet address (xxx.xxx.xxx.xxx), three messages to set up a Transmission Control Protocol (TCP) connection between your browser and this server, four messages for your browser to send the HTTP “get” request and the server to respond with the requested page (and for each side to acknowledge receipt of that message), and four messages to tear down the TCP connection. Of course, this does not include the millions of messages exchanged by Internet nodes throughout the day, just to let each other know that they exist and are ready to serve Web pages, translate names to addresses, and forward messages toward their ultimate destination.

Although not yet as common as surfing the Web, another emerging application of the Internet is streaming audio and video. Although an entire video file could first be fetched from a remote machine and then played on the local machine, similar to the process of downloading and displaying a Web page, this would entail waiting for the last second of the video file to be delivered before starting to look at it. Streaming video implies that the sender and the receiver are, respectively, the source and the sink for the video stream. That is, the source generates a video stream (perhaps using a video capture card), sends it across the Internet in messages, and the sink displays the stream as it arrives. UC Berkeley. The others include a whiteboard application (wb) that allows users to send sketches and slides to each other, a visual audio tool called vat, and a session directory (sdr) that is used to create and advertise videoconferences. All these tools run on Unix—hence their lowercase names—and are freely available on the Internet. Similar tools are available for other operating systems.

Although they are just two examples, downloading pages from the Web and participating in a videoconference demonstrate the diversity of applications that can be built on top of the Internet and hint at the complexity of the Internet’s design. Starting from the beginning, and addressing one problem at a time, the rest of this book explains how to build a network that supports such a wide range of applications. Chapter 9 concludes the book by revisiting these two specific applications, as well as several others that have become popular on today’s Internet.

To be more precise, video is not an application; it is a type of data. One example of a video application is video-on-demand, which reads a preexisting movie from disk and transmits it over the network. Another kind of application is videoconferencing, which is actually the more interesting case because it has very tight timing constraints. Just as when using the telephone, the interactions among the participants must be timely. When a person at one end gestures, then that action must be displayed at the other end as quickly as possible. Too much delay makes the system unusable. In contrast, if it takes several seconds from the time the user starts the video until the first image is displayed, then the service is still deemed satisfactory. Also, interactive video usually implies that video is flowing in both directions, while a video-on-demand application is most likely sending video in only one direction.