Berknet

Last updated

The Berkeley Network, or Berknet, was an early wide area network, developed at the University of California, Berkeley in 1978, primarily by Eric Schmidt as part of his master's thesis work. [1] The network continuously connected about a dozen computers running BSD [2] and provided email, file transfer, printing and remote command execution services to its users, and it connected to the two other major networks in use at the time, the ARPANET and UUCPNET. [3]

Contents

The network operated using what were then high-speed serial links, 1200 bit/s in the initial system. Its software implementation shipped with the Berkeley Software Distribution from version 2.0 onwards. [1] It consisted of a line discipline within the Unix kernel, [4] a set of daemons that managed queues of commands to be sent across machines, and a set of user-level programs that enqueued the actual commands. The Berkeley Network introduced the .netrc file.

The release of UUCP as part of Version 7 Unix in 1979 led to little external interest in the system; Mary Ann Horton noted in 1984 that "Berknets are gone now". [5] Support for Berknet's custom email addressing scheme was provided in the Sendmail program until 1993. [4]

History

The development of what became Berknet began with an initial concept developed by Bob Fabry, Eric Schmidt's advisor. Schmidt developed the system until leaving for a break in May. The system was initially designed to connect only two machines, known as A and Q, both PDP-11 machines running Unix. [6] Development ran until the end of term in May. By 1 May the initial system, connecting two machines, A and Q, was operational. As development took place mostly on the A machine, the system was also used to distribute the code to Q. The menial task of moving the code to Q led to early efforts to automate the system. [6]

As the code began to become functional it also began to see use by other users, and this led to A being connected to a new machine, C. This presented the new problem that the original implementation required the same user login on both machines, and trying to keep this in sync between several machines led to A's password file growing too large. Dealing with this problem was initially handled by having dedicated "free" accounts on both machines that was used by Berknet, along with using the .netrc file to automatically log into them when needed. [6]

A third machine, Cory, was then added. [6] To deal with the account issue, and handle physical routing, A became a hub responsible for storing and forwarding any messages between C and Cory. A table-based routing map was introduced to control this. It was in this state when Schmidt completed the first version in May. While he was away, the Computing Center made several changes to the system, and this led to several incompatible versions of Berknet emerging, and periodic breakage of the system, including the sendmail system not working. [7]

By the time Schmidt returned to the system in October, a VAX 11/780 machine had been added, bringing the total to three different versions of Unix being supported. make was then used to build and distribute the code to the machines, including using the older version of the code to bootstrap the Cory machine, which ran Unix Version 6 while the others ran 7. Further changes led to a stable version and documentation began, and several additional sites were added. Performance became a problem, especially for the machines tasked with forwarding, and required hand maintenance to keep the system working. [8]

Description

The system had some resemblance to UUCP in that it used a batch mode file transfer system based on a Unix daemon that performed the actual transfers, as well as defining a suitable simple network protocol to move the data over the telephone-based links. The protocol is built into the net application, which watches for new files to appear a series of defined locations representing queues. [8] When a file appears, net starts a terminal connection to the selected remote machine, issues commands and performs file transfers, and then disconnects and deletes the local file if it was a success. [9]

From a user's perspective, there are a number of separate applications that make up the system, ones for reading and writing mail, one for moving files between machines, etc. These all work by placing files in the proper queues which then automatically move the data to the target machine where it is reassembled and moved back into user directories for use. [8] The most-used application was netcp, which copied files over the network. This was supplied with two filenames, the first the path to the existing file, and the second the path to the desired final location. Paths were a combination of a machine name followed by a colon, and then a normal Unix slash-separated path. For instance:

  netcp testfile.txt Cory:/usr/pascal/sh

would copy the file testfile.txt to the path /usr/pascal/sh on the Cory machine. [9]

Likewise, the existing mail application was modified to understand the same addressing scheme, and supported by the mmail utility which automatically added headers to indicate where the message originated. On the receive side, the new application netmail uses net to log into a named remote machine and read any mail found there. When this completes, prmail then copies the messages into the user's local mail where it can be read and replied to as normal. Automation of these separate tasks was quickly introduced. [10]

Protocol

The underlying transfer protocol was arranged in three layers. The uppermost was the command protocol, which defined the overall file structure, below this was the stream protocol, which broke the file into multiple packets, and at the bottom was the hardware layer using the serial ports. [11]

The command layer consisted primarily of a file format that started with a length indicator, followed by a header, a command to run on the remote machine, and then any required data. The net command assembled the files, prepends the length indicator, and then places the resulting file in the proper queue. The header contains the origin and destination machine names, the login names to use on both, a version number, time stamps, and then the "pseudo-command". The header data is written as normal ASCII text with the fields separated by colons. [11]

During a transfer, the file is broken into packets for error correction purposes. The packets have a header consisting of a length byte that allows up to 255 bytes in a packet, followed by a two-byte packet number, a one-byte type indicator, a one-byte checksum, and then the data. [11] The checksum is placed at the front because the packets are variable length, and this simplified the code. There are several packet types, which contain command information or data. Among these is the "reset" packet, which indicates the start of a new transfer from a remote machine. The protocol was very similar to XMODEM in complexity, lacking sliding windows or streaming acknowledgement, features that were considered important to add to future versions. [12]

At the hardware level, the system was simply a serial port connecting two machines. However, the existing Unix systems could not directly process 8-bit ASCII data without considerable overhead, so the data being sent is encoded with three 8-bit bytes packaged into four 6-bit characters in the printable range. This introduces an overhead of 33%, which was also considered an important area for possible improvement. [12]

Related Research Articles

<span class="mw-page-title-main">Asynchronous Transfer Mode</span> Digital telecommunications protocol for voice, video, and data

Asynchronous Transfer Mode (ATM) is a telecommunications standard defined by the American National Standards Institute and ITU-T for digital transmission of multiple types of traffic. ATM was developed to meet the needs of the Broadband Integrated Services Digital Network as defined in the late 1980s, and designed to integrate telecommunication networks. It can handle both traditional high-throughput data traffic and real-time, low-latency content such as telephony (voice) and video. ATM provides functionality that uses features of circuit switching and packet switching networks by using asynchronous time-division multiplexing. ATM was seen in the 1990s as a competitor to Ethernet and networks carrying IP traffic as it was faster and was designed with quality-of-service in mind, but it fell out of favor once Ethernet reached speeds of 1 gigabits per second.

The Internet Control Message Protocol (ICMP) is a supporting protocol in the Internet protocol suite. It is used by network devices, including routers, to send error messages and operational information indicating success or failure when communicating with another IP address. For example, an error is indicated when a requested service is not available or that a host or router could not be reached. ICMP differs from transport protocols such as TCP and UDP in that it is not typically used to exchange data between systems, nor is it regularly employed by end-user network applications.

The Simple Mail Transfer Protocol (SMTP) is an Internet standard communication protocol for electronic mail transmission. Mail servers and other message transfer agents use SMTP to send and receive mail messages. User-level email clients typically use SMTP only for sending messages to a mail server for relaying, and typically submit outgoing email to the mail server on port 587 or 465 per RFC 8314. For retrieving messages, IMAP is standard, but proprietary servers also often implement proprietary protocols, e.g., Exchange ActiveSync.

The Secure Shell Protocol (SSH) is a cryptographic network protocol for operating network services securely over an unsecured network. Its most notable applications are remote login and command-line execution.

The Transmission Control Protocol (TCP) is one of the main protocols of the Internet protocol suite. It originated in the initial network implementation in which it complemented the Internet Protocol (IP). Therefore, the entire suite is commonly referred to as TCP/IP. TCP provides reliable, ordered, and error-checked delivery of a stream of octets (bytes) between applications running on hosts communicating via an IP network. Major internet applications such as the World Wide Web, email, remote administration, and file transfer rely on TCP, which is part of the Transport layer of the TCP/IP suite. SSL/TLS often runs on top of TCP.

Network throughput refers to the rate of message delivery over a communication channel, such as Ethernet or packet radio, in a communication network. The data that these messages contain may be delivered over physical or logical links, or through network nodes. Throughput is usually measured in bits per second, and sometimes in data packets per second or data packets per time slot.

In computer networking, the User Datagram Protocol (UDP) is one of the core communication protocols of the Internet protocol suite used to send messages to other hosts on an Internet Protocol (IP) network. Within an IP network, UDP does not require prior communication to set up communication channels or data paths.

Trivial File Transfer Protocol (TFTP) is a simple lockstep File Transfer Protocol which allows a client to get a file from or put a file onto a remote host. One of its primary uses is in the early stages of nodes booting from a local area network. TFTP has been used for this application because it is very simple to implement.

The File Transfer Protocol (FTP) is a standard communication protocol used for the transfer of computer files from a server to a client on a computer network. FTP is built on a client–server model architecture using separate control and data connections between the client and the server. FTP users may authenticate themselves with a plain-text sign-in protocol, normally in the form of a username and password, but can connect anonymously if the server is configured to allow it. For secure transmission that protects the username and password, and encrypts the content, FTP is often secured with SSL/TLS (FTPS) or replaced with SSH File Transfer Protocol (SFTP).

Berkeley sockets is an application programming interface (API) for Internet sockets and Unix domain sockets, used for inter-process communication (IPC). It is commonly implemented as a library of linkable modules. It originated with the 4.2BSD Unix operating system, which was released in 1983.

UUCP is a suite of computer programs and protocols allowing remote execution of commands and transfer of files, email and netnews between computers.

Unix security refers to the means of securing a Unix or Unix-like operating system. A secure environment is achieved not only by the design concepts of these operating systems, but also through vigilant user and administrative practices.

In computer programming, a magic number is any of the following:

ZMODEM is an inline file transfer protocol developed by Chuck Forsberg in 1986, in a project funded by Telenet in order to improve file transfers on their X.25 network. In addition to dramatically improved performance compared to older protocols, ZMODEM offered restartable transfers, auto-start by the sender, an expanded 32-bit CRC, and control character quoting supporting 8-bit clean transfers, allowing it to be used on networks that would not pass control characters.

XMODEM is a simple file transfer protocol developed as a quick hack by Ward Christensen for use in his 1977 MODEM.ASM terminal program. It allowed users to transmit files between their computers when both sides used MODEM. Keith Petersen made a minor update to always turn on "quiet mode", and called the result XMODEM.

YMODEM is a file transfer protocol used between microcomputers connected together using modems. It was primarily used to transfer files to and from bulletin board systems. YMODEM was developed by Chuck Forsberg as an expansion of XMODEM and was first implemented in his CP/M YAM program. Initially also known as YAM, it was formally given the name "YMODEM" in 1985 by Ward Christensen, author of the original XMODEM.

A ping of death is a type of attack on a computer system that involves sending a malformed or otherwise malicious ping to a computer. In this attack, a host sends hundreds of ping requests with a packet size that is large or illegal to another host to try to take it offline or to keep it preoccupied responding with ICMP Echo replies.

Real-Time Messaging Protocol (RTMP) is a communication protocol for streaming audio, video, and data over the Internet. Originally developed as a proprietary protocol by Macromedia for streaming between Flash Player and the Flash Communication Server, Adobe has released an incomplete version of the specification of the protocol for public use.

A network socket is a software structure within a network node of a computer network that serves as an endpoint for sending and receiving data across the network. The structure and properties of a socket are defined by an application programming interface (API) for the networking architecture. Sockets are created only during the lifetime of a process of an application running in the node.

The Stream Control Transmission Protocol (SCTP) is a computer networking communications protocol in the transport layer of the Internet protocol suite. Originally intended for Signaling System 7 (SS7) message transport in telecommunication, the protocol provides the message-oriented feature of the User Datagram Protocol (UDP), while ensuring reliable, in-sequence transport of messages with congestion control like the Transmission Control Protocol (TCP). Unlike UDP and TCP, the protocol supports multihoming and redundant paths to increase resilience and reliability.

References

Citations

  1. 1 2 Shacklette, Mark (2004). "Unix Operating System". The Internet Encyclopedia. Wiley. p. 497. ISBN   9780471222019 . Retrieved April 28, 2020.
  2. ↑ Lerner, Josh; Tirole, Jean (2000). "Some simple economics of open source" (PDF). NBER Working Paper Series. NATIONAL BUREAU OF ECONOMIC RESEARCH. Retrieved April 30, 2020.
  3. ↑ Hauben, Michael; Hauben, Ronda (1997). Netizens: On the History and Impact of Usenet and the Internet. Wiley. p. 170. ISBN   978-0-8186-7706-9.
  4. 1 2 Vixie, Paul A.; Avolio, Frederick M. (2002). Sendmail: Theory and Practice. Elsevier. p. 3. ISBN   9781555582296.
  5. ↑ Horton, Mark R. (1986). What is a Domain?. Software Tools Users Group [Sof84]. pp. 368–372. Retrieved April 28, 2020.
  6. 1 2 3 4 Schmidt 1979, p. 2.
  7. ↑ Schmidt 1979, p. 3.
  8. 1 2 3 Schmidt 1979, p. 5.
  9. 1 2 Schmidt 1979, p. 6.
  10. ↑ Schmidt 1979, p. 7.
  11. 1 2 3 Schmidt 1979, p. 8.
  12. 1 2 Schmidt 1979, p. 9.

Bibliography

This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.