2.1 The Ether ¶

The transmission medium of Chaosnet is called the ether. Physically it is a coaxial cable, of the semi-rigid 1/2 inch low-loss type used for cable TV, with 75-ohm termination at both ends. At each network node a cable transceiver is attached to the cable. A 10-meter flat cable connects the transceiver to an interface which is attached to a computer’s I/O bus. A network node consists of this transceiver and interface and a computer which executes a certain piece of software called the Network Control Program (NCP), which manages and controls Chaosnet, in addition to whatever application software justifies its existence in the first place.

One network node at a time may seize the ether and transmit a packet, which arrives at all other nodes; each node decides in hardware whether to ignore the packet or to receive it. A single ether must be a linear cable; it may not contain branches nor stubs, and the ends may not be joined into a circle. The maximum length of an ether cable is about 1 kilometer. This is determined by dispersion and by DC attenuation. The maximum number of nodes on a single ether is probably a few dozen. This is determined by degradation of the electrical properties of the cable by the connectors used to attach the transceivers.

The maximum length of an ether could be increased by using repeaters (bidirectional digital amplifiers joining two pieces of cable). In practice this is not done. Instead, the protocol provides for multiple ethers, joined together by nodes called bridges which relay packets from one ether to another. A bridge is typically a pdp11 computer with two or more network interfaces attached to it. A bridge node usually performs other tasks as well, such as interfacing terminals. Bridges attach other network media as well as ethers; some computers connect to the network through their manufacturer’s high speed computer-to-computer interface to a nearby bridge, rather than being interfaced directly to an ether. Asynchronous lines have also been used as Chaosnet media.

The form of information on the ether, the transceiver and interface hardware, and the protocols which control who may seize the ether are described in the following sections.

2.2 Packets ¶

The basic unit of transmission is called a packet. This is a sequence of up to 4032 data bits, plus 48 bits of header information used by the hardware. Packets’ bits are normally grouped into 16-bit words. The division of a transmitted bit stream into packets provides a conveniently-sized unit for resource allocation and error control. The job of the hardware is to deliver a packet from one node to another. Software protocols define the meaning of the data bits in a packet, manage the hardware, compensate for imperfections of the hardware, and provide more useful services than simple transmission of packets from one computer to another.

The hardware header consists of three 16-bit words, called destination, source, and check. The source identifies the node which transmitted this packet onto this ether. This is not necessarily the original source of the message, since it may have originated on a different ether. The destination identifies the node which is intended to receive this packet from this ether. This is not necessarily the final destination of the message; it may be a bridge which should relay the packet to another ether, whence it will eventually reach its final destination. The check word is a cyclic redundancy checksum, generated and checked by hardware, which detects errors in transmission through the ether, entirely-spurious packets created by noise on the cable, and memory errors in the transmitting and receiving packet buffers.

The software protocol is also based on packets, taking 128 of the data bits as a software header. This is described in Packets.

2.3 The Transceiver ¶

Everyone who connects to the ether does so through a transceiver, which is a small box which mounts directly on the cable via a UHF connector and a T-joint. All nodes use identical transceivers (the interface varies depending on what computer it is designed to interface to). The transceiver contains the analog portion of the interface logic, provides ground isolation between the ether cable and the computer, and contains some protective circuitry designed to prevent a malfunctioning program or interface from continuously jamming the ether. (If it were to be redesigned, it ought to contain even more protective circuitry, since there are some possible interface failures that can get past the protection and render the ether unusable.)

The transceiver receives a differential digital signal from the computer interface and impresses it onto the cable as a level of about 8 volts for a 1, or 0 volts (open circuit) for a 0, through a very fast VMOS power FET. When the cable is idle it is held at 0 volts by the terminations. This simple-minded unipolar scheme is adequate for the medium cable lengths and transmission speeds we are using. The transceiver monitors the cable by comparing it against a reference voltage, and returns a differential signal to the interface. In addition, it detects interference (another transceiver transmitting at the same time as this one) and informs the interface.

The transceiver includes indicators (light-emitting diodes) for power OK, transmitted data, received data, and interface attempting to jam the ether. A test button simulates an input of continuous 1’s from the interface, which should light all the lights (dimly) if the transceiver is working. These indicators and the test button are useful for rapidly tracking down network problems. The transceiver requires its own power supply mounted nearby; one power supply can service three transceivers if they are all adjacent. High-voltage isolation between the cable and the computer is provided by optical isolators within the transceiver.

2.4 The Interface ¶

The interface is typically a wire-wrap board containing about 120 TTL logic chips, which plugs into the I/O bus of a computer and connects it to the ether (through a transceiver.) The interface implements the hardware protocols described in the next section, buffers incoming and outgoing packets, generates and checks checksums, and interrupts the host computer when a packet is to be read out of the receive packet buffer or stored into the transmit packet buffer. These packet buffers shield the host computer from the high speed of data transmission on the cable. Instead of having to produce bits at a high rate, the host can produce them at a lower rate, collect them into a packet, and then tell the interface to transmit the packet in a single burst of high-speed transmission.

Interfaces currently exist for Lisp machines, for DEC LSI-11 micro-computers, and for the DEC Unibus [UNIBUS], which allows Chaosnet to be attached to pdp11’s, VAX’s, and the peripheral processors of most pdp10’s. Programming documentation for this compatible family of interfaces appears later in this paper.

Interfaces for other computers are likely to exist in the future. The existing interface design does not make any unusual special demands of its host computer and should be easily adaptable to other architectures.

2.5 Hardware Protocols ¶

The purpose of these protocols is to deliver packets intact from one node to another node on the same ether, with fairly high probability of success, and to guarantee to give an error indication or lose the packet entirely if it is not delivered intact. An additional purpose is to provide high performance and not to bog down when subjected to a heavy load.

Bits are represented on the ether using a technique which is called Upright Biphase NRZI. Each bit cell, which is approximately 250 nanoseconds long, begins with a transition in state, from high to low or from low to high. This transition marks the beginning of a bit cell and provides self-clocking. 3/4 of the way through the bit cell, the state of the cable is sampled; high represents a 1 and low represents a 0. If the bit being represented is the same as the previous bit, there will be one transition at the beginning of the bit cell and a second in the middle of the bit cell. If the bit being represented is the opposite of the previous bit, there will be no transition in the middle of the bit cell since the clock transition will have set the cable to the desired state. The AC frequency of the signal on the cable varies between 1/2 the bit rate and the full bit rate. The information bit-rate is 4 million bits per second.

The self-clocking feature allows for slight variations in transmission and cable propagation speed. However, since the 3/4 of a bit cell delay is a fixed delay, only modest variations in speed can be tolerated. A crystal clock is used as the source of the transmit timing in the interface.

Since there is always at least one state-transition per bit cell, the states where the ether remains high or low for an appreciable time are available for non-data uses. If the ether remains low for more than about two bit cells, it is considered to be not-busy. This condition marks the end of a packet and allows someone else to transmit. Note that if no transceivers are active, the terminations will hold the ether low.

If the ether remains high for about two bit cells, this is an "abort signal". Abort signals are used for two purposes. If the transceiver detects a collision (two nodes trying to transmit at the same time), each transmitting interface ceases to transmit and sends an abort signal (four bit cells long), which tells all receivers to ignore the aborted packet and ensures that the other transmitter also aborts. Thus when a collision occurs, the ether is cleared as soon as possible to help prevent long tie-ups under conditions of heavy load. The other use for the abort signal is in hardware flow-control. When a receiving interface determines that an incoming packet is addressed to it, but its receive buffer already contains a packet, it sends an abort signal which causes the transmitter to stop. This serves the dual purpose of immediately informing the transmitter that its message did not get through, and preventing the ether from being tied up while a long packet is transmitted which the receiver cannot receive.

Packets are transmitted over the ether in reverse bit-order, for hardware convenience. The three header words, which to the software appear to be at the end of the packet, are transmitted first, in the order check, source, destination. The data words, in reverse order, follow. Words are transmitted least-significant bit first. Of course, the software need not be aware of this reversal; packets arrive at the destination in the same form as they were created by the source. At the end of the packet, an extra zero bit is appended to bring the ether to the low state so that an extra spurious clock-transition will not be generated when it goes idle. This bit is stripped off by the interface and is never seen by software.

The check word is used for error detection, as described above. The source word is made available to the software, which ignores it in most cases, and also serves to synchronize the clocks in the collision-avoidance mechanism which is described below. The destination word is compared by each receiver against its own address. If they match, or if the destination is zero, or if the software selects the "match any destination" mode, the packet is placed in the receive packet buffer and the host computer is interrupted. The zero destination feature is used for "broadcast" messages. Note that a receiver whose packet buffer is full will only generate an abort signal if the packet was specifically addressed to it.

2.6 Ether Contention ¶

Chaosnet has no centralized control element; when a network node has a message to transmit, its interface seizes the ether and transmits a packet. The time when it seizes the ether is determined only by state inside that particular interface and by the local state of the cable at the point where that interface’s transceiver is attached.

If two interfaces should decide to seize the ether and transmit at the same time, their transmissions will interfere and no useful information will be transmitted. This is called a collision. Collisions are the principal limitation on the bandwidth of a heavily-loaded ether-type network, and should be avoided. (However, neither PARC’s network nor MIT’s network has yet been operated with a heavy enough load to make collisions really significant.)

Chaosnet uses a novel collision avoidance technique. First of all, an interface will never initiate transmission unless the ether is seen to be not busy, i.e. it has been in the low state for some time. This ensures that collisions can only occur near the beginning of a packet. Once transmission of a packet has gotten well started, the ether is effectively "seized" (all interfaces realize that it is busy) and transmission will continue successfully through to the end of the packet. The amount of ether transmission time wasted by a collided packet is therefore limited to the round-trip cable propagation delay. This technique is called carrier sense.

Secondly, the hardware uses a time-division technique to attempt to prevent two interfaces from initiating transmission at the same time. This technique should prevent essentially all collisions while imposing only a modest delay in the initiation of transmission. It is designed so that it works better as the load on the ether increases; the wasted time between packets and the relative rate of collisions both decrease.

The basic idea is that each interface is assigned a time-slot, or turn, according to its address. It may only initiate transmission during its turn. The turns are spaced far enough apart that if one interface initiates transmission, every other interface will perceive that the ether is busy by the time its own turn arrives, and will not initiate an interfering transmission. Each interface contains a time-slot counter which counts while the ether is not busy, keeping track of whose turn it is. Each packet synchronizes the counters in all of the interfaces by setting them from the source address of that packet; at the time the packet was transmitted, it must have been the turn of the interface that transmitted it.

Another way to think of this is to make an analogy with ring networks. One can imagine a virtual token which passes down the cable until it gets to the end, then jumps to the beginning of the cable and repeats. An interface may only initiate transmission at the instant the token passes by it. When an interface transmits, the token stops moving and remains at that interface until the end of the packet, whereupon it continues down the cable, passing every other interface, giving them each a chance to transmit before letting the first interface transmit a second packet.

The token is not represented by any physical transmission on the cable. That would constitute a form of centralized control, and would lead to reliability problems if the token was lost or duplicated. Instead, every interface contains a time-slot counter which keeps track of where the token is thought to be. Every time a packet is transmitted these counters are brought up-to-date. The token cannot be lost because a counter by its nature eventually returns to all previous states. It does not matter if the token is duplicated (i.e. the counters lose synchronization) occasionally, since this will only cause collisions, which we know how to detect and deal with, and since the first successful transmission will resynchronize all counters. The basic mechanism of the ether network with contention and collisions is known to work, and the collision-avoidance scheme is an added-on optimization which improves performance without changing the basic mechanism.

There is a finite propagation delay time between interfaces, and this time is not small compared with the bit-rate of Chaosnet, nor when compared with the desirable length of a time slot. This time consists of the delay in the cable, about 5 nanoseconds per meter, and the delay through the two transceivers, about 220 nanoseconds. This propagation delay means that the time-slot counters in two different interfaces cannot be exactly synchronized, and that when interface A initiates transmission interface B will not instantaneously see that the ether is busy. Special relativity tells us that in fact the concept "exactly synchronized" is meaningless. Since the two time-slot counters are not in the same place, the only way we can compare them is to send a message from one to the other, through the ether, containing the reading of the counter. But this message takes non-zero time to get there, so the counter-reading it contains is wrong by the time it is compared against the other counter! We in fact do send messages containing counter readings; the source address in a packet equals the reading of the time-slot counter in the interface that sent it–at the time it was sent. Since the network nodes are not in relative motion, we can measure the distance between them and use that information to improve their synchronization.

What we are trying to do is to prevent collisions. This means that if interface A starts transmitting a packet in its turn, then by the time interface B thinks that its own turn has arrived, it must perceive the ether as busy. We will assign addresses (and hence time slots) and set the length of a time slot in such a way that this will happen. Suppose the maximum delay through the ether between A and B is t. This would be the delay for one of them sending a packet to the other; the delay between A’s receipt of a third party’s packet and B’s receipt of that packet is less, especially if the third party is between A and B on the cable. Then the maximum perceived difference between a clock at A and a clock at B is 2t; if a message is sent from B to A synchronizing the clocks, and then a message is sent from A to B containing A’s clock reading, at B this clock reading will be slow by 2t.

When a packet transmitted by A arrives at B, B’s clock may read as much as 2t earlier or later than A’s turn, depending on the transmission direction of the last synchronizing message. In order to guarantee that B’s turn has not yet happened, the time between any of A’s turns and any of B’s turns must always be at least 2t, twice the maximum propagation delay through the ether between A and B. This is the important idea! We cause this to be true by assigning addresses starting at one end of the cable; each node’s address is the previous node’s address plus twice the propagation delay between them, divided by the length of a turn. It is easy to see that if this is done for all adjacent pairs, the condition will automatically be true for non-adjacent pairs as well. When we get to the end of the cable, we must assign a number of empty slots equal to twice the propagation delay of the full length of cable, to provide the necessary separation between the turns of the two nodes at the ends of the cable.

The virtual token travels through the network at a substantially slower speed than a real signal such as a packet; in the fastest case, when nodes are very far apart, it travels at just half the speed of a real signal. Since a Chaosnet ether has the geometry of a line, as compared to the ring net’s circle, the virtual token is also slowed down by the need to return from the end of the cable to the beginning. This slower speed of the token is the price one pays for the increased robustness of Chaosnet as compared with a ring network. In a real system, we slow the token down even more to provide a margin of safety. The speed of the network is not significantly affected by the slow token, since the interval between packet transmissions by a single node is much longer than the round-trip time of the token. Indeed, if the network is being used primarily for file transfer, and hence the packets are large, the transmission time alone for a typical packet is several times the round-trip time of the token. A typical value for the token’s round-trip time is 64 microseconds.

In spite of all this, sometimes collisions will occur anyway. If the cable has been idle for a long time, the various clocks will have lost synchronization. If a source address is corrupted by a transmission error, any interface that sees that source address will set its clock to an incorrect value. Sometimes a packet will collide with random noise rather than another legitimate packet. In addition, the transmitter does not distinguish receiver-busy aborts from real collisions.

When a collision does occur, we recover from it (in software) by retransmitting the packet again a couple of times, hoping that we will be lucky enough not to have another collision, or that the receiver will soon clear its packet buffer. This retransmission is done by the software, not the hardware, since the hardware destroys the packet in its packet buffer in the process of transmitting it. But if collisions continue to occur, we give up and let somebody else have the ether. The packet is lost. A higher level of protocol will soon realize that it has been lost and retransmit it. We assume that there is enough randomness in the higher-level software that the two nodes which originally collided will not collide again on the retransmission by deciding to retransmit at precisely the same instant.

3.1 Connections ¶

The principal service provided by Chaosnet is a connection between two user processes. This is a full-duplex reliable packet-transmission channel. The network undertakes never to garble, lose, duplicate, or resequence the packets; in the event of a serious error it may break the connection off entirely, informing both user processes. User programs may either deal in terms of packets, or ignore packet boundaries and treat the connection as two uni-directional streams of 8-bit or 16-bit bytes.

On top of the connection facility "user" programs build other facilities, such as file access, interactive terminal connections, and data in other byte sizes, such as 36 bits. The meaning of the packets or bytes transmitted through a connection is defined by the particular higher-level protocol in use.

In addition to reliable communication, the protocol provides flow control, includes a way by which prospective communicants may get in touch with each other (called contacting or rendezvous), and provides various network maintenance and housekeeping facilities. These are discussed later.

3.2 Contact Names ¶

When first establishing a connection, it is necessary for the two communicating processes to contact each other. In addition, in the usual user/server situation, the server process does not exist beforehand and needs to be created and made to execute the appropriate program.

We chose to implement contacting in an asymmetric way. (Once the connection has been established everything is completely symmetric.) One process is designated the user, and the other is designated the server. The server has some contact name to which it listens. The user process requests its local operating system to connect it to the server, specifying the network node and contact name of the server. The local operating system sends a message (a Request for Connection) to the remote operating system, which examines the contact name and creates a connection to a listening process, creates a new server process and connects to it, or rejects the request.

Automatically discovering to which host to connect in order to obtain a particular service is a subject for higher-level protocols and for further research. It is not dealt with by Chaosnet.

Once a connection has been established, there is no more need for the contact name and it is discarded. Indeed, often the contact name is simply the name of a service (such as "TELNET") and several users should be able to have simultaneous connections to separate instances of that service, so contact names must be reusable.

In the case where two existing processes that already know about each other want to establish a connection, we arbitrarily designate one as the listener (server) and the other as the requester (user). The listener somehow generates a "unique" contact name, somehow communicates it to the requester, and listens for it. The requester requests to connect to that contact name and the connection is established. In the most common case of establishing a second connection between two processes which are already connected, the index number (see below) of the first connection can serve as a unique contact name.

Contact names are restricted to strings of upper-case letters, numbers, and ASCII punctuation. The maximum length of a contact name is limited only by the packet size, although on ITS hosts the names of automatically-started servers are limited by the file-system to six characters.

See Connection Establishment for complete details of how to establish a connection.

3.3 Addresses and Indices ¶

Each node (or host) on the network is identified by an address, which is a 16-bit number. These addresses are used in the routing of packets. There is a table (the system hosts table, SYSBIN;HOSTS2, in the case of ITS) which relates symbolic host names to numeric host addresses.

An address consists of two fields. The most-significant 8 bits identify a subnet, and the least-significant 8 bits identify a host within that subnet. Both fields must be non-zero. A subnet corresponds to a single transmission path. Some subnets are physical Chaosnet cables (ethers), while others are other media, for instance an interface between a pdp10 and a pdp11. The significance of subnets will become clear when routing is discussed (see Routing).

When a host is connected to an ether, the host’s hardware address on that ether is the same as its software address, including the subnet field.

A connection is specified by the names of its two ends. Such a name consists of a 16-bit host address and a 16-bit connection index, which is assigned by that host, as the name of the entity inside the host which owns the connection. The only requirements placed by the protocol on indices are that they be non-zero and that they be unique within a particular host; that is, a host may not assign the same index number to two different connections unless enough time has elapsed between the closing of the first connection and the opening of the second connection that confusion between the two is unlikely.

Typically the least-significant n bits of an index are used as a subscript into the operating system’s tables, and the most-significant 16-n bits are incremented each time a table slot is reused, to provide uniqueness. The number of uniquizing bits must be sufficiently large, compared to the rate at which connection-table slots are reused, that if two connections have the same index, a packet from the old connection cannot sit around in the network (e.g. in buffers inside hosts or bridges) long enough to be seen as belonging to the new connection.

It is important to note that packets are not sent between hosts (physical computers). They are sent between user processes; more exactly, between channels attached to user processes. Each channel has a 32-bit identification, which is divided into subnet, host, index, and uniquization fields. From the point of a view of a user process using the network, the Network Control Program section of his host’s operating system is part of the network, and the multiplexing and demultiplexing it performs is no different from the routing performed by other parts of the network. It makes no difference whether two communicating processes run in the same host or in different hosts.

Certain control packets, however, are sent between hosts rather than users. This is visible to users when opening a connection; a contact name is only valid with respect to a particular host. This is a compromise in the design of Chaosnet, which was made so that an operational system could be built without first solving the research and engineering problems associated with making a diverse set of hosts into a uniform, one-level name space.

3.4 Packet Numbers ¶

There are two kinds of packets, controlled and uncontrolled. Controlled packets are subject to error-control and flow-control protocols, described below (see Flow and Error Control), which guarantee that each controlled packet is delivered to its destination exactly once, that the controlled packets belonging to a single connection are delivered in the same order they were sent, and that a slow receiver is not overwhelmed with packets from a fast sender. Uncontrolled packets are simply transmitted; they will usually but not always arrive at their destination exactly once. The protocol for using them must take this into account.

Each controlled packet is identified by an unsigned 16-bit packet number. Successive packets are identified by sequential numbers, with wrap-around from all 1’s to all 0’s. When a connection is first opened, each end numbers its first controlled packet (RFC or OPN) however it likes, and that sets the numbering for all following packets.

Packet numbers should be compared modulo 65536 (2 to the 16th), to ensure correct handling of wrap-around cases. On a pdp11, use the instructions

Do not use the BLT or BLO instruction. On a pdp10, use the instructions

SUB A,B
TRNE A,100000
 JRST A_is_less

Do not use the CAMGE instruction. On a Lisp machine, use the code

(IF (BIT-TEST #o100000 (- A B))
    <A is less>)

Do not use the LESSP (or <) function.

3.5 Packets ¶

Operation

The most-significant 8 bits of this word are the Opcode of the packet, a number which tells what the packet means. The 128 opcodes with high-order bit 0 are for the use of the network itself. The 128 opcodes with high-order bit 1 are for use by users. The various opcodes are described in Software Protocol–Details.

The least-significant 8 bits of this word are reserved for future use, and must be zero.

Count

The most-significant 4 bits of this word are the forwarding count, which tells how many times this packet has been forwarded by bridges. Its use is explained in the Routing section.

The least-significant 12 bits of this word are the data byte count, which tells the number of 8-bit bytes of data in the packet. The minimum value is 0 and the maximum value is 488. Note that the count is in 8-bit bytes even if the data are regarded as 16-bit bytes.

The byte count must be consistent with the actual length of the hardware packet. Since the hardware cyclic redundancy check algorithm is not sensitive to extra zero bits, packets whose hardware length disagrees with their software length are discarded as hardware errors.

Destination Address

This word contains the network address of the destination host to which this packet should be sent.

Destination Index

This word contains the connection index at the destination host of the connection to which this packet belongs, or 0 if this packet does not belong to any connection.

Source Address

This word contains the network address of the source host which originated this packet.

Source Index

This word contains the connection index at the source host of the connection to which this packet belongs, or 0 if this packet does not belong to any connection.

Packet Number

If this is a controlled packet, this word contains its identifying number.

Acknowledgement

The use of this word is described in Flow and Error Control.

3.6 Data Formats ¶

Data transmitted through Chaosnet generally follow Lisp Machine standards. Bits and bytes are numbered from right to left, or least-significant to most-significant. The first 8-bit byte in a 16-bit word is the one in the arithmetically least-significant position. The first 16-bit word in a 32-bit double-word is the one in the arithmetically least-significant position.

The character set used is dictated by the higher-level protocol in use. Telnet and Supdup, for example, each specifies its own ASCII-based character set. The "default" character set–used for new protocols and for text that appears in the basic Chaosnet protocol, such as contact names–is the Lisp Machine character set [CHINUAL]. This is basically ASCII, augmented with additional printing characters and a different set of format-effector (or "control") characters.

Because the rules for bit numbering conflict with the native byte-ordering in pdp10s, and because it is quite expensive to rearrange the bytes using the pdp10 instruction set, pdp11s which act as front-ends for pdp10s must reformat packets passing through them, and pdp10s interfaced directly to the network must have interfaces capable of rearranging the bytes. This requires that the network protocols explicitly specify which portions of each type of packet are 8-bit bytes and which are 16-bit bytes. In general the header is 16-bit bytes and the data field is 8-bit bytes, but certain packet types (OPN, STS, RUT, and opcodes 300 through 377) have 16-bit bytes in the data field. Use of 32-bit data is rare, so no provision is made for putting 32-bit data into the standard format for pdp10s. On our current network pdp10s are the only hosts which require this packet reformatting assistance, because most modern computers number their bits and bytes from least-significant to most-significant.

The effect of this is that user programs that use the Chaosnet always see the data in a packet and its header in the native form of the machine they are running on, and the necessary conversions are automatically applied by the network. This statement applies to the order of bits and bytes within a word, but not to the character set (when packets contain textual data) which is dictated by protocols.

Unlike some other network protocols, Chaosnet does not use any software checksumming. Because of the diversity of hosts with different architectures attached to the Chaosnet, it is impossible to devise a checksumming algorithm which can be executed compatibly and efficiently on all hosts. Instead, Chaosnet relies on error-checking hardware in the network interfaces, and assumes that other sources of packet damage that checksums could detect, such as software bugs in a Network Control Program, either do not occur or will produce symptoms so obvious that they will be detected and fixed immediately.

3.7 Routing ¶

3.8 Flow and Error Control ¶

The Network Control Programs (NCPs) conspire to ensure that data packets are sent from user to user with no garbling, duplications, omissions, or changes of order. Secondarily, the NCPs attempt to achieve a maximum rate of flow of data, and a minimum of overhead and retransmission.

The fundamental basis of flow-control and error-control in Chaosnet is retransmission. Packets which are damaged in transmission, which won’t fit in buffers, which are duplicated or out-of-sequence, or which otherwise are embarrassing are simply discarded. Packets are periodically retransmitted until an indication that they have been successfully received is returned. This retransmission is end-to-end; any intermediate bridges do not participate in flow-control and error-control, and hence are free to discard any packets they wish.

There are actually two kinds of packets, controlled and uncontrolled. Controlled packets are retransmitted and delivered reliably; most packets, including all packets used by the user (except for UNC packets), are of this type. Uncontrolled packets are not retransmitted; these are used for certain lower-level functions of the protocol such as the implementation of flow and error control. The usage of these packets is designed so that they need not be delivered reliably.

Retransmission of a packet continues until stopped by a signal from the receiver to the sender called a receipt. A receipt contains a packet number, and indicates that all controlled packets with a packet number less than or equal (modulo 65536) to that number have been successfully received, and therefore need not be retransmitted any more. A receipt does not indicate that these packets have been processed by the destination user process; it simply indicates that they have successfully arrived in the destination host, and are guaranteed to be there when the user process asks for them.

There is another signal from the receiver to the sender, called an acknowledgement. An acknowledgement also contains a packet number, and indicates that all controlled packets with a packet number less than or equal (modulo 65536) to that number have been read by the destination user process. This is used to implement flow-control. Note that acknowledgement of a packet implies receipt of that packet. In fact, if the receiving process does not fall behind, explicit receipts need not be sent, because the receiving host will not have to buffer any packets, but will acknowledge them as soon as they arrive.

The purpose of flow-control is to match the speeds of the sending and receiving processes. The extremes to be avoided are, on the one hand, too small a "buffer size" causing the data transmission rate to be slower than it could be, and on the other hand, large numbers of packets piling up in the network because the sender is sending faster than the receiver is receiving. It is also necessary to be aware that receipts and acknowledgements must be transmitted through the network, and hence have an associated cost.

Chaosnet flow-control operates by controlling the number of packets "in the network". These are packets which have been emitted by the sending user process, but have not been acknowledged. We define a window into the set of packet numbers. The beginning of this window is the first packet number which has not been acknowledged, and the width of the window is a fixed number established when the connection is opened. The sending process is only allowed to emit packets whose packet numbers lie within the window. Once it has emitted all of the packets in the window, the window is said to be full. Thus, the size of the window is the "buffer size" for the connection, and is the maximum number of packets that may need to be buffered inside an NCP (sending or receiving). Acknowledgements move the window, making it not full, and allowing the sending process to emit additional packets.

We do not receipt and acknowledge every single controlled packet that is transmitted through a connection, since that would double or triple the number of packets sent through the network to move a given amount of data. Instead we batch the receipts and acknowledgements. But if acknowledgements are not sent sufficiently often, the data will not flow smoothly, because the window will often appear full to the sender when it is not. If receipts are not sent sufficiently often, there will be unnecessary retransmissions.

Whenever a packet is sent through a connection, an acknowledgement for the reverse direction of that connection is "piggy-backed" onto it, using the Acknowledgement field in the packet header. For interactive applications, where there is much traffic in both directions, this provides all the necessary acknowledgement and receipting with no need to send any extra packets through the network.

When this does not suffice, STS (status) packets are generated to carry receipts and acknowledgements. STS packets are uncontrolled, since they are part of the mechanism that implements controlled packets. If an STS packet is duplicated, it does no harm. If an STS packet is lost, mechanisms exist which will cause a replacement to be generated later. An STS packet carries separate receipt and acknowledgement packet numbers.

When a user process reads a packet from the network, if the number of packets which should have been acknowledged but have not been is more than 1/3 the window size, an STS is generated to acknowledge them. Thus the preferred batch size for acknowledgement is 1/3 the window size. The advantage of this size is that if one STS is lost, another will be generated before the window fills up (at the 2/3 point).

When a packet is received with the same packet number as one which has already been successfully received, this is evidence of unnecessary retransmission, and an STS is generated to carry a receipt back to the sender. If this STS is lost, the next retransmission will stimulate another one. Thus receipts are normally implied by acknowledgements, and only sent separately when there is evidence of unnecessary retransmission.

Retransmission consists of sending all unreceipted controlled packets, except those that were last sent very recently (within 1/30’th of a second in ITS.) Retransmission occurs every 1/2 second. This interval is somewhat arbitrary, but should be close to the response time of the systems involved. Retransmission also occurs in response to an STS packet, so that a receiver may cause a faster retranmission rate than twice a second if it so desires. This should never cause useless retransmission, since STS carries a receipt, and very-recently-transmitted packets, which might still be in transit through the network, are not retransmitted.

4.1 Connection Establishment ¶

The following packet types are associated with creating and destroying connections. First the packets are described and then the details of the various connection-establishment protocols are given.

Opcode: 1 RFC Request for connection ¶

All connections are initiated by the transmission of an RFC from the user to the server. The data field of the packet contains the contact name. The contact name can be followed by arbitrary arguments to the server, delimited by a space character. The destination index field of an RFC contains 0 since the destination index is not known yet.

RFC is a controlled packet; it is retransmitted until some sort of response is received. Because RFC’s are not sent over normal, error-controlled connections, a special way of detecting and discarding duplicates is required. When an NCP receives an RFC packet, it checks all pending RFC’s and all connections which are in the Open or RFC-received state (see Connection States), to see if the source address and index match; if so, the RFC is a duplicate and is discarded.

Opcode: 12 LSN Listen ¶

A server process informs the local NCP of the contact name to which it is listening by sending a LSN packet, with the contact name in the data field. This packet is never transmitted anywhere through the network. It simply serves as a convenient buffer to hold the server’s contact name. When an RFC and a LSN containing the same contact name meet, the LSN is discarded and the RFC is given to the server, putting its connection into the RFC-received state (see Connection States). The server reads the RFC and decides whether or not to open the connection.

Opcode: 2 OPN Open connection ¶

OPN is the usual positive response to RFC. The source index field conveys the server’s index number to the user; the user’s index number was conveyed in the RFC. The data field of OPN is the same as that of STS (see below); it serves mainly to convey the server’s window-size to the user. The Acknowledgement field of the OPN acknowledges the RFC so that it will no longer be retransmitted.

OPN is a controlled packet; it is retransmitted until it is acknowledged. Duplicate OPN packets are detected in a special way; if an OPN is received for a connection which is not in the RFC-sent state (see Connection States), it is simply discarded and an STS is sent. This can happen if the connection is opened while a retransmitted OPN packet is in transit through the network, or if the STS which acknowledges an OPN is lost in the network.

Opcode: 3 CLS Close connection ¶

CLS is the negative response to RFC. It indicates that no server was listening to the contact name, and one couldn’t be created, or for some reason the server didn’t feel like accepting this request for a connection, or the destination NCP was unable to complete the connection (e.g. connection table full.)

CLS is also used to close a connection after it has been open for a while. Any data packets in transit may be lost. Protocols which require a reliable end-of-data indication should use the mechanism for that (see End-of-Data) before sending CLS.

The data field of a CLS contains a character-string explanation of the reason for closing, intended to be returned to a user as an error message.

CLS is an uncontrolled packet, so that the program which sends it may go away immediately afterwards, leaving nothing to retransmit the CLS. Since there is no error recovery or retransmission mechanism for CLS, the use of CLS is necessarily optional; a process could simply stop responding to its connection. However, it is desirable to send a CLS when possible to provide an error message for the user.

Opcode: 4 FWD Forward a request for connection ¶

This is a response to RFC which indicates that the desired service is not available from the process contacted, but may be available at a possibly-different contact name at a possibly-different host. The data field contains the new contact name and the Acknowledgement field–exceptionally–contains the new host number. The issuer of the RFC should issue another RFC to that address. FWD is an uncontrolled packet; if it is lost in the network, the retransmission of the RFC will presumably stimulate an identical FWD.

Opcode: 5 ANS Answer to a simple transaction ¶

This is another kind of response to RFC. The data field contains the entirety of the response, and no connection is established. ANS is an uncontrolled packet; if it is lost in the network, the retransmission of the RFC will presumably stimulate an identical ANS.

There are several connection-initiation protocols implemented with these packet types. In addition to those described here, there is also a broadcast mechanism; see Broadcast.

When an RFC arrives at a host, the NCP finds a user process that is listening for this RFC’s contact name, or creates a server process to provide the desired service, or responds to the RFC itself if it knows how to provide the requested service, or refuses the request for connection. The process that serves the RFC chooses which connection-initiation protocol to follow. This process is given the RFC as data, so that it can look at the contact name and any arguments that may be present.

A stream connection is initiated by an RFC, transmitted from user to server. The server returns an OPN to the user, which responds with an STS. These three packets convey the source and destination addresses, indices, initial packet numbers, and window sizes between the two NCP’s. In addition a character-string argument can be conveyed from the user to the server in the RFC.

The OPN serves to acknowledge the RFC and extinguish its retransmission. It also carries the server’s index, initial packet number, and window size. The STS serves to acknowledge the OPN and extinguish its retransmission. It also carries the user’s window size; the user’s index and initial packet number were carried by the RFC. Retransmission of the RFC and the OPN provides reliability in the face of lost packets. If the RFC is lost, it will be retransmitted. If the STS is lost, the OPN will be retransmitted. If the OPN is lost, the RFC will be retransmitted superfluously and the OPN will be retransmitted since no STS will be sent.

The exchange of an OPN and an STS tells each side of the connection that the other side believes the connection is open; once this has happened data may begin to flow through the connection. The user process may begin transmitting data when it sees the OPN. The server process may begin transmitting data when it sees the STS. These rules ensure that data packets cannot arrive at a receiver before it knows and agrees that the connection is open. If data packets did arrive before then, the receiver would reject them with a LOS (see below), believing them to be a violation of protocol, and this would destroy the connection before it was ever fully established.

Once data packets begin to flow, they are subject to the flow and error control protocol described in Flow and Error Control. Thus a stream connection provides the desired reliable, bidirectional data stream.

A refusal is initiated by an RFC in the same way, but the server returns CLS rather than OPN. The data field of the CLS contains the reason for refusal to connect.

A forwarded connection is initiated by an RFC in the same way, but the server returns a FWD, telling the user another place to look for the desired service.

A simple transaction is initiated by an RFC from user to server, and completed by an ANS from server to user. Since a full connection is not established and the reliable-transmission mechanism of connections is not used, the user process cannot be sure how many copies of the RFC the server saw, and the server process cannot be sure that its answer got back to the user. This means that simple transactions should not be used for applications where it is important to know whether the transaction was really completed, nor for applications in which repeating the same query might produce a different answer. Simple transactions are a simple efficient mechanism for applications such as extracting a small piece of information (e.g. the time of day) from a central data-base.

4.2 Status ¶

Opcode: 7 STS Status ¶

STS is an uncontrolled packet which is used to convey status information between NCPs. The Acknowledgement field in the packet header contains an acknowledgement, that is, the packet number of the last packet given to the receiving user process. The first 16-bit byte in the data field contains a receipt, that is, a packet number such that all controlled packets up to and including that one have been successfully received by the NCP. The second 16-bit byte in the data field contains the window size for packets sent in the opposite direction (to the end of the connection which sent the STS). The byte count is presently always 4. This will change if the protocol is revised to add additional items to the STS packet.

Opcode: 6 SNS Sense status ¶

SNS is an uncontrolled packet whose sole purpose is to cause the other end of the connection to send back an STS. This is used by the probing mechanism described above (see Probing).

Opcode: 11 LOS Lossage ¶

LOS is an uncontrolled packet which is used by one NCP to inform another of an error. The data field contains a character-string explanation of the problem. The source and destination addresses and indices are simply the destination and source addresses and indices, respectively, of the erroneous packet, and do not necessarily correspond to a connection. When an NCP receives a LOS whose destination corresponds to an existent connection and whose source corresponds to the supposed other end of that connection, it breaks the connection and makes the data field of the LOS available to the user as an error message. Other LOS’s, that don’t correspond to connections, are simply ignored.

LOS is sent in response to situations such as: arrival of a data packet or an STS for a connection that does not exist or is not open, arrival of a packet from the wrong source for its destination, arrival of a packet containing an undefined opcode or too large a byte count, etc.

LOS’s are given to the user process so that it may read the error message.

No LOS is given in response to an OPN to a connection not in the RFC-Sent state, nor in response to a SNS to a connection not in the Open state, nor in response to a LOS to a non-existent or broken connection. These rules are important to make the protocols work without timing errors. An OPN or a SNS to a non-existent connection elicits a LOS.

4.3 Data ¶

Opcode: 200-277 DAT 8-bit Data ¶

Opcodes 200 through 277 (octal) are controlled packets with user data in 8-bit bytes in the data field. The NCP treats all 64 of these opcodes identically; some higher-level protocols use the opcodes for their own purposes. The standard default opcode is 200.

Opcode: 300-377 DAT 16-bit Data ¶

Opcodes 300 through 377 (octal) are controlled packets with user data in 16-bit bytes in the data field. The NCP treats all 64 of these opcodes identically; some higher-level protocols use the opcodes for their own purposes. The standard default opcode for 16-bit data is 300.

Opcode: 15 UNC Uncontrolled Data ¶

This is an uncontrolled packet with user data in 8-bit bytes in the data field. It exists so that user-level programs may bypass the flow-control mechanism of Chaosnet protocol. Note that the NCP is free to discard these packets at any time, since they are uncontrolled. Since UNC’s are not subject to flow control, discarding may be necessary to avoid running out of buffers. A connection may not have more input packets queued awaiting the attention of the user program than the window size of the connection, except that you are always allowed to have one UNC packet queued. If no normal data packets are in use, up to one more UNC packet than the window size may be queued.

UNC packets are also used by the standard protocol for encapsulating packets of foreign protocols for transmission through Chaosnet (see Using Foreign Protocols in Chaosnet).

4.4 End-of-Data ¶

Opcode: 14 EOF End of File ¶

EOF is a controlled packet which serves as a "logical end of data" mark in the packet stream. When the user program is ignoring packets and treating a Chaosnet connection as a conventional byte-stream I/O device, the NCP uses the EOF packet to convey the notion of conventional end-of-file from one end of the connection to the other. When the user program is working at the packet level, it may transmit and receive EOF’s.

It is illegal to put data in an EOF packet; in other words, the byte count should always be zero. Most Chaosnet implementations will simply ignore any data that is present in an EOF.

EOF packets are used in the following protocol which is the recommended way to reliably determine that all data have been transferred before closing a connection (in applications where that is an important consideration).

The important issue is that neither side may send a CLS until both sides are sure that all the data have been transmitted. After sending all the data it is going to send, including an EOF packet to mark the end, the sending process waits for all packets to be acknowledged. This ensures that the receiver has seen all the data and knows that no more data are to come. The sending process then closes the connection. When the receiving process sees an EOF, it knows that there are no more data. It does not close the connection until it sees the sender close it, or until a brief timeout elapses. The timeout is to provide for the case where the sender’s CLS gets lost in the network (CLS cannot be retransmitted). The timeout is long enough (a few seconds) to make it unlikely that the sender will not have seen the acknowledgement of the EOF by the time the timeout is over.

To use this protocol in a bidirectional fashion, where both parties to the connection are sending data simultaneously, it is necessary to use an asymmetrical protocol. Arbitrarily call one party the user and the other the server. The protocol is that after sending all its data, each party sends an EOF and waits for it to be acknowledged. The server, having seen its EOF acknowledged, sends a second EOF. The user, having seen its EOF acknowledged, looks for a second EOF and then sends a CLS and goes away. The server goes away when it sees the user’s CLS, or after a brief timeout has elapsed. This asymmetrical protocol guarantees that each side gets a chance to know that both sides agree that all the data have been transferred. The first CLS will only be sent after both sides have waited for their (first) EOF to be acknowledged.

4.5 Broadcast ¶

Chaosnet includes a generalized broadcast facility, intended to satisfy needs such as:

• Locating services when it is not known what host they are on.
• Internal communications of other protocols using Chaosnet as a transmission medium, such as routing in their own address spaces.
• Reloading and remote debugging of Chaosnet bridge computers.
• Experiments with radically different protocols.

Opcode: 16 BRD Broadcast ¶

A BRD packet works much like an RFC packet; it contains the name of a server to be communicated with, and possibly some arguments. Unlike an RFC, which is delivered to a particular host, a BRD is broadcast to all hosts. Only hosts which understand the service it is looking for will respond. The response can be anything which is valid as a response to RFC. Typically BRD will be used in a simple-transaction mode, and the response will be an ANS packet. Actually it can be any number of ANS packets since multiple hosts may respond. BRD can also be used to open a full byte-stream connection to a server whose host is not known. In this case the response will be an OPN packet; only the first OPN succeeds in opening a connection. CLS is also a valid response, but only as a true negative response; BRD’s for unrecognized or unavailable services should be ignored and no CLS should be sent, since some other host might be able to provide the service.

The TIME and STATUS protocols (see Higher-Level Protocols) will work through BRD packets as well as RFC packets. I don’t think there are any other standard protocols that need to be able to work with BRD packets.

The data field of a BRD contains a subnet bit map followed by a contact name and possible arguments. The subnet bit map has a "1" for each subnet on which this packet is to be broadcast to all hosts; these bits are turned off as the packets flow through the network, to avoid loops. The sender initializes the bit map with 1’s for whichever subnets he desires (often all of them).

In the packet header, the destination host and index are 0. The source host and index are who to send the reply (ANS or OPN) to. The acknowledgement field contains the number of bytes in the bit map (this would normally be 32, but may be changed in the future). The number of bytes in the bit map is required to be a multiple of 4. Bits in the bitmap are numbered from right to left within a byte and from earlier to later bytes; thus the bit for subnet 1 is the bit with weight 2 in the first byte of the data field. Bits that lie outside of the declared length of the bit map are considered to be zero; thus the BRD is not transmitted to those subnets.

After the subnet bit map there is a contact name and arguments, exactly as in an RFC. Operating systems should treat incoming BRD packets exactly like RFC, even to the extent that a contact name of STATUS must retrieve the host’s network throughput and error statistics. BRD packets will never be refused with a "CLS", however; broadcast requests to nonexistent servers should simply be ignored, and no CLS reply should be sent. Most operating systems will simplify incoming BRD handling for themselves and their users by reformatting incoming BRD packets to look like RFC’s; deleting the subnet bit map from the data field and decreasing the byte count. For consistency when this is done the bit map length (in the acknowledgement field) should be set to zero. The packet opcode will remain BRD (rather than RFC).

Operating systems should handle outgoing BRD packets as follows. When a user process transmits a BRD packet over a closed connection, the connection enters a special "Broadcast Sent" state. In this state, the user process is allowed to transmit additional BRD packets. All incoming packets other than OPN’s should be made available for the user process to read, until the allowed buffering capacity is exceeded; further incoming packets are then simply discarded. These incoming packets would normally be expected to consist of ANS, FWD, and CLS packets only. If an OPN is received, and there are no queued input packets, a regular byte-stream connection is opened. Any OPN’s from other hosts elicit a LOS reply as usual, as do any ANS’s, CLS’s, etc. received at this point.

Operating systems should not retransmit BRD packets, but should leave this up to the user program, since only it knows when it has received enough answers (or a satisfactory answer).

BRD packets can be delivered to a host in multiple copies when there are multiple paths through the network between the sender and that host. The bit map only serves to cut down looping more than the forwarding-count would, and to allow the sender to broadcast selectively to portions of the net, but cannot eliminate multiple copies. The usual mechanisms for discarding duplicated RFC’s will also cause most duplicated BRD’s to be discarded.

BRD packets put a noticeable load on every host on the network, so they should be used judiciously. "Beacons" that send a BRD every 30 seconds all day long should not be used.

4.6 Low-level ¶

Opcode: 13 MNT Maintenance ¶

MNT is a special packet type reserved for the use of network maintenance programs. Normal NCPs should simply discard any MNT packets they receive. MNT packets are an escape mechanism to allow special programs to send packets that are guaranteed not to get confused with normal packets. MNT packets are forwarded by bridges although usually one would not be depending on this.

Opcode: 10 RUT Routing Information ¶

RUT is a special packet type broadcast by bridges to inform other nodes of the bridge’s ability to forward packets between subnets. The source address is the network address of the bridge on the subnet on which the RUT was broadcast. The destination address is zero. The byte count is a multiple of 4, and the data field contains a series of pairs of 16-bit bytes: a subnet number and the "cost" of getting to that subnet via this bridge. The packet number and acknowledgement fields are not used and should contain zero. See Routing for the details.

4.7 Connection States ¶

A user process gets to Chaosnet by means of a capability or channel (dependent on the host operating system) which corresponds to one end of a connection. Associated with this channel are a number of buffers containing controlled packets output by the user and not yet receipted, and data packets received from the network but not yet read by the user; some of these incoming packets are in-order by packet number and hence may be read by the user, while others are out of order and cannot be read until packets earlier in the stream have been received. Certain control packets are also given to the user as if they were data packets. These are RFC, ANS, CLS, LOS, EOF, and UNC. EOF is the only type that can ever be out-of-order.

Also associated with the channel is a state, usually called the connection state. Full understanding of these states depends on the descriptions of packet-types above. The state can be one of:

Open

The connection exists and data may be transferred.

Closed

The channel does not have an associated connection. Either it never had one or it has received or transmitted a CLS packet, which destroyed the connection.

Listening

The channel does not have an associated connection, but it has a contact name (usually contained in a LSN packet) for which it is listening.

RFC Received

A Listening channel enters this state when an RFC arrives. It can become Open if the user process accepts the request.

RFC Sent

The user has transmitted an RFC. The state will change to Open or Closed when the reply to the RFC comes back.

Broadcast Sent

The user has transmitted a BRD. In this state, the user process is allowed to transmit additional BRD packets. All incoming packets other than OPN’s are made available for the user process to read, until the allowed buffering capacity is exceeded; further incoming packets are then simply discarded. These incoming packets would normally be expected to consist of ANS, FWD, and CLS packets only. If an OPN is received, and there are no queued input packets, a regular byte-stream connection is opened (the connection enters the Open state). Any OPN’s from other hosts elicit a LOS reply as usual, as do any ANS’s, CLS’s, etc. received at this point.

Lost

The connection has been broken by receiving a LOS packet.

Incomplete Transmission

The connection has been broken because the other end has ceased to transmit and to respond to SNS. Either the network or the foreign host is down. (This can also happen if the local host goes down for a while and then is revived, if its clock runs in the meantime.)

Foreign

The channel is talking some foreign protocol, whose packets are encapsulated in UNC packets. As far as Chaosnet is concerned there is no connection. See Using Foreign Protocols in Chaosnet for the details.

5.1 Status ¶

All network nodes, even bridges, are required to answer RFC’s with contact name STATUS, returning an ANS packet in a simple transaction. This protocol is primarily used for network maintenance. The answer to a STATUS request should be generated by the Network Control Program, rather than by starting up a server process, in order to provide rapid response.

The STATUS protocol is used to determine whether a host is up, to determine whether an operable path through the network exists between two hosts, to monitor network error statistics, and to debug new Network Control Programs and new Chaosnet hardware. The hostat function on the Lisp machine, and the Hostat command of the CHATST program on ITS are user ends for this protocol.

The first 32 bytes of the ANS contain the name of the node, padded on the right with zero bytes. The rest of the packet contains blocks of information expressed in 16-bit and 32-bit words, low byte first (pdp11/Lisp machine style). The low-order half of a 32-bit word comes first. Since ANS packets contain 8-bit data (not 16-bit), machines such as pdp10s which store numbers high byte first will have to shuffle the bytes when using this protocol. The first 16-bit word in a block is its identification. The second 16-bit word is the number of 16-bit words to follow. The remaining words in the block depend on the identification.

This is the only block type currently defined. All items are optional, according to the count field, and extra items not defined here may be present and should be ignored. Note that items after the first two are 32-bit words.

word 0

A number between 400 and 777 octal. This is 400 plus a subnet number. This block contains information on this host’s direct connection to that subnet.

word 1

The number of 16-bit words to follow, usually 16.

words 2-3

The number of packets received from this subnet.

words 4-5

The number of packets transmitted to this subnet.

words 6-7

The number of transmissions to this subnet aborted by collisions or because the receiver was busy.

words 8-9

The number of incoming packets from this subnet lost because the host had not yet read a previous packet out of the interface and consequently the interface could not capture the packet.

words 10-11

The number of incoming packets from this subnet with CRC errors. These were either transmitted wrong or damaged in transmission.

words 12-13

The number of incoming packets from this subnet which had no CRC error when received, but did have an error after being read out of the packet buffer. This error indicates either a hardware problem with the packet buffer or an incorrect packet length.

words 14-15

The number of incoming packets from this subnet which were rejected due to incorrect length (typically not a multiple of 16 bits).

words 16-17

The number of incoming packets from this subnet rejected for other reasons (e.g. too short to contain a header, garbage byte-count, forwarded too many times.)

If the identification is a number between 0 and 377 octal, this is an obsolete format of block. The identification is a subnet number and the counts are as above except that they are only 16 bits instead of 32, and consequently may overflow. This format should no longer be sent by any hosts.

Identification numbers of 1000 octal and up are reserved for future use.

5.2 Pulsar ¶

For network maintenance purposes, certain network nodes support a simple transaction with contact name PULSAR, which controls a "pulsar" feature. This feature periodically transmits a short packet which can be used to test and adjust cable transceivers. The packet consists of the three header words, a zero word, and a word of alternating ones and zeros. It is addressed to host 177777 which is guaranteed not to exist.

The returned ANS contains a single character, which is a digit. A 0 means that the pulsar is turned off. Any other digit indicates the number of sixtieths of a second between pulses. Sending an RFC with a digit as an argument sets the state of the pulsar to that digit, and returns an ANS containing the new state. Pulsars should be off by default, and should only be turned on when debugging the network. The waste of cable bandwidth and machine resources is negligible except in extremely large networks, since pulsar packets are so short, but when debugging or making measurements on cables using pulsar packets it is important to know where the packets are coming from.

Bridge nodes which implement the PULSAR protocol and possess more than one network interface should should have a single pulsar which transmits on all network interfaces, rather than bothering to provide a more complex protocol by which pulsars on the individual interfaces could be turned on and off.

5.3 Telnet and Supdup ¶

The Telnet and Supdup protocols of the Arpanet [TELNET] [SUPDUP] exist in identical form in Chaosnet. These protocols allow access to a computer system as an interactive terminal from another network node.

The contact names are TELNET and SUPDUP. The direct borrowing of the Telnet and Supdup protocols was eased by their use of 8-bit byte streams and only a single connection. Note that these protocols define their own character sets, which differ from each other and from the Chaosnet standard character set.

Chaosnet contains no counterpart of the INR/INS attention-getting feature of the Arpanet. The Telnet protocol sends a packet with opcode 201 in place of the INS signal. This is a controlled packet and hence does not provide the "out of band" feature of the Arpanet INS, however it is satisfactory for the Telnet "interrupt process" and "discard output" operations on the kinds of hosts attached to Chaosnet.

5.4 File Access ¶

The FILE protocol is primarily used by Lisp machines to access files on network file servers. ITS and TOPS-20 are equipped to act as file servers. A user end for the file protocol also exists for TOPS-20 and is used for general-purpose file transfer. For complete documentation on the file protocol, see [FILE]. The Arpanet file transfer protocols have not been implemented on the Chaosnet (except through the Arpanet gateway described below).

5.5 Mail ¶

The MAIL protocol is used to transmit inter-user messages through the Chaosnet. The Arpanet mail protocol was not used because of its complexity and poor state of documentation. This simple protocol is by no means the last word in mail protocols; however, it is adequate for the mail systems we presently possess.

The sender of mail connects to contact name MAIL and establishes a stream connection. It then sends the names of all the recipients to which the mail is to be sent at (or via) the server host. The names are sent one to a line and terminated by a blank line (two carriage returns in a row). The Lisp Machine character set is used. A reply (see below) is immediately returned for each recipient. A recipient is typically just the name of a user, but it can be a user-atsign-host sequence or anything else acceptable to the mail system on the server machine. After sending the recipients, the sender sends the text of the message, terminated by an EOF. After the mail has been successfully swallowed, a reply is sent. After the sender of mail has read the reply, both sides close the connection.

In the MAIL protocol, a reply is a signal from the server to the user (or sender) indicating success or failure. The first character of a reply is a plus sign for success, a minus sign for permanent failure (e.g. no such user exists), or a percent sign for temporary failure (e.g. unable to receive message because disk is full). The rest of a reply is a human-readable character string explaining the situation, followed by a carriage return.

The message text transmitted through the mail protocol normally contains a header formatted in the Arpanet standard fashion. [RFC733]

5.6 Send ¶

The SEND protocol is used to transmit an interactive message (requiring immediate attention) between users. The sender connects to contact name SEND at the machine to which the recipient is logged in. The remainder of the RFC packet contains the name of the person being sent to. A stream connection is opened and the message is transmitted, followed by an EOF. Both sides close after following the end-of-data protocol described in End-of-Data. The fact that the RFC was responded to affirmatively indicates that the recipient is in fact present and accepting messages. The message text should begin with a suitable header, naming the user that sent the message. The standard for such headers, not currently adhered to by all hosts, is one line formatted as in the following example:

Moon@MIT-MC 6/15/81 02:20:17

Automatic reply to the sender can be implemented by searching for the first "@" and using the SEND protocol to the host following the "@" with the argument preceding it.

5.7 Name ¶

The Name/Finger protocol of the Arpanet [FINGER] exists in identical form on the Chaosnet. Both Lisp machines and timesharing machines support this protocol and provide a display of the user(s) currently logged in to them.

The contact name is NAME which can be followed by a space and a string of arguments like the "command line" of the Arpanet protocol. A stream connection is established and the "finger" display is output in Lisp Machine character set, followed by an EOF.

Lisp Machines also support the FINGER protocol, a simple-transaction version of the NAME protocol. An RFC with contact name FINGER is transmitted and the response is an ANS containing the following items of information separated by carriage returns: the logged-in user ID, the location of the terminal, the idle time in minutes or hours-colon-minutes, the user’s full name, and the user’s group affiliation.

5.8 Time ¶

The Time protocol of the Arpanet [TIME] exists on Chaosnet as a simple transaction. An RFC to contact name TIME evokes an ANS containing the number of seconds since midnight Greenwich Mean Time, Jan 1, 1900 as a 32-bit number in four 8-bit bytes, least-significant byte first. Some computers–Lisp machines, for example–which don’t have hardware calendar-clocks use this protocol to find out the date and time when they first come up.

5.9 Arpanet Gateway ¶

This protocol allows a Chaosnet host to access almost any service on the Arpanet. The gateway server runs on each ITS host that is connected to both networks. It creates an Arpanet connection and a Chaosnet connection and forwards data bytes from one to the other. It also provides for a one-way auxiliary connection, used for the data connection of the Arpanet File Transfer Protocol.

The RFC packet contains a contact name of ARPA, a space, the name of the Arpanet host to be connected to, optionally followed by a space and the contact-socket number in octal, which defaults to 1 if omitted. The Arpanet Initial Connection Protocol is used to establish a bi-directional 8-bit connection.

If a data packet with opcode 201 (octal) is received, an Arpanet INS signal will be transmitted. Any data bytes in this packet are transmitted normally.

If a data packet with opcode 210 (octal) is received, an auxiliary connection on each network is opened. The first eight data bytes are the Chaosnet contact name for the auxiliary connection; the user should send an RFC with this name to the server. The next four data bytes are the Arpanet socket number to be connected to, in the wrong order, most-significant byte first. The byte-size of the auxiliary connection is 8 bits.

The normal closing of an Arpanet connection corresponds to an EOF packet. Closing due to an error, such as Host Dead, corresponds to a CLS packet.

5.10 Host Table ¶

The HOSTAB protocol may be used to access tables of host addresses on other networks, such as the Arpanet. Servers for this protocol currently exist for Tenex and TOPS-20.

The user connects to contact name HOSTAB, undertakes a number of transactions, then closes the connection. Each transaction is initiated by the user transmitting a host name followed by a carriage return. The server responds with information about that host, terminated with an EOF, and is then ready for another transaction. The server’s response consists of a number of attributes of the host. Each attribute consists of an identifying name, a space character, the value of the attribute, and a carriage return. Values may be strings (free of carriage returns and not surrounded by double-quotes) or octal numbers. Attribute names and most values are in upper case. There can be more than one attribute with the same name; for example, a host may have more than one name or more than one network address.

The standard attribute names defined now are as follows. Note that more are likely to be added in the future.

ERROR

The value is an error message. The only error one might expect to get is "no such host".

NAME

The value is a name of the host. There may be more than one NAME attribute; the first one is always the official name, and any additional names are nicknames.

MACHINE-TYPE

The value is the type of machine, such as LISPM, PDP10, etc.

SYSTEM-TYPE

The value is the type of software running on the machine, such as LISPM, ITS, etc.

ARPA

The value is an address of the host on the Arpanet, in the form host/imp. The two numbers are decimal.

CHAOS

The value is an address of the host on Chaosnet, as an octal number.

DIAL

The value is an address of the host on Dialnet, as a telephone number.

LCS

The value is an address of the host on the LCSnet, as two octal numbers separated by a slash.

SU

The value is an address of the host on the SUnet, in the form net#host. The two numbers are octal.

5.11 Dover ¶

A press file may be sent to the Dover printer by connecting to contact name DOVER at host AI-CHAOS-11. This host provides a protocol translation service which translates from Chaosnet stream protocol to the EFTP protocol spoken by the Dover printer. Only one file at a time can be sent to the Dover, so an attempt to use this service may be refused by a CLS packet containing the string "BUSY". Once the connection has been established, the press file is transmitted as a sequence of 8-bit bytes in data packets (opcode 200). It is necessary to provide packets rapidly enough to keep the Dover’s program (Spruce) from timing out; a packet every five seconds suffices. Of course, packets are normally transmitted much more rapidly.

Once the file has been transmitted, an EOF packet must be sent. The transmitter must wait for that EOF to be acknowledged, send a second one, then close the connection. The two EOF’s are necessary to provide the proper connection-closing sequence for the EFTP protocol. Once the press file has been transmitted to the Dover in this way and stored on the Dover’s local disk, it will be processed and prepared for printing, and then printed.

If an error message is returned by the Dover while the press file is being transmitted, it will be reported back through the Chaosnet as a LOS containing the text of the error message. Such errors are fairly common; the sender of the press file should be prepared to retry the operation a few times.

Most programs that send press files to the Dover first wait for the Dover to be idle, using the Foreign Protocol mechanism of Chaosnet to check the status of the Dover. This is optional, but is courteous to other users since it prevents printing from being held up while additional files are sent to the Dover and queued on its local disk.

It would be possible to send to a press file to the Dover using its EFTP protocol through the Foreign Protocol mechanism, rather than using the AI-CHAOS-11 gateway service. This is not usually done because EFTP, which requires a handshake for every packet, tends to be very slow on a timesharing system.

9.1 Opening Connections ¶

A (potential) Chaosnet connection is represented by a JFN. When the JFN is opened, an actual Chaosnet connection is created. The GTJFN syntax is as follows:

The device name is CHA:. The filename is the symbolic name or octal number of the host at the other end of the connection, or a null string if it is desired to listen for an incoming Request For Connection rather than initiating a connection. The extension (filetype) is normally the contact name; some special cases are described below. Use of * names and JFN stepping is not permitted. The directory, generation (version) number, and semicolon attributes are ignored if present.

When the JFN is opened (with OPENF), normally the system will wait for the connection to open up; a user connection (nonblank filename) will wait for a response to be returned to its RFC, and a server connection (blank filename) will wait for an RFC to come in to its contact name. If an RFC is refused or the foreign host is not up, OPENF will return an error. If data mode 6 or 7 is used with OPENF, it will return immediately, without waiting for the connection to open. This is useful if you want to open several Chaosnet connections simultaneously, or if you want to determine the reason for failure if the connection does not open; if the normal data mode 0 OPENF fails, the operating system will not let you read the CLS packet nor do the .MOERR operation (described below).

There are a number of special cases in the GTJFN syntax. If the extension is a null string, then the contact name is specified by OPENF rather than by GTJFN; AC3 contains the number of characters in the contact name in the left half, and the address of the contact name in the right half. In listening mode (the filename is a null string), then if the extension is also null, this JFN will listen to any RFC that is not otherwise serviced. Privileges are required and only one job at a time can do this. This mechanism is used by a system server process. If the filename is null and the extension is a hyphen, the JFN is put in a special mode for simple transactions; packet-level I/O may be used to transmit any number of RFCs and receive any response packets (ANS, FWD, LOS, or CLS).

When a JFN is closed with CLOSF, if it has an open connection the end-of-data protocol is used (an EOF packet is transmitted and its acknowledgement is awaited), and then a CLS packet is transmitted. (This is not completely implemented yet; currently no EOF is sent, and .MOEOF (see below) must be used.) If the JFN is in the RFC-Received state, the RFC is refused by sending a CLS.

9.2 Stream Input and Output ¶

The normal I/O JSYSes (BIN, BOUT, SIN, SOUT) work on Chaosnet JFNs. When the connection was created by listening, doing I/O to it automatically accepts it first (sending an OPN). The input and output data are transmitted as 8-bit bytes in standard data packets (opcode 200). On input, if an EOF packet is encountered the standard end-of-file action occurs. If a CLS or LOS is encountered, or the connection is in a bad state, an error is signalled. The message from the CLS or LOS may be picked up with .MOERR (see below).

On TOPS-20, but not Tenex, the SIBE, SOBE, DIBE, DOBE, SINR, and SOUTR JSYSes may be used. The latter two treat each packet as a separate record.

The OPENF byte size may be either 7 or 8. With a byte size of 8, the raw Chaosnet data bytes are transmitted. With a byte size of 7, the system converts between the ASCII code it uses normally and the Lisp Machine character set, which is standard on Chaosnet. (This is not yet implemented; currently a byte size of 7 will be accepted but will behave the same as 8.)

9.3 Packet Input and Output ¶

It is possible to do packet-level input and output and to deal directly with the details of the Chaosnet protocol by using the special operations described in the following section. Note that stream I/O and packet I/O should not be mixed in the same connection, unless you know exactly what you are doing, since you can get your data out of order.

9.4 Special Operations ¶

GDSTS returns device-dependent status. AC2 returns the state of the connection, and AC3 returns the number of packet slots available in the output window in the left half, and the number of available input packets in the right half. The symbolic names for the connection states are as follows:

.CSCLS

The connection is closed (or was never opened).

.CSLSN

The connection is listening for an RFC.

.CSRFC

An RFC has been received by a listening connection.

.CSRFS

An RFC has been sent.

.CSOPN

The connection is open.

.CSLOS

The connection has been broken by a LOS packet.

.CSINC

The connection has been broken by Incomplete Transmission (no response from the other end for a long time).

.CSPRF

This is the "permanent RFC" state which is entered by GTJFN with a null filename and an extension of just a hyphen.

MTOPR performs a variety of special operations, with the JFN in AC1, one of the following function codes in AC2, and an argument and/or return value in AC3.

.MOPKS

Send a packet. AC3 contains the address of the first word of the packet. An error return is taken if the connection is in a bad state for the kind of packet being transmitted. This will wait for space to be available in the window.

.MOPKR

Receive a packet. AC3 contains the address of a 126-word buffer in which the packet is to be stored. This will wait until an input packet arrives.

.MOOPN

Accept a Request for Connection. Error if the connection is not in the RFC-received state.

.MOSND

Force out any buffered stream output.

.MOEOF

Force out any buffered stream output, then send an EOF packet.

.MONOP

Force out any buffered stream output, then wait for it to be transmitted and acknowledged. (This is not a "no op", but .MONOP is the system standard name for this operation.)

.MOERR

Returns the error message from a received CLS or LOS packet. An error is signalled if no error message is available. AC3 is a string pointer to where to put the error message; it is updated to point at the terminating null character which makes the message an ASCIZ string.

.MOACN

Assigns PSI (interrupt) channels. The left half of AC3 is the channel number for output interrupts, and the right half is the channel number for input and state-change interrupts. Specifying -1 as a channel number disables interrupts. Output interrupts are signalled when the window is full and then an acknowledgement is received which makes some space so that more packets may be output. Input interrupts are signalled when the state changes, and when there are no input packets available and then a packet is received.

.MOSWS

Sets the receive window size from AC3.

.MORWS

Returns the receive window size in the left half of AC3 and the transmit window size in the right half.

.MOAWS

Returns the available space in the transmit window in AC3.

.MOUAC

Returns the number of unacknowledged output packets in AC3.

.MOFHS

Returns the foreign host number in AC3.

.MOSIZ

Returns the maximum packet size in bytes in AC3. This can be smaller than the Chaosnet standard (488) on machines encumbered with an RSX20F front end.

.MOSRT

Sets the RFC timeout period in milliseconds from AC3. The maximum is 262 seconds.

9.5 Utility Programs ¶

There are two Chaosnet utility programs, both named CHASTA. One prints one line for each connection that exists, giving its state, number of input and output packets, who it is connected to, etc. The other prints the STATUS protocol information for every host on the network, including the host name, when it was last up, and its packet throughput and error counts. This information is maintained by a system daemon process.

9.6 Server Programs ¶

When an RFC is received for contact-name, if no process is listening for contact-name and the file SYSTEM:CHAOS.contact-name (or DSK:<SYSTEM>CHAOS.contact-name on Tenex) exists, the server program contained in that file is run. The server program should open CHA:.contact-name. This is implemented by the CHARFC program which runs as a daemon job and opens CHA:., the magic name which gets a copy of all unclaimed RFCs. Normally the server program is run in a freshly-created job, and may log in if it wishes, but if the file is marked as ephemeral (the ";E" attribute), it is run in a subfork of the CHARFC job. Ephemeral servers should be used for protocols that don’t involve a long-term connection.

The TELNET and SUPDUP servers attach their Chaosnet connection directly to an NVT, just as the corresponding Arpanet servers do.

When the system starts up, the file SYSTEM:HOSTS2.BIN (or DSK:<SYSTEM>HOSTS2.BIN on Tenex) is read in and used to initialize the host name table inside the system used by GTJFN. This is the ITS/TOPS-20/WAITS standard multi-network host table.

12.2 Special Files for Creating Connections ¶

There are several special files in the file system that provide ways of creating and accessing connections (these names are defined in <chaos/user.h>):

CHRFCDEV

Opening this file creates a connection to a remote host. The host address should follow the file name as an additional pathname component containing ascii digits representing the Chaosnet address in decimal (soon to be octal). The rest of the pathname after the host address is taken as the contact name that will be sent in the RFC packet. Thus to open a TELNET connection to the host at address 234 use:

#include <chaos/user.h>
#include <chaos/contacts.h>
char pathbuf[100];
int fd;
sprintf(pathbuf,
        "%s/%d/%s", CHRFCDEV, 234, CHAOS_TELNET);
fd = open(pathbuf, 2);

To send a message to User at host address 567 use:

sprintf(pathbuf,
        "%s/%d/%s %s", CHRFCDEV, 567, CHAOS_SEND, User);
fd = open(pathbuf, 1);

Opening CHRFCDEV returns when the response to the RFC is received from the remote host, or a fixed timeout, whichever happens first. Other timeouts may be implemented by the user program, using the alarm system call. ANS packets are acceptable responses. The data in the ANS packet will be readable, and will be followed by end-of-file as with a full connection or a normal file.

CHRFCADEV

This device provides the same functions as CHRFCDEV except that it returns immediately after transmission of the RFC packet with the connection in the CSRFCSENT state. This allows the user program to have access to the contents of packets refusing the connection (CLS, LOS). See the CHIOCSWAIT and CHIOCPREAD ioctl’s below.

CHLISTDEV

Opening this file creates a connection in the Listening state with the contact name given as the pathname component following the device name. Thus to listen for a TELNET connection use:

sprintf(pathbuf, "%s/%s", CHLISTDEV, CHAOS_TELNET);
fd = open(pathbuf, 2);

Use the CHIOCSWAIT ioctl to wait for a RFC to arrive, and CHIOCREJECT, CHIOCACCEPT, or CHIOCANSWER to respond.

CHURFCDEV

This file, the "unmatched RFC server" device, when opened and read will return the contents of RFC packets that have no listener. Read calls on this connection just return RFC data. If another read on this file is done before the RFC is matched, it is discarded. This file may only be opened by one user at a time. Normally this file is opened by the system unmatched-RFC server process.

12.3 Stream Mode Connections ¶

The default mode when a Chaosnet device is opened is stream mode. This mode makes the connection behave like a UNIX file, with the exception that seek system calls are disallowed and read calls will return whatever data is available if there is any. (Rather than returning the full number of bytes requested.) Thus standard I/O library routines can easily be used to read and write on these connections. A normal UNIX end of file indication will be returned on receiving an EOF packet, and will continue to be returned until either the connection is closed or more data arrives on the connection. If the connection is closed before an EOF packet is received (via a CLS or LOS packet arriving or a connection timeout occurring), an error will be returned after all data and EOF packets have been read.

If the file was opened for writing (open mode 1 or 2), then an EOF packet will be sent and its acknowledgement awaited when the file is closed (unless the connection was already closed).

In stream mode all non-data packets are discarded and data packet opcodes are all treated the same. Ioctl’s can be used to read non-data packets (RFC, CLS, LOS etc.) and perform other network specific functions.

The contents of ANS and UNC packets are read as data in the stream, just as if they had been data packets.

12.4 Record Mode Connections ¶

This mode, set on a connection by issuing

ioctl(fd, CHIOCSMODE, CHRECORD);

gives the user program access to packet opcodes and packet boundaries, without any further awareness of network data structures. Read calls from the connection return all the data in a single packet, with the first byte of the data being the opcode in the packet. The count returned is, as normal, the count of bytes transfered, including the opcode. Opcodes are defined in <chaos/user.h>.

RFC, ANS, CLS, LOS, EOF, UNC, FWD, and data packets will be returned to the user. The buffer given must be large enough to fit the entire packet including the opcode byte, or an error is returned.

Write calls must include the desired opcode as the first byte of data and also reflect this byte in the byte count. The data to be written must not exceed the maximum packet size.

If a record mode connection is closed in the OPEN state a CLS packet will automatically be sent. The CHIOCREJECT ioctl should be used to send a CLS packet containing a specific reason.

12.5 TTY Mode Connections ¶

TTY mode (via CHTTY) connections allow the connection to act exactly as a UNIX tty, allowing, for example, remote login service with no extra process for the NVT. Unfortunately, none of the remote protocols (TELNET, SUPDUP) can work over a transparent connection that just acts like a terminal. This mode is currently unused.

12.6 Foreign Protocol Mode ¶

Used for a connection to transmit and receive foreign protocols encapsulated in UNC packets. (unimplemented)

12.7 IOCTL System Call Commands ¶

The following ioctl codes can be used on Chaosnet connections.

CHIOCSMODE

Set the connection mode. Argument is CHSTREAM, CHRECORD, CHTTY, or CHFOREIGN.

CHIOCSWAIT

Wait until the connection state changes from the given state (in the third argument). Typically used for listeners waiting for a RFC:

ioctl(fd, CHIOCSWAIT, CSLISTEN);

or for a user end waiting for a respone to a RFC:

ioctl(fd, CHIOCSWAIT, CSRFCSENT);

CHIOCFLUSH

In stream mode, send out any data waiting for a full packet. This is done every 1/2 second at clock level anyway.

CHIOCOWAIT

Wait for all transmitted data (after doing a CHIOCFLUSH) to be acknowledged by the other end of the connection. If the argument is non-zero, an EOF packet is sent first, and then it must be acknowledged also.

CHIOCGSTAT

Get the status of the connection. The argument is the address where the status structure (struct chst in <chaos/user.h>) will be returned. This is frequently used to ascertain the state of the connection after a CHIOCSWAIT call, or to find out the Chaosnet address of the other end.

CHIOCANSWER

When a connection is in the CSRFCRCVD state, this causes data writes on the connection to be sent using an ANS packet. In stream mode, the packet is filled incrementally. In record mode the first packet sent is made into an ANS. In every case only one packet is sent and the connection is made closed.

CHIOCACCEPT

When a connection is in the CSRFCRCVD state, this causes an OPEN packet to be sent and the connection opened.

CHIOCREJECT

When the connection is in either the CSRFCRCVD or CSOPEN state this causes a CLS packet to be sent, closing the connection. The argument is the address of a null-terminated string which is copied into the close packet.

CHIOCPREAD

Read a packet from the received packet queue. Used in stream mode to read control packets that are otherwise ignored. Typically used to read RFC or CLS packets.

CHIOCRSKIP

Skip over the unmatched RFC at the head of the unmatched RFC queue and mark it to only be matched against a listen, not queued as an unmatched RFC. This is used by the unmatched RFC server to ignore RFC’s it knows someone else might want.

FIONREAD

A normal UNIX ioctl, this returns an integer at the address specified by the argument, containing the number of byes available to be read.

12.8 Signals ¶

All read, write, open, close, and ioctl’s are interruptable except when waiting for buffer allocation. Read and write calls are automatically restarted (on VAX UNIX). All others currently return EINTR errors.

12.9 Software Installation ¶

Global header files are placed in a "chaos" subdirectory of the system header file directory (usually /usr/include) so that #include <chaos/foo.h> works.

The kernel code is found in two subdirectories of the kernel source directory, parallel to sys, dev, and conf:

chncp

This directory contains the parts of the NCP which do not depend on the operating system. It also contains the actual Chaosnet interface drivers - which do have some operating-system-dependent code. These drivers interface only to the Chaosnet code (except interrupt vectors) and thus are not usable as UNIX device drivers (this may change).

chunix

This directory contains the top level device driver interface from the system call level (through cdevsw) to the NCP and some system dependent utilities (buffer allocation etc.)

The NCP needs two entries in the character device switch and one other small change in conf.c.

In the UNIX kernel proper several small changes are required:

nami.c

A small (2 line) change is required to nami to allow Chaosnet special files to have additional pathname components after the one that matches the special file in the file system.

clock.c

A call to the Chaosnet clock process routine must be placed in the clock routine called every clock tick (this should be done with timeouts but isn’t).

fio.c

Several bugs in closef which never were encountered by other drivers need fixing.

All these changes are conditioned on #ifdef CHAOS. In the normal (Berkeley) VAX configuration scheme, normal entries made in the configuration file suffice to cause all the right files to be included in the system if the line

is specified and the CHAOS option is included in the "options" line. The "files" file gets a few more lines.

For pdp11 UNIX, since the configuration system is much more primitive, some handwork is usually required to make the kernel correctly.

All user program sources can be put in /usr/src/cmd/chaos, /usr/local/src/cmd/chaos, /usr/src/local/cmd/chaos. The make file contains variables for destinations of all programs. The default destination for user programs is /usr/local. Server programs are placed in /usr/local/lib/chaos. The unmatched RFC server ("chserver") is placed in /etc and should be started in the /etc/rc file at boot time. It may be killed and restarted at any time.