John G. Fletcher

An architecture for support of network operating system services

Abstract This paper argues that network architectures should be designed with the explicit purpose of creating a coherent network operating system (NOS). The resulting NOS must be capable of efficient implementation as the base (native) operating system on a given machine or machines, or of being layered on top of existing operating systems as a guest system. The goals and elements of a network architecture to support a NOS are outlined. This architecture consists of a NOS model and three layers of protocol: an interprocess communication (IPC) layer, with an end-end protocol and lower sub-layer protocols as needed to support reliable uninterpreted message communication; a service support layer (SSL), abstracting logical structures and needs common to most services, including naming, protection, request/reply structure, and data-type translation, error control; and a layer of standard services, (file, directory, terminal, process, clock, etc.).

Mechanisms for a reliable timer-based protocol☆

Abstract Timer-based protocol mechanisms are developed for reliable and efficient transmission of both single-message and message-stream traffic. That is, correct data delivery is assured in the face of lost, damaged, duplicate, and out-of-sequence packets. The protocol mechanisms seem particularly useful in a high-speed local network environment. Current reliable protocol design approaches are not well suited for single-message modes of communication appropriate, for example, to distributed network operating systems. The timer intervals that must be maintained for sender and receiver are developed along with the rules for timer operation, packet acceptance, and connection opening and closing. The underlying assumptions about network characteristics required for the timer-based approach to work correctly are discussed, particularly that maximum packet lifetime can be bounded. The timer-based mechanisms are compared with mechanisms designed to deal with the same problems using the exchange of multiple messages to open and close logical connections or virtual circuits.

A more general algorithm for computing closed semiring costs between vertices of a directed graph

This note describes a generalization of an algorithm given by Aho, Hopcroft, and Ullman [1], originally derived from the work of Kleene [2] and McNaughton and Yamada [3]. The algorithm is used to compute the total cost of all paths between each pair of vertices in a directed graph when the cost of each edge is known. The cost of a path is defined as the product of the costs of the edges forming it, and the total cost of a set of paths is the sum of their individual costs. If there are <italic>n</italic> vertices labeled 1 through <italic>n</italic> and <italic>E</italic>[<italic>i, j</italic>] is the cost of the edge from vertex <italic>i</italic> to vertex <italic>j</italic> (or is zero when there is no such edge), then the total cost <italic>T</italic>[<italic>i, j</italic>] of all paths from <italic>i</italic> to <italic>j</italic> is the solution of the equation <italic>T</italic>[<italic>i, j</italic>] = δ[<italic>i, j</italic>] + ∑<supscrpt><italic>n</italic></supscrpt><subscrpt><italic>k</italic>-1</subscrpt> <italic>E</italic>[<italic>i, k</italic>]·<italic>T</italic>[<italic>k, j</italic>], (1) where δ[<italic>i, i</italic>] = 1 (the cost of the path of no edges from <italic>i</italic> to <italic>i</italic>) and δ[<italic>i, j</italic>] = 0 if <italic>i</italic> ≠ <italic>j</italic>. To assure that <italic>T</italic> [<italic>i, j</italic>] is always well-defined, costs are required to be elements from an algebraic structure called a closed semiring.

A program to solve the Pentomino problem by the recursive use of macros

Just as a domino is a platte figure formed of two contiguous equal squares, a pentomino is a plane figure formed of five contiguous equal squares. A fixed size for the elemental squares being assumed, there are 112 different pentominos, different meaning noneongruent. These are each identified by a number front 1 to 12 (see Figure 1). Ihe pentonfino problem is the problem of fitting the 12 pentomittos without overlapping into a plane area (the box) formed of 60 elelnetttal squares. The box may be rectangular (3 X 20, 4 X 16, 5 X 12 or 6 X 10) but is not necessarily so. In the program, the box is viewed as a portion of a large arena, 16 X 32 squares; these squares arc numbered from i: 1 to 512, 1 to 16 proceeding from left to right across the ~ first row, 17 to 32 across the second, etc. Each square

Principles of design in the octopus computer network

The concepts and methods are reviewed which have proven to be of the most value in designing and implementing the Octopus computer network, which is one of the largest concentrations of computing capability in the world. The discussion summarizes design principles relating to the scope of system software, privacy and security, processor organization, file structure, network connections, hardware selection, programming techniques, standards, and use of resources. Differences with what appear to be widespread belief and practice are cited, including such matters as the size of the programmer staff, the significance of the privacy issue, the importance of the choice of languages and language constructions, the primary causes of system failure, and efficiency.

Serial link protocol design: A critique of the X.25 standard, level 2

There are certain technical design principles for link communication protocols which, if followed, result in a protocol that is less complex in both concept and implementation, but at the same time provides better service, than if the principles are not followed. These principles include modularization into sub-protocols, symmetry between the nodes on the link, and use of the state-exchange model of a conversation rather than the command-response model. The principles are described, the extent to which they are followed by the standard protocol X.25, level 2, is examined, and a protocol adhering to them is presented.

Planning a computer network: The octopus experience☆

Abstract The author of this article is engaged in software design and implementation for the decade-old Octopus computer network. This network remains in a continual state of growth and change in a constant effort to take advantage of the most advanced hardware and software available from an ever-developing technology. Those planning a computer network or other complex computer system should benefit by considering the Octopus experience with regard to the needs of computer users, methods of design, network and operating system structure, security and privacy, the management of limited resources, and the advantages of locally generated hardware and software.