Information Technology Reference
In-Depth Information
a
protokollon
was the first page of a manuscript that contained a brief
summary of the contents, the date, and who authenticated the doc-
ument. In networking, the meaning of
protocol
resembled the role of
the packet header, which specified the destination and information
needed to reconstruct the message. A more informal definition was
suggested by Cerf: “The other definition of protocol is that it's a hand-
written agreement between parties, typically worked out on the back
of a lunch bag, which describes pretty accurately how most of the pro-
tocol designs were done.”
24
Although the team did not complete a draft of the host-to-host pro-
tocol until the summer of 1970, the group had early on adopted a “lay-
ered” approach and had also written a couple of key applications. The
lowest layer of the protocol specified how to move packets from host to
host as a stream of unidentified bits, regardless of what sort of data the
bits might represent. The two key applications were one for transferring
files and another for
remote login
, software to enable a user at one com-
puter to
log in
- that is, to identify himself or herself at a remote host
computer and begin using the site. The final version of the protocol for
exchanging files over the network, the File Transfer Protocol, or FTP as it is
now usually abbreviated, was not completed until July 1972 when Jon Postel
issued the Networking Group's RFC #354. The remote log-in application was
called Telnet and was also very widely used. This application, together with the
extension of the IMP interface to allow terminals as well as host computers to
send data into the network - an interface called the Terminal IMP controller or
TIP - later set the scene for the rapid expansion of the network.
The first IMP node was delivered to Len Kleinrock's team at UCLA on sched-
ule in September 1969. The software written by Steve Crocker's team and the
hardware interface designed and built by another UCLA graduate student, Mike
Wingfield, worked perfectly for the host-to-IMP connection. But it was not until
the second IMP was delivered to Engelbart's team at SRI in October that BBN
was able to test intercomputer communication between two different host
computers, the Sigma-7 at UCLA and the Scientific Data Systems 940 at SRI
(
Fig. 10.14
). The system worked perfectly and the network was soon extended
to the sites at Santa Barbara and Utah (see
Fig. 10.12
in the preceding text).
From the diagram, it is clear that the only link to Utah was through SRI, mean-
ing that this first prototype distributed network was not yet what Baran had
called “a robust web of redundant interconnections.” By 1973, the ARPANET
had expanded to become a much more redundant network (
Fig. 10.15
).
One of the concerns that Bob Kahn had about BBN's design of the IMP net-
work software was about the flow control of the packets across the network.
He said, “I could see things that to me were obvious flaws. The most obvious
one was that the network could deadlock.”
25
Deadlock is a situation in which
the system gets into a state where no action is possible. The scenario that most
worried Kahn was one caused by congestion at a destination IMP. If the storage
buffers
, the areas of computer memory used to temporarily store the informa-
tion while it was being moved from one place to another, became too full at the
receiving node, the packets containing the instructions to reassemble the mes-
sages would not be received. The destination IMP would be full up with pack-
ets unable to be assembled into complete messages. The pragmatic engineer
Fig. 10.14. The first message sent over the
ARPANET on 29 October 1969. This was an
attempt to log into a remote computer at the
SRI from UCLA.
Search WWH ::
Custom Search