Tanenbaum A. Computer Networks
Подождите немного. Документ загружается.
When a user types in the URL
www.furryvideo.com, DNS returns the IP address of Furry
Video's own Web site, allowing the main (HTML) page to be fetched in the normal way. When
any of the hyperlinks is clicked on, the browser asks DNS to look up
cdn-server.com, which it
does. The browser then sends an HTTP request to this IP address, expecting to get back an
MPEG file.
That does not happen because
cdn-server.com does not host any content. Instead, it is CDN's
fake HTTP server. It examines the file name and server name to find out which page at which
content provider is needed. It also examines the IP address of the incoming request and looks
it up in its database to determine where the user is likely to be. Armed with this information, it
determines which of CDN's content servers can give the user the best service. This decision is
difficult because the closest one geographically may not be the closest one in terms of network
topology, and the closest one in terms in network topology may be very busy at the moment.
After making a choice,
cdn-server.com sends back a response with status code 301 and a
Location header giving the file's URL on the CDN content server nearest to the client. For this
example, let us assume that URL is
www.CDN-0420.com/furryvideo/bears.mpg. The browser
then processes this URL in the usual way to get the actual MPEG file.
The steps involved are illustrated in
Fig. 7-47. The first step is looking up www.furryvideo.com
to get its IP address. After that, the HTML page can be fetched and displayed in the usual way.
The page contains three hyperlinks to
cdn-server [see Fig. 7-46(b)]. When, say, the first one is
selected, its DNS address is looked up (step 5) and returned (step 6). When a request for
bears.mpg is sent to cdn-server (step 7), the client is told to go to CDN-0420.com instead
(step 8). When it does as instructed (step 9), it is given the file from the proxy's cache (step
10). The property that makes this whole mechanism work is step 8, the fake HTTP server
redirecting the client to a CDN proxy close to the client.
Figure 7-47. Steps in looking up a URL when a CDN is used.
511
The CDN server to which the client is redirected is typically a proxy with a large cache
preloaded with the most important content. If, however, someone asks for a file not in the
cache, it is fetched from the true server and placed in the cache for subsequent use. By
making the content server a proxy rather than a complete replica, the CDN has the ability to
trade off disk size, preload time, and the various performance parameters.
For more on content delivery networks see (Hull, 2002; and Rabinovich and Spatscheck,
2002).
7.3.6 The Wireless Web
There is considerable interest in small portable devices capable of accessing the Web via a
wireless link. In fact, the first tentative steps in that direction have already been taken. No
doubt there will be a great deal of change in this area in the coming years, but it is still worth
examining some of the current ideas relating to the wireless Web to see where we are now and
where we might be heading. We will focus on the first two wide area wireless Web systems to
hit the market: WAP and i-mode.
WAP—The Wireless Application Protocol
Once the Internet and mobile phones had become commonplace, it did not take long before
somebody got the idea to combine them into a mobile phone with a built-in screen for wireless
access to e-mail and the Web. The ''somebody'' in this case was a consortium initially led by
Nokia, Ericsson, Motorola, and phone.com (formerly Unwired Planet) and now boasting
hundreds of members. The system is called
WAP (Wireless Application Protocol).
A WAP device may be an enhanced mobile phone, PDA, or notebook computer without any
voice capability. The specification allows all of them and more. The basic idea is to use the
existing digital wireless infrastructure. Users can literally call up a WAP gateway over the
wireless link and send Web page requests to it. The gateway then checks its cache for the
page requested. If present, it sends it; if absent, it fetches it over the wired Internet. In
essence, this means that WAP 1.0 is a circuit-switched system with a fairly high per-minute
connect charge. To make a long story short, people did not like accessing the Internet on a
tiny screen and paying by the minute, so WAP was something of a flop (although there were
other problems as well). However, WAP and its competitor, i-mode (discussed below), appear
to be converging on a similar technology, so WAP 2.0 may yet be a big success. Since WAP 1.0
was the first attempt at wireless Internet, it is worth describing it at least briefly.
WAP is essentially a protocol stack for accessing the Web, but optimized for low-bandwidth
connections using wireless devices having a slow CPU, little memory, and a small screen.
These requirements are obviously different from those of the standard desktop PC scenario,
which leads to some protocol differences. The layers are shown in
Fig. 7-48.
512
Figure 7-48. The WAP protocol stack.
The lowest layer supports all the existing mobile phone systems, including GSM, D-AMPS, and
CDMA. The WAP 1.0 data rate is 9600 bps. On top of this is the datagram protocol,
WDP
(
Wireless Datagram Protocol), which is essentially UDP. Then comes a layer for security,
obviously needed in a wireless system. WTLS is a subset of Netscape's SSL, which we will look
at in
Chap. 8. Above this is a transaction layer, which manages requests and responses, either
reliably or unreliably. This layer replaces TCP, which is not used over the air link for efficiency
reasons. Then comes a session layer, which is similar to HTTP/1.1 but with some restrictions
and extensions for optimization purposes. At the top is a microbrowser (WAE).
Besides cost, the other aspect that no doubt hurt WAP's acceptance is the fact that it does not
use HTML. Instead, the WAE layer uses a markup language called
WML (Wireless Markup
Language
), which is an application of XML. As a consequence, in principle, a WAP device can
only access those pages that have been converted to WML. However, since this greatly
restricts the value of WAP, the architecture calls for an on-the-fly filter from HTML to WML to
increase the set of pages available. This architecture is illustrated in
Fig. 7-49.
Figure 7-49. The WAP architecture.
In all fairness, WAP was probably a little ahead of its time. When WAP was first started, XML
was hardly known outside W3C and so the press reported its launch as
WAP DOES NOT USE
HTML.
A more accurate headline would have been: WAP ALREADY USES THE NEW HTML
STANDARD.
But once the damage was done, it was hard to repair and WAP 1.0 never caught
on. We will revisit WAP after first looking at its major competitor.
I-Mode
While a multi-industry consortium of telecom vendors and computer companies was busy
hammering out an open standard using the most advanced version of HTML available, other
developments were going on in Japan. There, a Japanese woman, Mari Matsunaga, invented a
513
different approach to the wireless Web called i-mode (information-mode). She convinced
the wireless subsidiary of the former Japanese telephone monopoly that her approach was
right, and in Feb. 1999 NTT DoCoMo (literally: Japanese Telephone and Telegraph Company
everywhere you go) launched the service in Japan. Within 3 years it had over 35 million
Japanese subscribers, who could access over 40,000 special i-mode Web sites. It also had
most of the world's telecom companies drooling over its financial success, especially in light of
the fact that WAP appeared to be going nowhere. Let us now take a look at what i-mode is and
how it works.
The i-mode system has three major components: a new transmission system, a new handset,
and a new language for Web page design. The transmission system consists of two separate
networks: the existing circuit-switched mobile phone network (somewhat comparable to D-
AMPS), and a new packet-switched network constructed specifically for i-mode service. Voice
mode uses the circuit switched network and is billed per minute of connection time. I-mode
uses the packet-switched network and is always on (like ADSL or cable), so there is no billing
for connect time. Instead, there is a charge for each packet sent. It is not currently possible to
use both networks at once.
The handsets look like mobile phones, with the addition of a small screen. NTT DoCoMo heavily
advertises i-mode devices as better mobile phones rather than wireless Web terminals, even
though that is precisely what they are. In fact, probably most customers are not even aware
they are on the Internet. They think of their i-mode devices as mobile phones with enhanced
services. In keeping with this model of i-mode being a service, the handsets are not user
programmable, although they contain the equivalent of a 1995 PC and could probably run
Windows 95 or UNIX.
When the i-mode handset is switched on, the user is presented with a list of categories of the
officially-approved services. There are well over 1000 services divided into about 20
categories. Each service, which is actually a small i-mode Web site, is run by an independent
company. The major categories on the official menu include e-mail, news, weather, sports,
games, shopping, maps, horoscopes, entertainment, travel, regional guides, ringing tones,
recipes, gambling, home banking, and stock prices. The service is somewhat targeted at
teenagers and people in their 20s, who tend to love electronic gadgets, especially if they come
in fashionable colors. The mere fact that over 40 companies are selling ringing tones says
something. The most popular application is e-mail, which allows up to 500-byte messages, and
thus is seen as a big improvement over SMS (Short Message Service) with its 160-byte
messages. Games are also popular.
There are also over 40,000 i-mode Web sites, but they have to be accessed by typing in their
URL, rather than selecting them from a menu. In a sense, the official list is like an Internet
portal that allows other Web sites to be accessed by clicking rather than by typing a URL.
NTT DoCoMo tightly controls the official services. To be allowed on the list, a service must
meet a variety of published criteria. For example, a service must not have a bad influence on
society, Japanese-English dictionaries must have enough words, services with ringing tones
must add new tones frequently, and no site may inflame faddish behavior or reflect badly on
NTT DoCoMo (Frengle, 2002). The 40,000 Internet sites can do whatever they want.
The i-mode business model is so different from that of the conventional Internet that it is
worth explaining. The basic i-mode subscription fee is a few dollars per month. Since there is a
charge for each packet received, the basic subscription includes a small number of packets.
Alternatively the customer can choose a subscription with more free packets, with the per-
packet charge dropping sharply as you go from 1 MB per month to 10 MB per month. If the
free packets are used up halfway through the month, additional packets can be purchased on-
line.
514
To use a service, you have to subscribe to it, something accomplished by just clicking on it and
entering your PIN code. Most official services cost around $1–$2 per month. NTT DoCoMo adds
the charge to the phone bill and passes 91% of it onto the service provider, keeping 9% itself.
If an unofficial service has 1 million customers, it has to send out 1 million bills for (about) $1
each every month. If that service becomes official, NTT DoCoMo handles the billing and just
transfers $910,000 to the service's bank account every month. Not having to handle billing is a
huge incentive for a service provider to become official, which generates more revenue for NTT
DoCoMo. Also, being official gets you on the initial menu, which makes your site much easier
to find. The user's phone bill includes phone calls, i-mode subscription charges, service
subscription charges, and extra packets.
Despite its massive success in Japan, it is far from clear whether it will catch on in the U.S.
and Europe. In some ways, the Japanese circumstances are different from those in the West.
First, most potential customers in the West (e.g., teenagers, college students, and
businesspersons) already have a large-screen PC at home, almost assuredly with an Internet
connection at a speed of at least 56 kbps, often much more. In Japan, few people have an
Internet-connected PC at home, in part due to lack of space, but also due to NTT's exorbitant
charges for local telephone services (something like $700 for installing a line and $1.50 per
hour for local calls). For most users, i-mode is their only Internet connection.
Second, people in the West are not used to paying $1 a month to access CNN's Web site, $1 a
month to access Yahoo's Web site, $1 a month to access Google's Web site, and so on, not to
mention a few dollars per MB downloaded. Most Internet providers in the West now charge a
fixed monthly fee independent of actual usage, largely in response to customer demand.
Third, for many Japanese people, prime i-mode time is while they are commuting to or from
work or school on the train or subway. In Europe, fewer people commute by train than in
Japan, and in the U.S. hardly anyone does. Using i-mode at home next to your computer with
a 17-inch monitor, a 1-Mbps ADSL connection, and all the free megabytes you want does not
make a lot of sense. Nevertheless, nobody predicted the immense popularity of mobile phones
at all, so i-mode may yet find a niche in the West.
As we mentioned above, i-mode handsets use the existing circuit-switched network for voice
and a new packet-switched network for data. The data network is based on CDMA and
transmits 128-byte packets at 9600 bps. A diagram of the network is given in
Fig. 7-50.
Handsets talk LTP (Lightweight Transport Protocol) over the air link to a protocol
conversion gateway. The gateway has a wideband fiber-optic connection to the i-mode server,
which is connected to all the services. When the user selects a service from the official menu,
the request is sent to the i-mode server, which caches most of the pages to improve
performance. Requests to sites not on the official menu bypass the i-mode server and go
directly through the Internet.
Figure 7-50. Structure of the i-mode data network showing the
transport protocols.
515
Current handsets have CPUs that run at about 100 MHz, several megabytes of flash ROM,
perhaps 1 MB of RAM, and a small built-in screen. I-mode requires the screen to be at least 72
x 94 pixels, but some high-end devices have as many as 120 x 160 pixels. Screens usually
have 8-bit color, which allows 256 colors. This is not enough for photographs but is adequate
for line drawings and simple cartoons. Since there is no mouse, on-screen navigation is done
with the arrow keys.
The software structure is as shown in
Fig. 7-51. The bottom layer consists of a simple real-
time operating system for controlling the hardware. Then comes a module for doing network
communication, using NTT DoCoMo's proprietary LTP protocol. Above that is a simple window
manager that handles text and simple graphics (GIF files). With screens having only about 120
x 160 pixels at best, there is not much to manage.
Figure 7-51. Structure of the i-mode software.
The fourth layer contains the Web page interpreter (i.e., the browser). I-mode does not use
full HTML, but a subset of it, called
cHTML (compact HTML), based loosely on HTML 1.0. This
layer also allows helper applications and plug-ins, just as PC browsers do. One standard helper
application is an interpreter for a slightly modified version of JVM.
At the top is a user interaction module, which manages communication with the user.
Let us now take a closer look at cHTML. As mentioned, it is approximately HTML 1.0, with a
few omissions and some extensions for use on a mobile handsets. It was submitted to W3C for
standardization, but W3C showed little interest in it, so it is likely to remain a proprietary
product.
Most of the basic HTML tags are allowed, including
<html>, <head>, <title>, <body>, <hn >,
<center>, <ul>, <ol>, <menu>, <li>, <br>, <p>, <hr>, <img>, <form>, and <input>. The
<b> and <i> tags are not permitted.
516
The <a> tag is allowed for linking to other pages, but with the additional scheme tel for dialing
telephone numbers. In a sense
tel is analogous to mailto. When a hyperlink using the mailto
scheme is selected, the browser pops up a form to send e-mail to the destination named in the
link. When a hyperlink using the
tel scheme is selected, the browser dials the telephone
number. For example, an address book could have simple pictures of various people. When
selecting one of them, the handset would call him or her. RFC 2806 discusses telephone URLs.
The cHTML browser is limited in other ways. It does not support JavaScript, frames, style
sheets, background colors, or background images. It also does not support JPEG images,
because they take too much time to decompress. Java applets are allowed, but are (currently)
limited to 10 KB due to the slow transmission speed over the air link.
Although NTT DoCoMo removed some HTML tags, it also added some new ones. The
<blink>
tag makes text turn on and off. While it may seem inconsistent to forbid
<b> (on the grounds
that Web sites should not handle the appearance) and then add
<blink> which relates only to
the appearance, this is how they did it. Another new tag is <marquee>, which scrolls its
contents on the screen in the manner of a stock ticker.
One new feature is the
align attribute for the <br> tag. It is needed because with a screen of
typically 6 rows of 16 characters, there is a great danger of words being broken in the middle,
as shown in
Fig. 7-52(a). Align helps reduce this problem to make it possible to get something
more like
Fig. 7-52(b). It is interesting to note that Japanese does not suffer from words being
broken over lines. For kanji text, the screen is broken up into a rectangular grid of cells of size
9 x 10 pixels or 12 x 12 pixels, depending on the font supported. Each cell holds exactly one
kanji character, which is the equivalent of a word in English. Line breaks between words are
always allowed in Japanese.
Figure 7-52. Lewis Carroll meets a 16 x 6 screen.
Although the Japanese language has tens of thousands of kanji, NTT DoCoMo invented 166
brand new ones, called
emoji, with a higher cuteness factor— essentially pictograms like the
smileys of
Fig. 7-6. They include symbols for the astrological signs, beer, hamburger,
amusement park, birthday, mobile phone, dog, cat, Christmas, broken heart, kiss, mood,
sleepy, and, of course, one meaning cute.
Another new attribute is the ability for allowing users to select hyperlinks using the keyboard,
clearly an important property on a mouseless computer. An example of how this attribute is
used is shown in the cHTML file of
Fig. 7-53.
Figure 7-53. An example cHTML file.
517
Although the client side is somewhat limited, the i-mode server is a full-blown computer, with
all the usual bells and whistles. It supports CGI, Perl, PHP, JSP, ASP, and everything else Web
servers normally support.
A brief comparison of the WAP and i-mode as actually implemented in the first-generation
systems is given in
Fig. 7-54. While some of the differences may seem small, often they are
important. For example, 15-year-olds do not have credit cards, so being able to buy things via
e-commerce and have them charged to the phone bill makes a big difference in their interest
in the system.
Figure 7-54. A comparison of first-generation WAP and i-mode.
For additional information about i-mode, see (Frengle, 2002; and Vacca, 2002).
Second-Generation Wireless Web
WAP 1.0, based on recognized international standards, was supposed to be a serious tool for
people in business on the move. It failed. I-mode was an electronic toy for Japanese teenagers
using proprietary everything. It was a huge success. What happens next? Each side learned
something from the first generation of wireless Web. The WAP consortium learned that content
matters. Not having a large number of Web sites that speak your markup language is fatal.
NTT DoCoMo learned that a closed, proprietary system closely tied to tiny handsets and
Japanese culture is not a good export product. The conclusion that both sides drew is that to
convince a large number of Web sites to put their content in your format, it is necessary to
have an open, stable, markup language that is universally accepted. Format wars are not good
for business.
Both services are about to enter the second generation of wireless Web technology. WAP 2.0
came out first, so we will use that as our example. WAP 1.0 got some things right, and they
518
have been continued. For one thing, WAP can be carried on a variety of different networks. The
first generation used circuit-switched networks, but packet-switched networks were always an
option and still are. Second-generation systems are likely to use packet switching, for
example, GPRS. For another, WAP initially was aimed at supporting a wide variety of devices,
from mobile phones to powerful notebook computers, and still is.
WAP 2.0 also has some new features. The most significant ones are:
1. Push model as well as pull model.
2. Support for integrating telephony into applications.
3. Multimedia messaging.
4. Inclusion of 264 pictograms.
5. Interface to a storage device.
6. Support for plug-ins in the browser.
The pull model is well known: the client asks for a page and gets it. The push model supports
data arriving without being asked for, such as a continuous feed of stock prices or traffic
alerts.
Voice and data are starting to merge, and WAP 2.0 supports them in a variety of ways. We
saw one example of this earlier with i-mode's ability to hyperlink an icon or text on the screen
to a telephone number to be called. Along with e-mail and telephony, multimedia messaging is
supported.
The huge popularity of i-mode's emoji stimulated the WAP consortium to invent 264 of its own
emoji. The categories include animals, appliances, dress, emotion, food, human body, gender,
maps, music, plants, sports, time, tools, vehicles, weapons, and weather. Interesting enough,
the standard just names each pictogram; it does not give the actual bit map, probably out of
fear that some culture's representation of ''sleepy'' or ''hug'' might be insulting to another
culture. I-mode did not have that problem since it was intended for a single country.
Providing for a storage interface does not mean that every WAP 2.0 phone will come with a
large hard disk. Flash ROM is also a storage device. A WAP-enabled wireless camera could use
the flash ROM for temporary image storage before beaming the best pictures to the Internet.
Finally, plug-ins can extend the browser's capabilities. A scripting language is also provided.
Various technical differences are also present in WAP 2.0. The two biggest ones concern the
protocol stack and the markup language. WAP 2.0 continues to support the old protocol stack
of
Fig. 7-48, but it also supports the standard Internet stack with TCP and HTTP/1.1 as well.
However, four minor (but compatible) changes to TCP were made (to simplify the code): (1)
Use of a fixed 64-KB window, (2) no slow start, (3) a maximum MTU of 1500 bytes, and (4) a
slightly different retransmission algorithm. TLS is the transport-layer security protocol
standardized by IETF; we will examine it in
Chap. 8. Many initial devices will probably contain
both stacks, as shown in
Fig. 7-55.
Figure 7-55. WAP 2.0 supports two protocol stacks.
519
The other technical difference with WAP 1.0 is the markup language. WAP 2.0 supports XHTML
Basic, which is intended for small wireless devices. Since NTT DoCoMo has also agreed to
support this subset, Web site designers can use this format and know that their pages will
work on the fixed Internet and on all wireless devices. These decisions will end the markup
language format wars that were impeding growth of the wireless Web industry.
A few words about XHTML Basic are perhaps in order. It is intended for mobile phones,
televisions, PDAs, vending machines, pagers, cars, game machines, and even watches. For this
reason, it does not support style sheets, scripts, or frames, but most of the standard tags are
there. They are grouped into 11 modules. Some are required; some are optional. All are
defined in XML. The modules and some example tags are listed in
Fig. 7-56. We have not gone
over all the example tags, but more information can be found at
www.w3.org.
Figure 7-56. The XHTML Basic modules and tags.
Despite the agreement on the use of XHTML Basic, a threat to WAP and i-mode is lurking in
the air: 802.11. The second-generation wireless Web is supposed to run at 384 kbps, far
better than the 9600 bps of the first generation, but far worse than the 11 Mbps or 54 Mbps
offered by 802.11. Of course, 802.11 is not everywhere, but as more restaurants, hotels,
stores, companies, airports, bus stations, museums, universities, hospitals, and other
organizations decide to install base stations for their employees and customers, there may be
enough coverage in urban areas that people are willing to walk a few blocks to sit down in an
802.11-enabled fast food restaurant for a cup of coffee and an e-mail. Businesses may
routinely put 802.11 logos next to the logos that show which credit cards they accept, and for
the same reason: to attract customers. City maps (downloadable, naturally) may show
covered areas in green and silent areas in red, so people can wander from base station to base
station, like nomads trekking from oasis to oasis in the desert.
Although fast food restaurants may be quick to install 802.11 base stations, farmers will
probably not, so coverage will be spotty and limited to the downtown areas of cities, due to the
520