When Bob wants to access the messages in his mailbox, the mail server
containing his mailbox authenticates Bob (with usernames and passwords). Alice's
mail server must also deal with failures in Bob's mail server. If Alice's server cannot deliver mail to Bob's server, Alice's server holds the message in a message
queue and attempts to transfer the message later. Reattempts are often done every
30 minutes or so; if there is no success after several days, the server removes the
message and notifies the sender (Alice) with an e-mail message.
SMTP is the principal application-layer protocol for Internet electronic mail. It
uses the reliable data transfer service of TCP to transfer mail from the sender's mail
server to the recipient's mail server. As with most application-layer protocols,
SMTP has two sides: a client side, which executes on the sender's mail server, and a
server side, which executes on the recipient's mail server. Both the client and server
sides of SMTP run on every mail server. When a mail server sends mail to other
mail servers, it acts as an SMTP client. When a mail server receives mail from other
mail servers, it acts as an SMTP server.
2.4.1 SMTP
SMTP, defined in RFC 5321, is at the heart of Internet electronic mail. As mentioned above, SMTP transfers messages from senders' mail servers to the recipients' mail servers. SMTP is much older than HTTP. (The original SMTP RFC
dates back to 1982, and SMTP was around long before that.) Although SMTP has
numerous wonderful qualities, as evidenced by its ubiquity in the Internet, it is
nevertheless a legacy technology that possesses certain archaic characteristics.
For example, it restricts the body (not just the headers) of all mail messages to
simple 7-bit ASCII. This restriction made sense in the early 1980s when transmission capacity was scarce and no one was e-mailing large attachments or large
image, audio, or video files. But today, in the multimedia era, the 7-bit ASCII
restriction is a bit of a pain—it requires binary multimedia data to be encoded to
ASCII before being sent over SMTP; and it requires the corresponding ASCII
message to be decoded back to binary after SMTP transport. Recall from Section
2.2 that HTTP does not require multimedia data to be ASCII encoded before
transfer.
To illustrate the basic operation of SMTP, let's walk through a common scenario. Suppose Alice wants to send Bob a simple ASCII message.
1. Alice invokes her user agent for e-mail, provides Bob's e-mail address (for
example, b..b@someschool.edu), composes a message, and instructs the
user agent to send the message.
2. Alice's user agent sends the message to her mail server, The total response time—that is, the time from the browser's request of an object
until its receipt of the object—is the sum of the LAN delay, the access delay (that is,
the delay between the two routers), and the Internet delay. Let's now do a very crude
calculation to estimate this delay. The traffic intensity on the LAN (see Section 1.4.2) is
(15 requests/sec)  (1 Mbits/request)/(100 Mbps) = 0.15
whereas the traffic intensity on the access link (from the Internet router to institution
router) is
(15 requests/sec)  (1 Mbits/request)/(15 Mbps) = 1
A traffic intensity of 0.15 on a LAN typically results in, at most, tens of milliseconds of delay; hence, we can neglect the LAN delay. However, as discussed in
Section 1.4.2, as the traffic intensity approaches 1 (as is the case of the access link
in Figure 2.12), the delay on a link becomes very large and grows without bound.
Thus, the average response time to satisfy requests is going to be on the order of
minutes, if not more, which is unacceptable for the institution's users. Clearly something must be done.
One possible solution is to increase the access rate from 15 Mbps to, say, 100
Mbps. This will lower the traffic intensity on the access link to 0.15, which translates to negligible delays between the two routers. In this case, the total response
time will roughly be two seconds, that is, the Internet delay. But this solution also
means that the institution must upgrade its access link from 15 Mbps to 100 Mbps, a
costly proposition.
Now consider the alternative solution of not upgrading the access link but
instead installing a Web cache in the institutional network. This solution is illustrated in Figure 2.13. Hit rates—the fraction of requests that are satisfied by a
cache—typically range from 0.2 to 0.7 in practice. For illustrative purposes, let's
suppose that the cache provides a hit rate of 0.4 for this institution. Because the
clients and the cache are connected to the same high-speed LAN, 40 percent of
the requests will be satisfied almost immediately, say, within 10 milliseconds, by the
cache. Nevertheless, the remaining 60 percent of the requests still need to be satisfied by the origin servers. But with only 60 percent of the requested objects passing
through the access link, the traffic intensity on the access link is reduced from 1.0 to
0.6. Typically, a traffic intensity less than 0.8 corresponds to a small delay, say, tens
of milliseconds, on a 15 Mbps link. This delay is negligible compared with the twosecond Internet delay. Given these considerations, average delay therefore is
0.4  (0.01 seconds) + 0.6  (2.01 seconds)
which is just slightly greater than 1.2 seconds. Thus, this second solution provides an
even lower response time than the first solution, and it doesn't require the institution
to upgrade its link to the Internet. 

2) Four different designs for a digital computer circuit are being studied to compare the amount of noise present. The following data have been obtained: Circuit Design 1 2 3 4 Noise Observation 29 75 63 54 28 36 89 27 58 43 66 84 33 89 45 67 76 43 45 A A=Last two digits of your student number. (Last two numbers from right) We want to know that whether "Circuit Designs" effect on the "Noise Observation" or not.