A closer reading of RFC 2046 indicates that, in a multipart/mixed message, the boundary delimiter following a part that is supposed to end with a line break should include an extra line break (carriage-return/line-feed pair) just before the boundary marker. Moreover, there should be a boundary delimiter at the end of the last part, similar to the others except with two extra hyphens at the end. Here's the transcript of a successful interaction that observes these rules:
220 franklin.math.grin.edu ESMTP Sendmail 8.11.2/8.11.2; Fri, 8 Feb 2002 16:41:37 -0600 HELO curry.cs.grinnell.edu 250 franklin.math.grin.edu Hello curry.math.grinnell.edu [132.161.33.144], pleased to meet you MAIL FROM: stone@cs.grinnell.edu 250 2.1.0 stone@cs.grinnell.edu... Sender ok RCPT TO: stone@cs.grinnell.edu 250 2.1.5 stone@cs.grinnell.edu... Recipient ok DATA 354 Enter mail, end with "." on a line by itself From: stone@cs.grinnell.edu To: stone@cs.grinnell.edu Subject: foo MIME-Version: 1.0 Content-Type: multipart/mixed; Boundary="(break here)" --(break here) Some text. --(break here) Content-Type: text/html <html><head><title>Foo!</title></head><body><p>Bar!</p></body></html> --(break here) Some more text. --(break here)-- . 250 2.0.0 g18Mfn114283 Message accepted for delivery QUIT 221 2.0.0 franklin.math.grin.edu closing connection
The link farm at traceroute.org contains links to Web tools all over the world that will trace packets for you, as we saw in class.
TCP segments are not fixed in size. One common size is 1500 bytes (a twenty-byte header followed by 1480 bytes of data), because the Ethernet protocol sets this as an upper bound for packets, but this is far from universal. A short Web page might well fit into one TCP segment. Bear in mind, however, that a lower-level protocol such as IP may divide a single TCP segment into several datagrams that are transmitted separately. The theoretical upper bound on the size of an IP datagram is 65535 bytes; in practice, however, many routers will not process IP datagrams larger than 576 bytes (including a twenty-byte IP header). So a Web document must be very short to fit into one IP datagram.
IPv6 (``Internet Protocol, version 6'') addresses contain 128 bits, and are conventionally written as eight colon-separated groups of four hexadecimal digits each. Here's a randomly generated one:
706b:05c0:5e6f:e19c:ab01:120e:443d:96e1
The physical-level protocol whose name I was groping for in class is actually called ``Manchester encoding.'' Kurose and Ross discuss it on page 420.
When an application program running on one computer sends a message over a network to an application running on a different computer, the message goes through several processing steps on the sending computer, descending through the protocol layers, possibly with some transformation at each layer, and picking up a new header at each step. The message transmitted at the physical level includes all of these headers. On the receiving machine, the message again goes through several processing steps, with each protocol layer stripping off the corresponding header and possibly transforming the accompanying body. The application programs at the endpoints never see messages containing any headers except their own; the lower-level protocols could in principle peek at the headers supplied by and intended for higher-level protocols, but in practice generally treat them as part of the message body.
Here's a link to RFC 1149, ``A standard for the transmission of IP datagrams on avian carriers.''
This document is available on the World Wide Web as
http://www.cs.grinnell.edu/~stone/courses/networks/afterthoughts.xhtml
created January 22, 2002
last revised February 8, 2002