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.