65
AD-7A04 02 "ASAHUSETTS INST OF TECH CAMBRIDGE ARTIFICIAL INTE--ETC F/S, 9/'2 UC JUN 81 D A MOON NOO14-80-C-0505 W4CLASSIF lED AI-M628 ML mEmmhmhEmhhhEEE EohhohmhEEEEEE

ASAHUSETTS TECH CAMBRIDGE ARTIFICIAL F/S, UC · PDF fileboth the hardware and software protocols. It is intended to be the definitive documentation for Chaosne~ 1 9 11 3~ I ~ '7 1

Embed Size (px)

Citation preview

Page 1: ASAHUSETTS TECH CAMBRIDGE ARTIFICIAL F/S, UC · PDF fileboth the hardware and software protocols. It is intended to be the definitive documentation for Chaosne~ 1 9 11 3~ I ~ '7 1

AD-7A04 02 "ASAHUSETTS INST OF TECH CAMBRIDGE ARTIFICIAL INTE--ETC F/S, 9/'2

UC JUN 81 D A MOON NOO14-80-C-0505

W4CLASSIF lED AI-M628 MLmEmmhmhEmhhhEEEEohhohmhEEEEEE

Page 2: ASAHUSETTS TECH CAMBRIDGE ARTIFICIAL F/S, UC · PDF fileboth the hardware and software protocols. It is intended to be the definitive documentation for Chaosne~ 1 9 11 3~ I ~ '7 1

UNCLASSIFIED IL E t' <SECURITY CLASSIFICATION4 OF THIS PAGE (Whaen D.t. Entered)

REPORT DOCUMENTATION PAGE READ INSTRUCTIONSBEFORE COMPLETING FORM

1. REORT NMBER 2. GOVT ACCESSION NO. 3. RECIPIEN4TS CATALOG 14UMIER

4.- T IT LE (and SubtoitI.) S. TYPE OF REPORT & PERIOD COVERED

~hi 6 Caosnt / Memorandum

6. PERFORMING OR1G. RIEPORT NUMBER

7. AUTOR~s) . CONTRACT OR GRANT NUMB ERfp)!

I / N00014-80-C-0505 ibl/

Z DvidA. MoonS ~ ai 10FRt~RAIATN AEADADESt. PROGRAM ELEMENT. PROJEC T. TASK

Artificial Irtelligence Laboratory. -AE OEUI UBR

54.5 Technology Square

Carbridge-r Massachusetts 02139

N TRLL F~C~N AME AND AD DRESS

Aavanc.ed Research Projects Agency ( 1 June,1481

!L0 wis iBvd 13I. NUMBER OF PAGES

Arlns-=,Virciria 22209 6

*a % rRr* AG~mCY NAME A AOORESS(If different from, Controlling Office) 15. SECURITY CLASS. (of I)%#* FOPONTi

- . 1f i e of Na"ai Research,,," - ~ j . UNCLASSIFIED

s orrrltion Systems -

AIinqton, Vir-ginia 22217 I3a. DECLASSIFICATION/DOWNGRAOING

1-4 ZiS 1O ,TF ST A7ThENT (of this Report) w

iDistribtrticn cfthis document is unlimited. D T iCSEP 1 0 19 81

17. 01STRItVTt*W S7ATENOENT (of the abstract entered In Block 20. It different froet Re"

[IS S JPPLEMDTA-1I NOTES

19. -KEY wWR.- (Cowtambw.n reverse side it necee~ mia ad Identify by block nmber)

Local Network* C.) System.

_.j~ftown20.' ABSTRACT (Confntwes an reverse old# it necessary mid Idefft~tY by block number)LA. Chaosnet is a local network, that is, a system for communication among a group

r of computers located within about 1000 meters of each other. Originallydeveloped by the Artificial Intelligence Laboratory as the internalcommni-eatiofls-medium of the Lisp Machine system, it has since come to be usedto link a variety o~f machines around MIT and el's~'her6. This memo describesboth the hardware and software protocols. It is intended to be thedefinitive documentation for Chaosne~ 1 9 11 3~

I ~ '7 1 96I85LT Sh0W 0ea~

Page 3: ASAHUSETTS TECH CAMBRIDGE ARTIFICIAL F/S, UC · PDF fileboth the hardware and software protocols. It is intended to be the definitive documentation for Chaosne~ 1 9 11 3~ I ~ '7 1

7 7.

MASSACHUSETTS INSTITUTE OF TECHNOLOGYARTIFICIAL INTELLIGENCE LABORATORY

A.I. Memo No. 628 June, 1981

Accession For

fNTIS GRA&IChaosnet DTIC TABUnannounced

Justification

* By.

David A. Moon Distrit i --

Dist \ 1 c

Abstract

Chaosnet is a local network, that is, a system for communication imong ,a group ofcomputers located within about 1000 eeers of each other. Originally LIOVCIOPCI by the ArtificialIntciligenec l.aboratory as ie internal commiunicalions medium of tho .isp NiIachilc Systen, ithas since come to be uscd to link a variety of' machines acound MI'T and elsewhere.

'rhis memo describes both the hardware and the software protocols. It is ii:t.'ndud to he thcdefinitive documentation For Chaosnet.

lii.; rcport r-dc ii w:; rc,,c: rcl done it ii' \lAiti ficilI Intellio,,n, c IL lboratorv of ' i 1 NI a hiv setishusttilutc of 'l', h l,4'y. Stinport fm Ih,: I ihoro'.n'lr alttilh',l vlllpI1ii1iwe f ksc mihh i' po oided in

A 1. p rt by (lit, *\4l\ ' c..d .1, ' c'aiclh PIlojekt \ i,, cy o t h Iw" ofI ti:,,,t 1,k I )cl1foe,-dmlr OIci¢' of. I';av,,[ :. ,' t C0m l'ttt 1k (il 0 , bV-(51 S

Page 4: ASAHUSETTS TECH CAMBRIDGE ARTIFICIAL F/S, UC · PDF fileboth the hardware and software protocols. It is intended to be the definitive documentation for Chaosne~ 1 9 11 3~ I ~ '7 1

Chaosnet 1 able (11 Contents

9 Table of Contents

1. Introduction . . . .

2. Hardware Protocol ..................................... ... 3

2.1 T hie I-ther . . . ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2.2 Packets ... ... .. ..... . . . . .... . . . . ...... . . . . .. .. 3

2.3 Ibe Transceiver ... ... ...... .......... .... .... .........1 42.4 11~e Interface .. .. .. .. .. .. .. . .. . .. . .. .. . .. . .. . .. . .. . .. ... 42.5 H~ardwaire Protocols .. .. .. .. .. .. .. . .. . .. .. . .. . .. . .. . .. .. . ...2.6 E-thcr Con tcntion. .. .. .. .. .. .. . .. . .. .. . .. . .. . .. . .. .. . .. . .. 6

3. Software Protocol-World View.... .. .. .. .. .. .. .. .. .. .. .. .. .......3.1 Connections. .. .. .. .. .. . .. .. . .. . .. . .. . .. .. . .. . .. . .. . .... 93.2 Contact Names. .. .. .. .. .. .. ... ... ... .. ... ... ... ... ... ... 93.3 Addresses and Indices................... .. ... .. 103.4 Packet Numbers.................... .. .. ........ . . .... . ..... . . ... ,,113.5 Packets. .. .. .. .. .. .. . .. .. . .. . .. . .. . .. .. . .. . .. . ... .. .123.6 D~ata Formats. .. .. .. .. .. .. .. . .. . .. . .. . .. .. . .. . .. . .. . .. .13

3.8 Hlow and E'rror Control .. .. .. .. .. .. .. . .. . .. .. . .. . .. . .. . .. .... 16

4.SotwreProtocol-De)tails. .. .. .. .. .. .. . .. . .. . .. . .. .. . ... . .. 041Connection Establishment .. .. .. .. .. .. . .. . .. . .. . .. .. . .. . .. . .. 0

4.4 Fnd-oC-[)ata .. .. .. .. .. .. . .. . .. . .. .. . .. . .. . .. . .. .. . .. . .. 244.5 1.ow-level. .. .. .. .. .. . .. . .. . .. . .. .. . .. . .. . .. .. . .. . .. . 254.6 Connection States. .. .. .. . .. . .. . .. . . .. . .. . .. . . .. . .. . .. . .. 25

5. Hligher-I eve! P~rotocols. .. .. .. .. . .. . .. . . .. . .. . .. . . .. . .. . . .. .. 275.1 Status .. .. .. .. . .. . .. . . .. . .. . . .. . .. . .. . . .. . .. . .. . . ... 275.2 Putlsar .. .. .. .. . .. . .. . . .. . .. . .. . . .. . .. . .. . . .. . .. . . ... 28

5.3 Tednet and Siipdup. .. .. .. .. .. . . .. . .. . . .. . .. . .. . . .. . .. . . ... 285.4 Fie Acccs .. .. .. .. .. .. .. . . .. . .. . .. . . .. . .. . .. . . .. . .. . ... 29

5.7 NameC.. .. .. .. .. . .. .. . .. . .. . .. . .. .. . .. . .. . .. . .. .. . .30

S9~ \Ipaitict (',lteway. .. .. .. .. . .. . .. .. . .. . .. . .. . .. .. . . . .. ... 30)i M llloer.......................... . . ... .... ...... 31

7. 1 hidwg 1 I o ilikolI 'ii 11('111osn t . ... .. .. .. .. .. .. .. .. .. .. .. .. . .... J

H. I lie I I S Mmll i i . ... .. .. . .. . .. .. . .. . .. . .. .. . .. . .. . .. ....

8.1.3 lomis ILS........................ . ... ......... 38

Page 5: ASAHUSETTS TECH CAMBRIDGE ARTIFICIAL F/S, UC · PDF fileboth the hardware and software protocols. It is intended to be the definitive documentation for Chaosne~ 1 9 11 3~ I ~ '7 1

TFable of Contents ii Chaosnct

8.1.4 Miscellaneous Operations .. .. .. .. .. .. .. .. .. . .. .. . .. .. . .. ... 398.2 Utility Programs. .. .. .. .. .. . .. .. . .. . .. . .. . .. .. . .. . .. . ... 408.3 Servcr Programs. .. .. .. .. .. .. .. .. ... .. ... .. ... .. .. ... ... 428.4 Subroutine Packages. .. .. .. .. .. .. .. .. ... .. .. ... .. ... .. ..... 42

9. The 1OPIS-20ITNEX Implementation. .. .. .. .. .. .. .. .. .. ... .. ... .... 439.1 Opening Connections .. .. .. .. .. .. .. . .. .. . .. . .. . .. . .. .. . .... 439.2 Stream Input and Output .. .. .. .. .. .. .. . .. . .. . .. . .. .. . .. . .. .. 449.3 Packet Input and Output .. .. .. .. .. .. . .. . .. .. . .. . .. . .. . .. .... 449.4 Special Operations .. .. .. .. .. .. . .. . .. .. . .. . .. . .. . .. . .. .... 449.5 Utility Programs. .. .. .. .. .. . .. .. . .. . .. . .. .. . .. . .. . .. . ... 459.6 Server Programs. .. .. .. .. .. . .. .. . .. . .. . .. . .. .. . .. . .. . ... 46

10. T'hc Lisp Machine Implementation. .. .. .. .. .. .. .. .. .. .. ... .. ... ... 47*10.1 Op-ening and Closing Connections . .... .. .. .. .. .. .. .. . .. . .. . .. . ... 47

10.1.1 User-Side. .. .. .. .. .. .. .. . .. . .. .. . .. . .. . .. . .. . .. .... 4710.1.2 Scrvcr-Side .. .. .. .. .. .. .. . .. .. . .. . .. . .. . .. . .. .. . .... 48

10.2 Connection States .. .. .. .. .. .. .. . .. . .. . .. . .. .. . .. . .. . .. .. 4310.3 Stream Input and Output. .. .. .. .. .. . .. .. . .. . .. . .. . .. . .. .... 4910.4 Picket Input and Output. .. .. .. .. .. .. .. . .. . .. .. . .. . .. . .. . ... 4910.5 Connection Interrupts. .. .. .. .. .. .. . .. .. . .. . .. . .. . .. .. . .... 5110.6 Information and Control .. .. .. .. .. .. .. . .. .. . .. . .. . .. . .. . .. .. 51

11. Thc VAX/VMS Implementation .. .I. .. .. .. .. ... .. ... ... ... ... .. .. 5311.1 Opening and Closing .. .. .. .. .. .. .. .. . .. . .. . .. .. . .. . .. . .. .. 5311.2 Stream Input and Output. .. .. .. .. .. . .. .. . .. . .. . .. . .. .. . .... 5411.3 Packct Input and Output. .. .. .. .. .. .. .. . .. . .. .. . .. . .. . .. . ... 5411.4 Checking the State. .. .. .. .. .. .. .. . .. . .. . .. .. . .. . .. . .. . ... 55

12. '[hec Unix Implementation . ..... .. .. .. .. .. .. . .. . .. . .. . .. .. . .... 57

References .. .. .. .. .. .. .. . .. .. . .. . .. . .. . .. .. . .. . .. . .. . ... 59

Page 6: ASAHUSETTS TECH CAMBRIDGE ARTIFICIAL F/S, UC · PDF fileboth the hardware and software protocols. It is intended to be the definitive documentation for Chaosne~ 1 9 11 3~ I ~ '7 1

Chaosnet IIn tioduct ion

1. IntroductionCharosnet is it local network, that is, at sysCtem filr cornrrran11iCati0tr ii in 011 ; ?i)I Of

computers located within one or two kilometers of' each other, 'I lie name ( lraosiet relcrs to thlelack of' any centralized control element in this network.

Chaosnct wits originally developed in 1975 by the Artificial I ntclligcnce I .roratory of theMlassachuIscirS Institute Of T*chnllology ats thle interl-11 conitniciltioaS :ncdI11,11 Of thC ILisp Machinesystem CI II NUA I , A I N4441. It has since conme to be USed to link a sam olet machines aroundthc Institute. Chaosncets also exist at several other universities and research labormrories.

IThe ILisp Machine system is a 11ult1i-processor in which cach active uiser is assigned a"personal" comnputer consisting of at mediumi-scale processor, a stri(AI M1be111 aOf'r t at ii O tr, and atswapping disk. [:ies are stored in a centralI file-syStem~ alccessed thr1oughI Chat sItCt. hiis sharedfile-systemn rectains thfe traditional advantages of at time-sharing Systerr. lin el, inter-uisercommunication, shared programs, and centralizcd backup and minn mcIc. At the s11ie timne, by

givig ech ctie mserhis own processor, the L isp Machine system is match mor o ip. hie thaitime-sharing systemi at executing ILisp programs semical million ss ords iii size Aicic et and withrapid interactive response. Bfecatise Chaiosnet is taking the place tif the file disk in a con ventionalsystemn, it ius be fast (both in response and in throirghpnt), it must I), cliihl de fb is thereason why there is no centralized control), and it maLSt allow Can iorl (it' se'~ cr1 dozenumachines. H owever. it dues not need to operate over long distances. tibet snet is iited to acccssother shared resouices in addition to the file systemll these ichlude prii tei s. tafh dmci \ s.iid one-ot-a-kind specialized processors and 1/O devices.

T[he system goals fur Chaosnlet were primarily simplicity and hi ii., perti-rnirce. Theperformance is atchievied by starting with a very high speed transmrissioii nedm am id operating itin at simple, low-overhecad faishion, rather ihanl by tisiirg urIrSMially clever- Jilnu0i this. Of' coarseoiie has to be carefutl tor avotid algorithms which atre so simple tha they donrt %%i k iii sotC5muILch of thfe trailsitission medium that p~erformnce is irrpacied. SimplicitN ~i inipo tint notonly to inmprove performiance, but because (liaosnet connects a diverse swt Of ilk hiines, aridhence had to have sescral implemnentations all of which require Ittl ite]t rtrc in) par ioi tia to theirCurmiplIexi ty.

Siniplicity of design also aids greatly in maintenance and immcntgirreit at' hei a' 0,u rk itself.which has proven to be at norvtrivial task in at network iriolvirig a i,trim' of 1)iilite n1id Ilsed

by at sriety of' group[s, esen within thle singile irstitutlioir of' klItI. It i , *1rpoil.11)1 to lbe abhle toisolate anI applreit brlillirie riP the Whole nietork to the cuIc or to ;I palto111 a ita I's h~ts OrrSoftware 11ts rapidly as, p~oss.il)le.

Alk. des irir (tf C 'itasnlet Wars greaitly Silirplilied by ignloring! p olits. atde ilt-.II to Iilliret%.smks. ('h it sut mumuairis no speciall pr'is sums for Ilirtys Mmli 'I" his specd ink, iti (\cryhielh rror-it) links, iiiple paths, auld longd(istaolinhiks i.sitht sal;l ( .11 111it litr. 't hisfilm is that ( littisire-t is, 10 11imit1L11 p ric~Ilv iidile I n rIse W iC ros t' iat IO I O ihilt-'ii (Ii Ini sie

ppI I:it )wii. ( hrIu''. I I ls nuakkeSD0 no Itteuip to) pMit I~~ uc i I i' 'ti' I' I I) iiittic(.5 1 1,m 'Cusim 1' 'r I IIi. mtuIui titi'14,tlimir tltlit thi I)Y irtil (11 inl mi d h t

Page 7: ASAHUSETTS TECH CAMBRIDGE ARTIFICIAL F/S, UC · PDF fileboth the hardware and software protocols. It is intended to be the definitive documentation for Chaosne~ 1 9 11 3~ I ~ '7 1

Introduction 2 Chaosnct

Chaosnet was largely inspir ed by the pioneering work on local networks at Xerox PARCIFrMHHRN K 1.

Chaosnet consists of two parts-the hardware and the software-which. while logicallyseparable, were designed for each other. 'he hardware provides a carricr-sense multiple-accessstructure very similar to the PARC Elhernet. Network nodes contend for access to a cable, orether, ovcr which they may transmit packets addressed to other network nodes. The softwaredefines higher-level protocols in terms of packets. TheIise protocols can be (and arc) used withmedia other than the Chaosnet cable, and with multiple interconnected cables. The softwarecontains ideas borrowed from Ethernet [ErIHERNI-1I, 'rcp rrcpi. and Arpanet, with someoriginal ideas and modifications.

I )SK:NI( t)N:Aht 111R 107 -iN8

Page 8: ASAHUSETTS TECH CAMBRIDGE ARTIFICIAL F/S, UC · PDF fileboth the hardware and software protocols. It is intended to be the definitive documentation for Chaosne~ 1 9 11 3~ I ~ '7 1

Chaosnet 3 1I ld~arC Protocol

2. Hrdware Protocol

2.1 The Ether

The transmission medium of Chaosnet is called the e~ter. Physically it is a coaxial cable, ofthc scmi-rigid 1/2 inch low-loss typc used for cable TIV, with 75-ohm termination at both cnds.At each network node a cableic Insceirer is attached to the cable. A 10-meter Itit cable connectsthe transceiver to an iiiielfice which is attached to a computer'CS 1/0 buIs. A nomvork nodeconsists of this transceiver and interface and a computer which executes a Certain piece of, softwarecalled the Network Control Program (NCII), which manages and controls (Thaosniet, int addition towhatever 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 allother nodes: each node decidcs in hardware whether to ignore the packet or to receive it. Asingle ether must be a linear cable; it may not contain branchcs nor stubs, and the ends may notbe joined into a circle. The maximum lengthr of an ether cable is abotit I kilometer. This isdetermined by dispersion and by DC attenuation. The maximum nomber of nodes onl a singleether is probably a few dozen. This is determined by degradation of the electrical properties ofthe cable by the connectors used to attach the transceivers.

1'he maxitnum length of an ether could be increased by using repeaters (bidirectional digitalamplifiers joining two pieces of cable), In practice this is not done. Instead, thle protocolprovides for multiple ethers, joined together by nodes called bridges which relay packets from oneether to another. A bridge is typically a pdpl I comnputer with two or more network interfacesattached to it. A bridge node u1sually performs other tasks as well, Such as iitoftfacing terminals.Biridges attach other network media as well as ethers; some compttters connect to the networkthrough their manu facttirer's high speed comnputer-to-computer interface to a necarby briidge, ratherthan being interfaced directly to anl ether. Asynchronous lintes have also beett u~cd as Chaosnctmedia.

[he form of information on the ether, the transceiver atid interface hardware, and theprotocols which control who may seize thle ether arc described in the fiollowing sections.

2.2 Packets

Thebasc uit f tansmnission is called a packet. This is a seql1enCe Of Up ito 412 data bits,plus1 48 bits of hecader inforumation used h thie hatdwire. Packets' arit, no Auy !!j(ped intoW6hit words. 'lIe division of'a transniticd hit streanm into packet rvie co vettientlv-sized

uni fo IVMn~ Z1100011and error control. T[he job of thw litatdware is to dolivcr a packet

services (I mit i simple t ra usi.V, in o f pat ets I on one cou0te r to at u t her.

T Ihe ha r 1w ti hea de r con sists of t Iirct 16- bit words, called 4 '.stintii, 01. rcHc, itid check.ile S01irLC itlutu1lics thle node NNlikh tratnstnittcd this picket onto this cither This is not

neCCCyi;N 111Cb ot itl11 *olilrc of' the it.w sinJce it v b11, or' liJtutte(d nii difficti ter.'lw Ie tlctioni ldtititik 1iw tiodc \hi, Il ik itetild to tcccikv 111i'" picet il O!ilie. ~is titil i111tlvtC finil d-'tuat ott of' Ole ,".w;it n;iv lie ,t hrids'c Mii1 bllmild .'Iliy the

D)*K:k1( i)N:A\lIlP:I 107 15 JUl.N-81

Page 9: ASAHUSETTS TECH CAMBRIDGE ARTIFICIAL F/S, UC · PDF fileboth the hardware and software protocols. It is intended to be the definitive documentation for Chaosne~ 1 9 11 3~ I ~ '7 1

The Transceiver 4 Chaosnet

packet to another ether, whence it will eventually reach its final destination. 'lhe check word is acyclic redundancy checksum, generated and checked by hardware, which detects errors intransmission through the ether, entirely-spurious packets created by noise on the cable, andmemory errors in tie transmitting and receiving packet buffers.

The software protocol is also based on packets, taking 128 of the data bits as a softwareheader. This is described in section 3.5, page 12.

2.3 The TransceiverEveryone 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 identicaltransceivers (the interface varies depending on what computer it is designed to interface to). Thetransceiver contains the analog portion of the interface logic, provides ground isolation betweenthe ether cable and the computer, and contains some protective circuitry designed to prevent amalfuinctioning program or interface from continuously jamming the ether. (If it were to beredesigned, it ought to contain even more protective circuitry, since there are some possibleinterface failures that can get past the protection and render the ether unusable.)

The transceiver receives a differential digital signal from the computer interface and impressesit onto the cable as a level of about 8 volts for a 1, or 0 volts (open circuit) for a 0, through avery fast VMOS power FFT. When the cable is idle it is held at 0 volts by the terminations.ilis simple-minded unipolar scheme is adequate for the medium cable lengths and transmissionspeeds we are using. The transceiver monitors the cable by comparing it against a referencevoltage, 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 ofcontinuous l's from the interface, which should light all the lights (dimly) if the transceiver isworking. These indicators and the test button are useful for rapidly tracking down networkproblems. The transceiver requires its own power supply mounted nearby; one power supply canservice three transceivers if they are all adjacent. Hligh-voltage isolation between the cable and thecomputer is provided by optical isolators within the transceiver.

2.4 The Interface

The interface is typically a wire-wrap board containing about 120 TI. logic chips, whichplugs into the I/O bus of a c( niputer and connects it to the ether (through a tianscciver.) Theinicri ace inplements Ohe hardwarc lIlut)K'tls described in the ncxl section, hullers incoming andoutgoing )iAkcts, gecralet, alnd checks checksums, and interrupts the host coimputer when apacket is 1o be re;ad otit of the rcceive packet buffer or stored into the transmit packet buffer.'hcsc pakct hullfirs shicd the host computer from the high speed of data trausm ission on thecable. hI icid of ha ing to produce bits at a high rate. the host can prodtce thenm at a lowerrate, collect them into a packet, and then tell the interface to transmit the packet in a singlebulrst of hitch-sp(ecd trowsmr.,ion.

I ~ : ()t, ,, IIR 107 is -,IUIN-81

Page 10: ASAHUSETTS TECH CAMBRIDGE ARTIFICIAL F/S, UC · PDF fileboth the hardware and software protocols. It is intended to be the definitive documentation for Chaosne~ 1 9 11 3~ I ~ '7 1

Chaosnet I lardware Protocols

Interfaces currently exist for Lisp machines, for DEC LSI-ll1 micro-computers, and for theDFC Unibus [UNIBUS], which allows Chaosnet to be attached to pdpll's, VAX's, and theperipheral processors of most pdplO's. Programming documentation for this compatible f'amily ofinterfaces appears later in this paper.

Interfaces for other computers are likely to exist in the ftuture. The existing interface designdoes not make any unusual special demands of its host computer and should be easiiy adaptableto other architectures.

2.5 Hardware Protocols

The purpose of these protocols is to deliver packets intact from one node to another node onthe same ether, with fairly high probability of success, and to guarantee to give an errorindication or lose the packet entirely if it is not delivered intact. An additional purpose is toprovide 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 Biphasc NRZI.Each bit cell, which is approximately 250 nanoseconds long, begins with a tratnsition in state,from high to low or from low to high. This transition marks the beginning of a bit cell andprovides self-clocking. 3/4 of the way through the bit cell, the state of the cable is sampled;high represents a I and low represents a 0. If the bit being represented is the same as theprevious bit, there will be one transition at the beginning of the bit cell and a second in themiddle of the bit cell. If the bit being represented is the opposite of the previous bit, there willbe no transition in de middle of the bit cell since the clock transition will have set the cable tothe desired state. The AC frequency of the signal on the cable varies between 1/2 the bit rateand 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 propagationspeed. However, since the 3/4 of a bit cell delay is a fixed delay, only modest 'ariations inspeed can be tolerated. A crystal clock is used ais the source of the transmit timing in theinterface.

Since there is always at least one state-transition per bit cell, the stites where the etherremains high or low for an appreciable time are available for non-data uses. If the ether remainslow for more than ahout two bit cells, it is considered to be not-busy. 'Ihis condition marks theend of a packet and allows someone else to transmit. Note that it' no transceivers are ictive, theterminations will hold the ether low.

If the ether remais high for about two bit cells, this is an "abort signal". Abort signals areused for two purposes. If the transceiver detects a collision (two nodeIs trying to tratnismit at thesame time), each transmitting inteiface ccacs to transmit and scnds an abort sigiml 'tour bit cellslong), which tells ;ill ieceivers to ignorc the aborted packet and en.mies that the ulhci tionsmitter;Ilso ahbolts. Thus whcn i collision oceliS, the ether is clearol ,, s Mon a:, p(i,,ible to help l)icventfilly, tie-1 ,, Ittidet'f c, lidrins of heavy lotl. 'I lhe oll rt' 1se fin, h aborl signal is in t hlrdwar¢Ilow-COot1od1, When A tCeti~illg intrkiix dekc'rins thdti an io imiii, pLkc't ik ,dhi .I,,d to it,

hit its recive butler idlreniv rontains a p1lcket. it scildmII ;aaolit S lIl whi, c tuse, theStr, un n Iitter Io ',(op. lIhis 'rv', the dill 1i111t4 j k ot inni 'li tcl\ inIiif ilm, tie llC i 1hat itsDIulS'iC di 1( i ilt get thinlu d,, hd i e ('il. [romi bollig lied iII hlli,: I 'ili,. p.ickt is

tranluittcd hid the IrCci\r clllot Ircie.

I )SIK:l(.1 )N:,\I IR 107 15 JUN .81

Page 11: ASAHUSETTS TECH CAMBRIDGE ARTIFICIAL F/S, UC · PDF fileboth the hardware and software protocols. It is intended to be the definitive documentation for Chaosne~ 1 9 11 3~ I ~ '7 1

Ether Contention 6 Chaosnet

Packets are transmitted over the ether in reverse bit-order, for hardware convenience. Thethree header words, which to the software appear to be at the end of the packet, are transmittedfirst, in the order check, source, destination. The data words, in reverse order, follow. Wordsare transmitted least-significant bit first. Of course, the software need not be aware of thisreversal; 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 sothat an extra spurious clock-transition will not be generated when it goes idle. This bit is strippedoff by the interface and is never seen by software.

The check word is used for error detection, as described above. The source word is madeavailable to the software, which ignores it in most cases, and also serves to synchronize the clocksin the collision-avoidance mechanism which is described below. The destination word is comparedby each receiver against its own address. If they match, or if the destination is zero, or if thesoftware selects the "match any destination" mode, die packet is placed in the receive packetbuffer 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 thepacket 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. 1lhe time when it seizes dhe ether isdetermined only by state inside that particular interface and by the local state of the cable at thepoint where that interface's transceiver is attached.

If two interfaces should decide to seize the ether and transmit at the same time, theirtransmissions will interfere and no useful information will be transmitted. This is called a

collision. Collisions arc the principal limitation on the bmdwidth of a heavily-loaded ether-typenetwork, and should be avoided. (However, neither PARC's network nor MIl's network has-yetbeen operated with a heavy enough load to make collisions really significant.)

Chaosnet uses a novel collision avoidance technique. First of all, an interface will neverinitiate transmission unless the ether is seen to he not busy, i.e. it has been in the low state forsome time. This ensures that collisions can only occur near the beginning of a packet. Oncetransmission of a packet has gotten well started, the ether is effectively "seized" (all interfacesrealize that it is busy) and transmission will continue successfully through to the end of thepacket. '1 he amount of cther transmission tirne wasted by a collided packet is therefore limited tothe round-trip cable propagation delay. This technique is Uilled carrier sense.

Sccondl, the hardware uses a time-di vision techniquic to attemnpt to pIrercut tvo inteffacestfiliun illitiating timisnlis-sio'i ,it the sallC time. This technique should plu.c .111 ('sc'itiaily allcollisions %%hilc imposing only a modest delay in the initiation of' tra imuuision. It ik dc\igned sothat it W%%oiks heuer as hlie load l ihe cther illcreases: the wasted Lilie' bcl,t cc Imckets and therlative ilte of collisions both deLlease.

I'he hisic idea is that c h interface is ;issigned a tilot, or moin, ,icordii. to its address.It nriuy oulI illitiat" th;1W'.1,'lSsion diiill ' it' tolnll. Ill,, I11lr: ate ' , , cd I IJ l. ,htlo l a,1 1 I l t t if'mnue iIit.'rl't. i11lt "r. tII.ii'1 lli"il Ili. ("'xi othl intll &Y k 'k ill IWRT 1i\ t' thu 11" ''uL'i h iy IV, the

till1t ' it in'i1 Ilhu ll lliIv(."' ,i1l \111 il o u iiitilt' Ill ilitci l'iIl: tlIaulli ,1,i iu I'.t1 iuit,'l tud't C0uutuills

a, tu1eI-lot totall01111 tolunit' ( hilt' tlh0 ! 1 thcW is iot k001 , k.'p t trck noc \SlIos, turn it is.

I :., . iM,)t)N.\lM lI R 107 15 .IJN-81

Page 12: ASAHUSETTS TECH CAMBRIDGE ARTIFICIAL F/S, UC · PDF fileboth the hardware and software protocols. It is intended to be the definitive documentation for Chaosne~ 1 9 11 3~ I ~ '7 1

Chaosnet 7 I Krhcr Contcntion

Each packet synchronizes the counters in all of ie interfaces by setting them fll, the sourceaddress of that packet; at the time the packet was transmitted, it muSt ha'e iCe4i the turn of theinterface that transmitted it.

Another way to think of this is to make an analogy with ring networks. One can imagine avirtual token which passes down the cable until it gets to the end, then jumps to the beginning ofthe cable and repeats. An interface may only initiate transmission at the instant the token passesby it. When an interface transmits, the token stops moving and remains A that interfac, until theend of the packet, whereupon it continues down the cable, passing every other intcrface, givingthem each a chance to transmit bel'ore letting the first interface transmit a second packet.

The token is not represented by any physical transmission on the cable. h'lat would constitutea form of centralized control, and would lead to reliability problems if the tokcun ,as lost orduplicated. Instead, every interface contains a time-slot counter which keeps track of %Oierc thetoken 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 thefirst successful transmission will resynchronize all counters. The basic mechanism of the ethernetwork with contention and collisions is known to work, and the collision-avoidance schcme is anadded-on optimization which improves performance without changing the basic mechanism.

There is a finite propagation delay time between interfaces, and this time is not smallcompared with the bit-rate of Chaosnct, nor when compared with the desirable length of a timeslot. This time consists of the delay in the cable, about 5 nanoseconds Per meter. and the delaythrough the two transceivers, about 220 nanoseconds. This propagation delay means that the time-slot counters in two different intcrfaces cannot be exactly synchronized, and that hen interface Ainitiates transmission interface B will not instantaneously see that the ether is busy. Specialrelativity tells us that in fact the concept "exactly synchronized" is meaningless. Since the twotime-slot counters are not in the sarne place, the only way we can compare them is to send amessage from one to the other, through the ether, containing the reading of the counter. But thismessage takes non-zero time to get there, so the counter-reading it contains is wrong by the timeit is compared against the other counter! We in fact do send messages containing counterreadings; the source address in a packet equals the reading of the time-slot couttnter in theinterface that sent it---at the time it was sent. Since the network nodes arc not il iclaiti o motion,we can measure the distance between them and use that infornation to improve theirsynchronization.

What we are trying to do is to )1re~cnt collisions. Tis iius th.t if' iiterlic A startstransmitting a packet in its turn, then by the time interface B think, that its ozi tan has arrived,it nlst perceive the ether as busy. We %ill assig,,n addresses (.i d lince inio' slots) mid set thelength of a time slot in such a way that this will hapl)C. Slllppnw' the illdJ\iiflt dcli'. thoughthe cther hctwen A ;11cl It is t. TlIIJ would be tie dlay fr ote of' thoii ,dtmti: a pi ckct tothe othcr: the dcl.' ht:evc A's receipt if a third party's pickct itd I" rcipt it h.t packet is

~~Ics' . C,pccr;lll, if' (lie third fla ty is I' 1vClw ,n !.\ Itl/tl It oil file cjIll,' henl [tic 1,,\m l CI'CCI\'ed

difllCretI1L hCl'. CCe , "lock It A antd a :loik ;it It is 2i : if a ISc ic s m It Itoles A'cii~ ftetu at sbtenAadIfo ~echt.Ihr h mim ecie

ss chrti'imil t Ic tlick,. imid hen ,I PItC,,dm.X iS SCIlt from A t' 1; L aIIIiman' \" e Jl" ,kiding, ,itIt thi'" rh, k IC. 1,1iii \%ill ho "low by . .

Il ,::,K(I0 0l ,1,\\,ll'l l: I(/ I", !IIN -81

Page 13: ASAHUSETTS TECH CAMBRIDGE ARTIFICIAL F/S, UC · PDF fileboth the hardware and software protocols. It is intended to be the definitive documentation for Chaosne~ 1 9 11 3~ I ~ '7 1

Ether Contention 8 Chaosnet

When a packet transmitted by A arrives at B, 11's clock may read as much as 2t earlier orlater than A's turn, depending on the transmission direction of the last synchronizing message. Inorder to guarantee that B's turn has not yet happened, the time between any of A's turns andany of 1B's turns must always be at least 21, twice the maximum propagation delay through theether between A and 11. This is the important idea! We cause this to be true by assigningaddresses starting at one end of the cable; each node's address is the previous node's address plustwice the propagation delay between them, divided by the length of a turn. It is easy to see thatif this is lone for all adjacent pairs, the condition will automatically be true for non-adjacentpairs as well. When we get to the end of the cable, we must assign a number of empty slotsequal to twice the propagation delay of the full length of cable, to provide the necessaryseparation between the turns of the two nodes at the ends of the cable.

'rhe virtual token travels through the network at a substantially slower speed than a real signalsuch as a packet; in the fastest case, when nodes are very far apart, it traels at just half thespeed of a real signal. Since a Chaosnct ether has the geometry of a line, as compared to thering net's circle, the virtual token is also slowed down by the need to return from the end of thecable to the beginning. Ibis slower speed of the token is the price one pays for the increasedrobustness of Chaosnet as compared with a ring network. In a real system, we slow the tokendown even more to provide a margin of safety. The speed of the network is not significantlyaffected by the slow token, since the interval between packet transmissi:)ns by a single node ismuch longer than the round-trip time of the token. Indeed, if the network is being usedprimarily for file transfer, and hence the packets are large, the transmission time alone for atypical packet is several times the round-trip time of the token. A typical value for the token'sround-trip time is 64 microseconds.

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

When a collision does occur, we recover from it (in software) by retransmitting the packetagain a couple of times, hoping that we will be lucky enough not to have another collision, orthat the recciver will soon clear its packet buffer. This retransmission is done by the software, notthe hardware, since the hardware destroys the packet in its packet buffer in the process oftr. nsmittin g it. Blnt if collisions continue to occur, we give ip and let somebody else have theether. 'lic packet is lost. A higher level of protocol %ill soo rca!ize that it has been lost andrcti-mismit it. We assume that there is enotigh raridomncss in the higher-level sofw tare that thet' nodes which originally collided will not collidc againi on the rctransmi:sitnon by deciding toretrmsmit at precisely the same instant.

I l,.Nl1 u )NAlIII 1,1111 15-iUN 81

Page 14: ASAHUSETTS TECH CAMBRIDGE ARTIFICIAL F/S, UC · PDF fileboth the hardware and software protocols. It is intended to be the definitive documentation for Chaosne~ 1 9 11 3~ I ~ '7 1

Chaosniet, 9 Software F'rotocl- World View

3. Software Protocol--World View

The purpose of* the basic software protocol of Chaosnct is to aillow high -speed commlhuicationlamong prooesses onl ditfercnt machines, with no undetected transmission errors. [he speed for file

transfers in real-life c ircumistances was to hC comparable with an inexpensive miagnetic tape drive

(30000 characters per second, or about 10 times the speed of the Arpanet). We aIctually get about

douible this in somec favorable cases. Tro achieve this spccd it wats important to design outhottlenecks Such ats are' found in thc Arpanct, for instnncc the control-link which is shared

betwecCn Multiple connectionls and the need to acknowledge each message bef'ore the next message

can be sent. The protocol must be simple, for the sake of reliability and to allow its use by

* modest computer systems. A full Chaosnet Network Control Program is just abhout half the size

of an Arpanet NCP on the same machine, and the protocol allows low-performianceimplementations to omit some features. A minimal iimplemientation exists for a single-chipmicrocomputer.

3.1 Connections

T1he principal service provided by Chaosnet is a conneclion between two user processes. Thisis a full-dupleax reliable packet- transm ission 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 ulser processes. User programs may either deal in terms of

packets, or ignore packet boundaries and treat the connection as two uni-directlonal sticiims of 8-bit or 16-bit bytes.

On top of the connection facility "user" programns build other facilities, such as file access,interactive terminal connections, and data in other byte sizes, such ats 36 bits. T he mecaning of

the packets or bytes transmitted through a connection is defined by the particular highier-level

protocol in use.

lin addition to reliable Communication, the protocol provides flow control, includes a way by

which prospective commuinicants may get in touch with each other (called contacting or

rendez'oiss), and~ provides various network maintenance and hlusekecping fa1-cilities. I hese are

discussed later.

3.2 C:ontact Names

When fir1st establishing a con nection, it is necessary for the I Nio Cuca111Ld ing processes to

contact each other. lIn addition, inl thlt usuall uiser/server Situaii on, the ser. er p oce,,S does nlot

ex\ist beforehiand and needis to be created and made to eXcute( thleaprratpwi.

We eho'.e to IIpIniA01i1 co1tactifig ill an asynirnlelii way. (O1ice thle coio lioon nas been

Csuhli shed O r~ tliiI1ug is 011i.CN nq1111C6 0et1C s ii ni.)OeprooCeSS is dc,,igiited fie 100, alld thle other

is desigilIatcd thet S.lvr. Ilie .,crver hats somie colitI noamie to .Mloli if 11wk oscok~ piocess

i0it' 1ts loa o111tii1s'tii o C CIoii it too tile sn e. spit 11il ii tile )i\\ito 00 LI ii1t 1 an

(olli(t oaio1 Mi t1e k.o' \ ci~c. The' l(otil s0peratiiig '. Iswli \Cii1(IS I iM-0' 1 (JI fi/" i )?-fo

( i' too tlln i iot opeto' ,\', i oi 'Ahikh Csiloioo. tillo colt'i t naili' .11 aiotl ioeots a

- -- co'iifi'I'CIII (() J hIICIIIo' I~It'. C .. ' 11O \k S' st Oci pHi)iQ( S ,iiiil eflhiiico.1 to it, oI wjo is the

I SK:\ttVAI 107 ],l1 1N-81

Page 15: ASAHUSETTS TECH CAMBRIDGE ARTIFICIAL F/S, UC · PDF fileboth the hardware and software protocols. It is intended to be the definitive documentation for Chaosne~ 1 9 11 3~ I ~ '7 1

Adessand Indices 10 C::osnc:

subject for higher-lcvel protocols and for further research. It is not dealt with by Chaosnct.

Once a connection has been estahlished. thcrc is no more rnced for thc coiiIact name and it isdiscardcd. Ideed, often the contact name is simply the niame of at service (such ias 'TELNE I")and several users should be able to have simultaneous connections to separate instanlces of thatservice, so contact names must bc reusable.

In thle casc where two existing processes that already know about each othecr want to estalisha connection, we arbitrarily designate one its the listener (server) and the othcr as thc reqticstcr(user). TIhe listener somehow generates a "unique" contact name, somehow communicates it tothe requester, and listens for it. Thec requester request% to connect to that contact name and theconnection is established. In the most common case of establishing a second connection betweentwo processes which are already connected, the index number (see below) of the first connectioncan serve as a unique contact name.

Contact names are restricted to strings of uipper-case letters, numbers, and ASCII punctuation.TC'tmaXimum length of a contact name is limited only by thle packet size, although on ITS hoststhe namnes o~f automatically-started server% are limited by the file-systemn to six characters.

See page 21 for complete details of how to establish a connection.

3.3 Addresses and Inidices

Fach nole (or host) onl the network is identified by an addlress, which is a 16-bit number.TIhese addresses are used in the routing of packets. lhere is a table (thle system hosts table,SYSB IN fIOSTS2, in thle case of IITS) which relates symmbolic host name11s to nuLmer'ic hostaddresses.

Ani address consists of two fields. The miost-significant 8 bits identify a subnct, and the least-significaint 8 hits identify a host within that SUhuet. Bioth fields must be non-zero. A suibnctcorresponds to a single transmission path. Some subnets are physical Chaosniet cables (ethers),White othiers arc other rne(Iia, for instance an interl",ice between aI 1dp 10 and a pdp 11. Thesignificance 01' Suhn~CtS will bcome clear when rouLtinlg is discuissed (see section 3.7, page 13).

Whcii a host is; cmiinected to) an ether, the host's hardwatre address onl that ether is tile sameiais its sidt'tkae address, incluldiog thle suhucet fieldl.

A I (itte(tioli is specified by dhe names of its two ends. Suich a laie Consists (of a 16-hit hostadiliess anlid ;I 1(4-1)1 colilcectinil illICN, v hich is ;IssiVI.'Ied h 1that host. IS thle 11,111C Of theC CIIityHPdeI tile HitY M111 liith 0iwl 0 teConu1CiLion. 'Ithe only re(ituir~elnielts place'( h\ Owi tilotitol (mniidice"~ te :,I'll tlic be nomi cro anld that they he un16illu %%(linl I aImtiitir1 int; thu.1 is, a hostIInty linlli t11ke sailic indexC ,nimnh11ei to two) Ililei''iit ( IlIlCLliMi'uiil cil441''hi litte h1is,ti I'l-kd cii~ ell [te elnaiit I', O l te luist eulilictiin mid( the 4ILlIIIfj 4A, tIlk' 1Il 4141 4 ilick-CtilI thatI

I t, 1 1-, 111 \I ~ t \ Il ic tIII, I llIO 1, t i" 1; l 1 1,11 , 1 1 1 ! - 1 I I, I t,

Page 16: ASAHUSETTS TECH CAMBRIDGE ARTIFICIAL F/S, UC · PDF fileboth the hardware and software protocols. It is intended to be the definitive documentation for Chaosne~ 1 9 11 3~ I ~ '7 1

Chaosnet 1 Packet Numbers

packet from the old connection cannot sit around in the network (e.g. in buffers inside hosts orbridges) long enough to be seen as belonging to the new connection.

It is important to note that packets are nol sent betv en hosts (physical computers). They aresent between user processes: more exactly, between channels attached to user processes. Eachchannel has a 32-bit identification, which is divided into subact, host, index, and uniquization

fields. From the point of a view of a user process using the network, the Network ControlProgram section of his host's operating system is part of the network, and the multiplexing and

denultiplexing it performs is no different from the routing performed by other parts of thenetwork. It makes no difference whether two communicating processes run in the same host or indifferent hosts.

Certain control packets, however, are sent between hosts rather than users. This is visible tousers 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 systemcould be built without first solving the research and engineering problems associated with makinga 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 section 3.8, page 16), which

guarantee that each controlled packet is delivered to its destination exactly once, that thecontrolled packets belonging to a single connection are delivered in the same order they were sent,and that a slow receiver is not overwhclmed with packets from a fist sender. Uncontrolledpackets are simply transmitted, they will usually but not always arrive at their destination exactlyonce. The protocol for using them must take this into account.

F~ach controlled packet is identified by an unsigned 16-bit packet number. Successive packetsare identified by sequential numbers, with wrap-around fiom all I's to all 0's. When a connectionis first opened, each end numbers its first controlled packet (RIVC or OPN) however it likes, andthat sets the niunhLering for all following packets.

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

CMP A,BBMI A is less

I)o not use the BI.T or BLO instruction. On a pdpl0, use the inst. CtionsSUB A,BIRNE A,100000

JRST A is less

)o not u.e the CAM(lI in,,trtction. On a IJi,,p machine, use the code(II (il -IFS1 Io100000 ( A 13))

"A i:; loss>)

l)o n t tsC lh1 1 1.'. (D[ <) 111unctio 1.

10

Page 17: ASAHUSETTS TECH CAMBRIDGE ARTIFICIAL F/S, UC · PDF fileboth the hardware and software protocols. It is intended to be the definitive documentation for Chaosne~ 1 9 11 3~ I ~ '7 1

Packets 12 Chaosnet

3.5 Packets

A packet consists of a header, which is 8 16-bit words, and zero or more 8-bit or 16-bit bytesof accompanying data. In addition there are three words put on by the hardware, describedearlier in this paper.

The following are the 8 header words:

Operation The most-significant 8 bits of this word are the Opcode of the packet, anumber which tells what the packet means. The 128 opcodcs with high-orderbit 0 are for the use of the network itself. The 128 opcodes with high-orderbit 1 are for use by users. The various opcodes are described in chapter 4,page 20.

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

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

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

Destination AddressThis word contains the network address of the destination host to which thispacket should be sent.

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

Source Address '[his word contains the network address of the source host which originated thispacket.

Source Index 'Ibis word contains the connection index at the source host of the connectionto which this packet belongs, or 0 if this packet does not belong to anyconnection.

Packet Number If this is a controlled packet, this word cointils its identifying naumber.

('/ COw'ICdgcc1i1I The tLSc of this word is dcscribcd in SCcLion 3.8, pge 16.

I ),I:Mt 10 15 J\ * I IN -XI

Page 18: ASAHUSETTS TECH CAMBRIDGE ARTIFICIAL F/S, UC · PDF fileboth the hardware and software protocols. It is intended to be the definitive documentation for Chaosne~ 1 9 11 3~ I ~ '7 1

Chaosnet 13 DIata Formats

3.6 Data Formats

Data transmitted through Chaosnet generally follow I isp Machine standards. Bits and bytesare numbered from right to left, or least-significant to most-significant. 'I lhe first 8 hit byte in a16-bit word is the one in the arithmetically least-significant position. The first- 16bit ,ord in a32-bit double-word is the one in the arithmetically least-signilicant position.

The character set uscd is dictated by thc higher-leveJ protocol in use. Telnct and Supdup, forexample, each specifies its own ASCII-based character set. The "default" character set-used fornew protocols and for text that appears in the basic Chaosnct protocol, such as contact names-isthe Lisp Machine Tharacter set ICtlINUAILJ. [his is basically ASCII. augmented with additionalprinting characters and a different set of format-cffector (or "control") characters.

Because the rules for bit numbering conflict with the native byte-ordering in pdpl0s, andbecause it is quite expensive to rearrange the bytes using the pdpl0 instruction set. pdplls whichact as front-ends t'or pdp)Os must reformat packets passing through them, and pdpl0s interfaceddirectly to the network must have interfaces capable of rearranging the bytes. This requires thatthe network protocols explicitly specify which portions of each type of packet are 8-bit bytes andwhich are 16-bit bytes. In general the header is 16-bit bytes and the data field is 8-bit bytes, butcertain packet types (OPN, S'IS, RUT. and opcodes 300 through 377) have 16-bit bytes in thedata field. Use of 32-bit data is rare, so no provision is made for putting 32-bit data into thestandard format for pdplOs. On our current network pdpl0s are the only hosts which require thispacket reformatting assistance, because most modern computers number their bits and bytes fromleast-significant to most-significant.

The effect of this is that user programs that use the Chaosnet always see the data in a packetand its header in the native form of the machine they are running on, and the necessaryconversie is are automratically applied by the network. This statement applies to the order of bitsand bytes within a word. but not to the character set (when packets contain textt,tl data) which isdictated by protocols.

Unlike some other network protocols, Chaosnet does not use any software checksumming.Because of the diversity of hosts with differctt architectures attached to the Cha,,net, it isimpossible to devise a checksuimming algorithm which can be executed compatibly and flicientlyon all hosts. Instead, Chaosnet relics on crror-ch'cking hardware in the network interfaces, andassumes that other sur'ces of packet damage that checksums could detect, such as stwre bugsin a Network Control Program, either do not occur or w ill produce syniptonis so u' h us thatthey will be detected and fixed immediately.

3.7 Routing

Ro ng,' consists of' deciding how to dcliver a packet to the ocoletik node sp.cificd by thedestinatio n addlress field of' the packet. Ii1ving1 reCchd that nodc. the p.a kct im nii. imlly hedelivercd to ieh de,,tilition usem' process a the detiallmionl i dex. III ), cilclli lotinp Imay he anm ltl 4cp " t e ) ' ,, ii\Olvitig train ,till 0iuinhf m\c1 ,ailhocts, l Iwle t 1,x, ii ) i til diiectlu:1mil~;II c t: iimctclim'ul hct' cl the ;oIIcc iiid th 1 c"sIiimilmoi . Note li tc It1111' I ,'iion isfll.fde ,,,lm;l.11c'iv 101- (:I('If ([ wlt' , "0 ) ,ti/ I( ICICt tt IVC 10 OW t -9h l I;) onjll io~p ,

I ,I,: ltI F;, 1 04 1.,Itl ', .JU N -81

Page 19: ASAHUSETTS TECH CAMBRIDGE ARTIFICIAL F/S, UC · PDF fileboth the hardware and software protocols. It is intended to be the definitive documentation for Chaosne~ 1 9 11 3~ I ~ '7 1

Routing 14 Chaosnet

Any host that is connected to more than one subnet acts as a bridge and forwards packetsfrom one subnet to another when necessary. There could also be hardware bridges which are nothosts, although we have not yet designed any such device. Since routing does not depend onconnections, a bridge is a very simple device (or program) which does not need much state. "Ibismakes the bridge function inexpensive to piggyback onto a computer which is also performingother functions, and makes reliable bridge software easy to implement.

The difference between a bridge and a gateway, in our terminology, is that a bridge forwardspackets from one sub-Chaosnet to another, without modifying the packets or understanding themother than to look at the destination address and increment the forwarding count, and does notdeal with connections nor with flow control, while a gateway interconnects two networks withdifecring protocols and must understand and translate the information passing through iLGateways may also have to deal with flow and error control because they connect networks withslow or differing speeds. Bridges are suitable for local networks while gateways are suitable forlong-distance networks and for connecting networks not produced by the same organization.

To prevent routing loops, each packet contains a tbrwarding-count field. Fach bridge thatforwards the packet increments this count; if the count reaches its maximum value the packet isdiscarded. The error-control protocol will recover discarded packets, or decide that no viableconnection can be established between the two hosts.

The implementation of routing in an operating system is as follows, given a packet to berouted, which may have come in from the network or may have been originated by the localhost. First, check the packot's destination address. If it is this host, receive the packet.Otherwise, increment the forwarding count and discard the packet if it has been forwarded toomany times. If the destination is some other host on a subnet to which this host is directlyconnected, transmit the packet on !hat subnet; the destination host should receive it. If thedestination is a host on a subnet of which this host has no knowledge, look up the subnet in thehost's routing table to find the best bridge to that subnet, and transmit the packet to dat bridge.

rFich host has a routing table, indexed by subnet number, which tells how to get packets tohosts on that subnet. Fach entry contains: (exact details may vary depending on implementation)

Ty-pe The type of connection between the host and this subnct. This can be one ofDirect, Bridge, or FI'red Bridge. Direct means a physical connection such as aChaosnct interface. liridge means an indirect conncction, via a packet-forwardingbridge. Which bridge is best to use is to be discovered by this routingmehmnism. IFixed Iridye is the saute cxcCpl that the autoiriatic rncci.aiSu; is notto thrnge Ith bridge is used. This is useil to set up explicit fouting lorprimie ,, such as nctwork dcbugging.

, h/11 IdLmlcr ih:s tire tills irlmet in c \Nry \hiih dclrrrds un the pe. [For,i 1L. ( c onrIcctiO ., this identilic, thC piceC 01' Iiailw;Aic wlitl illllriOr CInIs theu~rrretilon. (It right be a I tnibus address.) IFor a blidge or a fixed bridge, thisis t le netWoi rk iddr,'.ss o i tile hridge.

( A il,r1C il" tiht Ciri of' Sendifing a pickc (hirorgt ihis iuitc. (Cois are used tos.k ct 1ire be, i'tli Iloi i a olig a o ltei, ll , ,'ils ill awa tlVesClihbed belhw. [or it(llr'i.I wrrrc tm l. ir ol 1 mI .i dri, tis IiOtr i ll ilk Ii't\ Icn I\\w e rrp:t'r" (e.,g.

-. I;,e ., ll 1 1,1 I t ,i1i ilt I1r o -,i ntldl Ii i , I, iii n I I iu, ,.tile 1,0 to,

+-.1 , , irnClitl ri l t S 1n1 ii itrirroir, iri'C, IC. I'M' a iir, i r, (1' r fixed hli de+e.ili. u.'t i, ',K: 1iel h) lieW hlil: ill , F I ri ket (Als".rrii,' iiehov,).

f.... " It , ' .\\ I " I iii l:-.IJ N 81

Page 20: ASAHUSETTS TECH CAMBRIDGE ARTIFICIAL F/S, UC · PDF fileboth the hardware and software protocols. It is intended to be the definitive documentation for Chaosne~ 1 9 11 3~ I ~ '7 1

Chaostet 15 Routing

The routing table is initialized with the numbcr of a more or less arbitrary existent host and ahigh cost, for each ,subnet to which the host is not directly connected. Until (lie coirrect bridge isdiscovered (,Ahitb norm~illy happens within a tiinute of coming uip), packets for that subniet will

be bounced Off of that arbitrary host, which probably knows the right bridge to forward them to.

The cost for subncts acccssed via bridges is increased by 1 every 4 seconds, thus typicallydoubling after a niule. When the cost reaches a "high" value, it sticks there, preventingpriblems with ,ar ithmetic ovcrilhw. The purpose of the increasing cost is to discount the value ofold information. hc cost fo~r subncts accessed via direct connections and fixed bridges does notincrease.

Every 15 seconds, a bridge advertises its presence by broadcasting a routing (RUT) packet oneach subnct to which it is directly connected. Each host on that subnet receives the RUT packetand uses it to update its routing table. If the host's routing table says to access a certain subnetvia bridges, and the RUT packet says that this is the best bridge to that subnet, the routing tableis updated to say that this bridge should be used.

Note that it is important that the rate at which the costs increase with time be slow enoughthat it Lakes more than twice the broadcast interval to increase the cost of one hop to be morethan the cost of two hops. Otherwise the routing algorithm is not well-behaved. Suppose subnetA has two bridges ((Y and /3) on it, and bridge a is connected to subnet 11 but bridge /3 is not (itgoes to some other irrelevant subnet). Then if the costs increase too fast and bridges a and /3 donot broadcast their RUT packets exactly simultaneously, sometimes packets for subnet 11 may besent to bridge /I because its cost appears lower. Bridge /3 will then send thcm to bridge a, wherethey should have gone directly. In more complicated situations packets can go around in a circlesome of the time.

The source address of a RUT' packet must be the hardware address of the bridge on theparticular subnct oi %hich the packet is broadcast. The destination address of a RUT packetmust be iero; RLIT packets are not forwarded onto other subncts. The byte count of a RUTpacket is a mtiltiple of 4 and the packet contains up to 122 pairs of 16-bit words:

word I Ttc subnet number of a subnet which this bridge can get to, directly orindirectly, right-adjusted.

word 2 The cost of sending to that subnet via this bridge. This is the current cost fromthe bridge's routing table, plus the cost for the sruhnct on which the routingpacket is heing broadcast. Adding the suhent cost eliminates loops, and prefersone-hop paths over two-hop paths.

When a host receives a RIJT packet, it processes each 2-word entry by comparing the cost forthat stibnet against its current ost; if it is less or equal the cost ond the addrcss of' the bidgeare entered into the routing table, prosuid that that tlbiet's routing table entry is not of the

l)ircct or Fixed Bridile type.

When there are imulltiple Cqulivalent bridges, the tratlic is spread lniong them onIl) by virtueof their RUT packet-, being sent at diftircnl tithes, so that solictilles oIl hrldi-c i1.t, I1le lowerco>,., and ;otllefillics tile other. I1 this in't ,dequat'. hosts coid hat, h.lii Cr I I n t, bles

liidr Ic tlcI llho l e , Hils' thin oilk po..illk' tolle mid risc lli'I) ,.1'1 lio " ld i tu ll 1 il i ' to"It, 111tI'll tI , I1., Iml hkvlo 'ee , ,ire hi r t\k .o k Iralhic is Iltl f) hlii'll .1, toI .,Ii I l y nle

0l1il R'.

Page 21: ASAHUSETTS TECH CAMBRIDGE ARTIFICIAL F/S, UC · PDF fileboth the hardware and software protocols. It is intended to be the definitive documentation for Chaosne~ 1 9 11 3~ I ~ '7 1

Flow and Error Control 16 Chaosnet

The design of this routing scheme is predicated on the assuimption that the network geometryis simple, there are few multiple paths, and the length of any path is quite short. Ihis makesmore sophisticated schemes unnecessary.

An important feature of this routing scheme is that the size of the table is proportional-to thenumber of subnets, not to the number of hosts. Thus it does not take up an inordinate amountof memory in a small computer, and no complicated dynamic allocation schemes are required.

In the case of a pdplO which accesses the Chaosnet through a front-end pdpl1, we define theinterface between the two computers to be a subnet, and regard the pdplt as a bridge whichforwards packets between the network and the pdplO. This gives the pdplO and the pdpllseparate addresses so that we can choose to talk to either one, even though they are part of thesame computer system. This is occasionally useful for maintenance purposes. It becomes moreuseful when the front-end pdpll has peripherals which are to be accessed through the Chaosnet,since they can simply look like hosts on that pdpll's private subnet.

In the case of a host which is attached to more than one subnet, it is undesirable for the hostto have more than one address, since this would complicate user programs which use addresses.Instead, one of the host's network attachments is designated as primary, and that address is usedas the host's single address. The other attachments are regarded as bridges which can forward tothat host. Sometimes, we simplify the routing by inventing a new subnet which contains only thathost and has no physical realization. The host's address is an address on that fake subnet. All ofthe host's network attachments are regarded as bridges which know how to forward packets to thatsubnct.

The ITS host table allows a host to have multiple addresses on multiple networks, hut whenyou ask for Mhe address of a certain host on a certain network you only get back the primaryaddress. All packets coming from that host have that as their source address.

3.8 Flow and Error Control

'[he Network Control Programs (NCPs) conspire to ensure that data packets are sent fromuser to user with no garbling, duplications, omissions, or changes of order. Secondarily, theNCPs attempt to achieve a maximum rate of flow of data, and a minimum of overhead andretransmission.

'l hc fundaniental basis of flow-control and error-control in Chaosnct is rcllanvinissiont. Packetswhich arc diaged in Inansinission, which won't fit in h Ifeis, which ;ic duplicated or out-of-

s'ltillcC, o- which otherwise are cmbarrassing are silI iply (i,,tir(led. Packets are periodicallyrctrnsitittcd until an indication that they have been siccessfhl y rcce,i ed is rltlnn'd. ThisretlansIis-tol is cml-th-cnd any intermediate bridges Io not parti:ip itc in Ihm-contiol and error-

con trol. and hence irc 1rve to discard any packets they wish.

T'here are actually two kinds of ptkets, conroloI and wu'onlrollcd. Controlled packets areictransniojd and deliered reliably; nioit packels. iincludim, all 1ickeb, iIClx by (he ucr (except

oiir I INC pIckets), ;ire of this lype. I hIcontrollcd p;t lxeih are i1 rct.tlInaimiItd" ilus are ticd

li 1.i till li'wcr-lk'-cl fllirtions of, the pri t(h ve lch l ;1i,, l .'ii cnl t ioi t;1" (how and er1ror

- =_, coimilm'. I I II\a of, flt-'sC pat'kctS is d ,ivncd -o ih; Ihy t ed oNI 1w d.li'"ud ielh Ih .

l I 'i. ,:N1 ) N:\MI.II 10'7 15 JUIN-81

Page 22: ASAHUSETTS TECH CAMBRIDGE ARTIFICIAL F/S, UC · PDF fileboth the hardware and software protocols. It is intended to be the definitive documentation for Chaosne~ 1 9 11 3~ I ~ '7 1

Chaosnet 17 Flow and Error Control

Retransmission of a packet continues until stopped by a signal from the receiver to [Oe sendercalled a receipt. A receipt contains a packet number, and indicates that all controlled packets witha packet number less than or equal (modulo 65536) to that number have been successfullyreceived, and therefore need not be retransmitted any more. A receipt does not indicate thatthese packets have been processed by the destination user process: it simply indicates that theyhave successfully arrived in the destination host, and are guaranteed to be there when the userprocess asks for them.

There is another signal from the receiver to the sender, called an acknowledgement. Anacknowledgement also contains a packet number, and indicates that all controlled packets with apacket number less than or equal (modulo 65536) to that number have been read by thedestination user process. This is used to implement flow-control. Note that acknowledgement of apacket implies receipt of that packet. In fact, if the receiving process does not ibll 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 datatransmission rate to be slower than it could be, and on the other hand, large numbers of packetspiling up in the network because the sender is sending faster than the receiver is receiving. It isalso necessary to be aware that receipts and acknowledgements must be transmitted through thenetwork, and hence have an associated cost.

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

We do not receipt and acknowledge every single controlled packet that is transmitted througha connection, since that would double or triple the number of' packets sent through the networkto move a given amount of data. Instead we batch the receipts and acknowledgements. But ifacknowledgements are not sent sufficiently often, the data will mot tloA smoothly, because thewindow will often appear full to the sendcr when it is not. If r.ccipts ,are not sent sufficientlyoften, there will be unnecessary retransmissions.

Whenever a picket is sent through a connection, an acknowledgenient for the rc cise

direction of that connection is hopi .t' ked" onto it, using the Aknowledgeiilet elild in tiepu;,kct header. l-or imtercive ;ipplicition,. Mtiele Ihcre is miih iralic in otl diletitt ls, thispioOdides ill the nlcc, ,;irv ickiiowledeicni mid rc.ilpting with n no''(d io s'ntld ,iny t\1t, r ,ckels1h11-oligh tile lctwoilo.

W ic i hi [this itot sulliec, S I (,i't ) pm kct,, ire g', evm' d toi .,n i i ipts ,1n'1

,t ll . , .'ltlg' . .t;', I S cket, ie tlli,... L:1tl ed , ,1cQ tel'y l . iiL' oI f th ' li vh,uii,,tl I mt1ll+ll iLq( 'n tsL I 1 y., Cnlll d p~ t kcs. II .Ill '0 ', pIlk't is dipit ibt'd. it (h)c, It( h.,1m . II . S11 I.Nl,.ckvt iN Ih.t. emiehlm im, exit t hih v, itl cr , repl~la etMl k,, he ecilnkc:,tcd litr An S IS

I m:10, :it )t )N AM II I t 1:, .IIN-81

Page 23: ASAHUSETTS TECH CAMBRIDGE ARTIFICIAL F/S, UC · PDF fileboth the hardware and software protocols. It is intended to be the definitive documentation for Chaosne~ 1 9 11 3~ I ~ '7 1

Flow and Error Control 18 Chaosnet

packet carries separate receipt and acknowledgement packet numbers.

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

When a packet is received with the same packet number as one which has already beensuccessfully received, this is evidence of unnecessary retransmission, and an STS is generated tocarry a reccipz back to the sender. If this STS is lost, the next retransmission will stimulateanother one. Thus receipts are normally implied by acknowledgements, and only sent separatelywhen there is evidence of unnecessary retransmission.

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

Another operation is probing, which consists of sending a SNS packet, in the hope ofeliciting either an STS or a LOS. depending on whether the other side believes the connectionexists. Probing is used periodically as a way of testing that the connection is still open, and alsoserves as a way to get STS packets retransmitted as a hedge against the loss of anacknowledgement, which could otherwise stymie the connection. SNS packets are uncontrolled.

We probe every five seconds on connections which have unacknowledged packets outstanding(a non-empty window) and on connections which have not received any packets (neither data norcontrol) for one minute. If a connection rcceivcs no packets for 1 1/2 mintcs. this means that atleast 5 probes have been ignored, and the connection is declared to be broken: either the remotehost is down or there is no viable path through tie network between the two hosts.

The receiver can generate "spontaneous" STSs, to stimulate retransmission and keep dingsmoving on fast devices with insutlicicnt buffering for 1/2 second worth of packets. This providesa way for the receiver to speed up tie retransmission tineout in the sender, and to make suretht acknowledges arc happening olten enough.

Note tht the network still finciions if either or both parties to a connection ignore the\,indow. 'I hc winidov is Simply an i lpiovcr of cflicicvin. kcceilpts hiic the' s iivc pIoperty. Tiisallows very simall imillcticntations to be compatible with the same protocol, n hith iks useful forapplicatiOns Such as bootstralping through the network.

It wtold he possible to havc dynamic adjus.ntent 0" the window size in respon e to observedtihehi0ior. Ilhe S'IS pcket includes the witidow si/e soi thal (:lill1.ees to it (" Ine coguiut.nkated.

olwcver, thi, hi', not been fouind nececa;r) in practice. I ,lI, hiihcr-lce li prot.ii has a st.inudirdptc-ucl iud iiitlok ,i/c. M6hi11 it 't,,hc, when it tii,.t opens a uoMICli(on, .1i,, this Se'insI(, be iw" o ll itllh to n)pit11i11 t th: ull L,1111111 .(huuii, i t oh' it vo\uildit ite lis.di\le CtiC('.

Page 24: ASAHUSETTS TECH CAMBRIDGE ARTIFICIAL F/S, UC · PDF fileboth the hardware and software protocols. It is intended to be the definitive documentation for Chaosne~ 1 9 11 3~ I ~ '7 1

Chaosnet 19 Flow and Error Co trol

This scheme for flow-control and error-control is based on several assumptions. It is assumedthat the underlying transmission media have their own checking, so that they discard all damagedpackets, making packet checksums unnecessary at the protocol level. The transit time through thenetwork is assumed to be fast, so that a fairly-small retransmission interval is practical, andnegative acknowledgements are not necessary. The error rate is assumed to be low so that overallefficiency is not affected by the simple-minded error recovery scheme of simply retransmitting alloutstanding packets. It is assumed that no reformatting of packets occurs inside the network, sothat flow-control and error-control can operate on a packet basis rather than a byte basis.

I )I. :IO(( )N:ANI IlI:I 107 15-JUN-81

Page 25: ASAHUSETTS TECH CAMBRIDGE ARTIFICIAL F/S, UC · PDF fileboth the hardware and software protocols. It is intended to be the definitive documentation for Chaosne~ 1 9 11 3~ I ~ '7 1

Software Protocol-Details 20 Chaosnet

4. Software Protocol--Details

In the following sections, each of the packet Opcodes and the use of that packet type in theprotocol is described. Opodes arc given as an octal number, a three-letter code, and a name.

Unless otherwise specified, the use of the fields in the packet header is as follows. Thesource and destination address and index denote the two ends of the connection; when an enddoes not exist, as during initial connection establishment, that index is zero. The opcode, bytecount, and forwarding count fields have no variations. The packet number field containssequential numbers in controlled packets; in uncontrolled packets it contains the same number asthe next controlled packet will contain. Ihe acknowledgement field contains the packet number ofthe last packet seen by the user.

4.1 Connection Establishment

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

1 RFC Request for connection

All connections are initiated by the transmission of an RFC from the user to the server. Thedata field of the packet contains the contact name. The contact name can be followed byarbitrary arguments to the server, delimited by a space character. The destination index field ofan 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.liccause RFC's are not sent over normal, error-controlled connections, a special way of detectingand discarding duplicates is required. When an NCP receives an RFC packet, it checks allpending RFC's and all connections which are in the Open or RFC-received state (see section 4.6,page 25), to see if the source address and index match; if so, the RFC is a duplicate and isdiscarded.

12 LSN Listen

A server process informs the local NCP of the contact name to which it is listening bysending a I.SN packet, with the contact name in the dala field. This packet is never transmittedanywhere thiough the network. It simply serves as a convenient hulfer to hold the server's contactnam e. When an RI"C and i I.SN containing the samie contact nanmc meet, the I.SN is discardedand the RiC is given to the server, plttting its connection into the IflC-received state (see section4.6, page 25). "lhe server reads the RFC and decides whether or not to open the connection.

2 OPN Open connection

Ol'N is Ile utMul positive rcsponc to R :C. 'lhe ,otrce inldex field colvc +s the sei\cl's indexointllr (I)t' tO i uscr: le uer's index maithei Aas coe 'ccd in the Il (. I d, h licld o, t flN

is the salie 'Is that ol1 S'IS (see below); it sets , imu1ill) to 0. iVC the %c I,." , ill M 1,i,'c tu the

I )'\I:'\lt)N :AMII[R 107 15-.1 . N -8 1

1 i t

Page 26: ASAHUSETTS TECH CAMBRIDGE ARTIFICIAL F/S, UC · PDF fileboth the hardware and software protocols. It is intended to be the definitive documentation for Chaosne~ 1 9 11 3~ I ~ '7 1

Chaosnet 2d Connection Establishment

user. The Acknowledgemcnt field of the OtPN acknowledges the RFC so that it will no longer beretransmitted.

OPN is a controlled packet; it is retransmitted until it is acknowledged. l)uplicate OPNpackets arc detected in a special way, if all OPN is received fior at connection which is not in the

R'C-sent stite (see section 4.6, page 25), it is simply discarded and an STS is sent. This canhappen if the connection is opened while retrnsmitted OPN packet is in transit through thenetwork, or if the STS which acknowledges an OPN is lost in the network.

3 CLS Close connection

CLS is the negative response to RI"C. It indicates that no server was listening to the contactname, and one couldn't be created, or for some reason the server didn't feel like accepting thisrequest for a connection, or the destination NCP was unable to complete the connection (e.g,connection table full.)

CIS is also used to close a connection after it has been open for a while. Any data packetsin transit may be lost. Protocols which require a reliable end-of-data indication shoUld use themechanism for that (see section 4.4, page 24) 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 immediatelyafterwards, leaving nothing to retransmit the CLS. Since there is no error recovery orretransmission mechanism for CL.S, the use of Cl.S is necessarily optional: a process could simplystop responding to its connection. However, it is desirable to send a CS when possible toprovide an error message for the user.

4 FWD [orward a request for connection

This is a response to RFC which indicates that the desired service is not available from theprocess contacted, hut may he available at a possibly-different contact name at a possibl)-differenthost. The data field contains the new contact name and the Ackno\% lcdgementfield-exceptio|ally-conmtains the new host number. 'he issuer of the RUC should isSuc anotherRFC to that address. IWI) is an uncontrolled packet; if it is lost in the network, theretransmission of the R[C will presumably stimulate an identical DWI).

5 ANS Answer to a simple transaction

This is mnother kind of response to RI.C. [he (lata lield contains the entirety of the response,and no connection is c,tiblish'd. ANS is .1n UnCoiiolled packet if it is lOst in the ntwork, there, mslli'..iol o' ie R.(. will pr.u:mih)l simmlat, an ideanticl ANS.

'I here a k, \eIcri ll lllw.'( lloill illilidioinl l it(ocols iI ll cilict',I okith 1l10 k.' picket t'l 's.

(Vl i,1' l ll;11. I" cr'.it 1 hortC\el Ii ' , 1 P l i , lh 1 ',r l ,',' 1A . i l,ci ,l, t1 , 11hW RIC '(

pjmncs', that cik(, I1,.' RIJC chl)o','s h l0ll I 111,1 l 1101 I)Jtti0 1, ii to , li 11v. 11', i l .'C N' is

I ).,I.:: M ()( N l"i:\N1111l..I-1 1 V - N -.

Page 27: ASAHUSETTS TECH CAMBRIDGE ARTIFICIAL F/S, UC · PDF fileboth the hardware and software protocols. It is intended to be the definitive documentation for Chaosne~ 1 9 11 3~ I ~ '7 1

Connection Establishment 22 Chaosnet

given the RFC as data, so that it can look at the contact name and any arguments that may bepresent.

A stream connection is initiated by an IFC, transmitted from user to server. The serverreturns an OPN to the user, which responds with an SIS. These three packets convey the -sourceand destination addresses, indices, initial packet numbers, and window siues between the twoNCP's. In addition a character-string argument can be conveyed from the user to the server inthe RFC.

The OPN serves to acknowledge the RFC and extinguish its retransmission. It also carries theserver's index, initial packet number, and window size. 'The STS serves to acknowledge the OPNand extinguish its retransmission. It also carries the user's window size; the user's index andinitial packet number were carried by the RFC. Retransmission of the RFC and the OlINprovides reliability in the face of lost packets. If the RFC is lost, it will be retransmitted. If theSTS is lost, the OPN will be retransmitted. If the OPN is lost, the RFC will be retransmittedsuperfluously 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 tie other sidebelieves the connection is open; once this has happened data may begin to flow through theconnection. The user process may begin transmitting data when it sees the OPN. The serverprocess may begin transmitting data when it sees the STS. These rules ensure that data packetscannot arrive at a receiver before it knows and agrees that the connection is open. If data packetsdid arrive before then, the receiver would reject them with a LOS (see below), believing them tohe a violation of protocol, and this would destroy the connection before it was ever fillyestablished.

Once data packets begin to flow, they are subject to the flow and error control protocoldescribed in section 3.8, page 16. 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 CI.S rather thanOI'N. The data field of the CLS contains tie reason for refusal to connect.

A frnvarded connection is initiated by an RIC in the same way, but the server returns a[WI.), telling the user another place to look for the desired service.

A 01mple transaction is initiated by an R['C from user to server, and completed by an ANSIrl ',ciwcr to uter. Since a full connection is IWL established and tile reliable-transmissionil'.[1 i;lill of connections is itOt (ISe, thC uSC'r plroceS cinnoit he SlelC how lriiv copies of theRI tile ,erver :in ilid the server procss cmnot be site that its answelr got hadl, to the user.Ii,, ii '; I h , tint 1iy t. .,:ii itn]() ,hnihl oiwd he ued f 'r I;1~phlit ;1innt1', \0 ln't it ik inmptytallt tokim. mwhicetr thie train.action was reill) completed, no 'or oipplitions in Oith rcpeating theiii % p 1C11 i',1ht pro1ducc a dill'crm'nt 0inswer. Simiplc ir:ii,.i' tions ire a simple ellicientSin .1l11,ll till ,i applications such a , \tractirng a snii ll piece of inforniiatioit (e.y. the (itle of day)I t i a ( it l ll dillit-1),1se.

I1,1,%I( i0%4.A r ),.,\lIh I ! h' 11 N :, 1

Page 28: ASAHUSETTS TECH CAMBRIDGE ARTIFICIAL F/S, UC · PDF fileboth the hardware and software protocols. It is intended to be the definitive documentation for Chaosne~ 1 9 11 3~ I ~ '7 1

Chaosnet 23 Status

4.2 Status

7 STS Status

SI'S is an uncontrolled packet which is used to convey status information between NCPs. TheAcknowledgement field in the packet header contains an acknowledgement. that is, the packetnumber of the last packet given to the receiving user process. The first 16-hit byte in the datafield contains a receipt, that is, a packet number such that all controlled packCts up to andincluding that one have been successfully received by the NCP. The second 16-bit byte in thedata field contains the window size for packets sent in the opposite direction (to the end of theconnection which sent the STS). The byte count is presently always 4. This will change if theprotocol is revised to add additional items to the STS packet.

6 SNS Sense status

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

11 LOS Lossage

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

L.OS is sent in response to situations such as: arrival of a data packet or an STS for aconnection that does not exist or is not open, arrival of a packet from tie wrong source for itsdestination, arrival of a packet containing an undefined opcode or too large a byte count, etc.

l.OS's arc given to the user process so that it may read tile error message.

No I.OS is given in response to an I'N to a connection not in the RFC-Sent state, nor inresponse to a SNS to a connection not in the Open state, nor in response to a I OS to a non-existent oi- broken connction. Tlhese rules arc imlportant to 111,c (ihe pr'otocols work withoulttiming errors. An OI'N or a SNS to a non-existent connection elicits a IOS.

I)'1K:Nt)( JN:,\I fl k/ 101 I5-J iN 81

Page 29: ASAHUSETTS TECH CAMBRIDGE ARTIFICIAL F/S, UC · PDF fileboth the hardware and software protocols. It is intended to be the definitive documentation for Chaosne~ 1 9 11 3~ I ~ '7 1

Daa24 Chaosnet

Opcodcs 20truh27(ca)recontrolled packets with user data in 8-bit bytes in thedata field. The NCP treats all 64 of these opcodcs identically: some higher-level protocols use theopcodes for their own purposes. The standard default opcode is 200.

300-377 DAT 16-bit Data

* Opcodcs 300 through 377 (octal) are controlled packets with user data in 16-bit bytes in the* data field. T[le NCP treats alt 64 of these opcodes identically; some highr-levecl protocols use the* opcodes for their own purposes. '[he standard default opcode for 16-bit data is 300.

15 UNC Uncontrolled Data

T[his is an uncontrolled packet with user data in 8-hit bytes in the data field. It exists so thatuser-levcl programs may bypass thc flow-control mechanism of Chaosnet protocol. Note that theNCI' is free to discard these packets at any time, since they are uncontrolled. Since UNC's arenot subject to flow control, discarding may be necessary to avoid running out of buffers. Aconnection may not have more input packets queued awaiting the attention of the user programthan the window size of the connection, except that you are always allowed to have one UNCpacket queued. If no normal data packets are in use, up to one more UNC packet than thewindow size may be queued.

UNC packets are also used by the standard protocol for encapsulating packets of foreignprotocols for transmission through Chaosnct (see chapter 6, page 32).

4.4 End-of-Data

14 EOF Fnd of File

EOI' is a controllcd packet which serves as a "logical end of data" mnark in the packet stream.When the user program is ignoring packets and treating at Cliaosnet connection its a conventionalhytc-strcain 1/0 device, the NCP uses the F packet to convey the notion of conventional end-of tile froim one end of tie conncction to the other. When the user progrm'~n is working at thepicket k'\cl, it mnay transmit and receive EOis

I(*) IpAc' te istircn'cd in thc l'o ili~logIV pI)ot jCol Whjich is JI e r-CC On 11in et ded w to ret i ih1 ydcicrniinc tha~t all datia have beenO trarnsf'err-cd bel'ore closing a conne-ction (in ap~plications wheirediit is ;lit illitiiltaut consideration).

Ific ipiiini issie is thit iicitti Side iay send ;I CTIS tuntil both Sides ilre iiethat ;Ilt the(I If Ii h Ic hun 11iripujiticd Aflcr 'cJlling ;Ill thic dil;i it is going to sCind, ictitdiiig 111 1:OF-pitl, i it) irk tIIc coid, 111C studinei prole''s V.,lit, 1101 111IVA'Ik lS to IW' ,i'.;i e g T his

I bl . i- Ili, I I~ '1 'iC d)I~ f.IIm t. i 'oil i 1c i lilt' JOi Im r dii Ie o itC k limeS

Page 30: ASAHUSETTS TECH CAMBRIDGE ARTIFICIAL F/S, UC · PDF fileboth the hardware and software protocols. It is intended to be the definitive documentation for Chaosne~ 1 9 11 3~ I ~ '7 1

Chaosnet 25 Low-level

until a brief timeout elapses. The timeout is to provide for the case where the sender's CLS getslost 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 [OF by thetime thc timeout is over.

To use this protocol in a bidirectional fashion, where both parties to the connection aresending data simultaneously, it is necessary to use an asymmetrical protocol. Arbitrarily call oneparty the user and the other the server. '[he pr,,)col is that after sending all its datta, each partysends an [OF and waits for it to be acknowledged. The server, having scen its EOFacknowledged, sends a second EOF. '[he user, having seen its [OF acknowledged, looks for asecond [OF and then sends a CLS and goes away. 'I'he server goes away when it sees the user'sCLS, or after a brief timeout has elapsed. 11is asymmetrical protocol guarantees that each sidegets a chance to know that both sides agree that all the data have been transferred. 'Ihe firstCLS will only be sent after both sides have waited for their (first) [OF to be acknowledged.

4.5 Low-level

13 MNT Maintenance

MN is a special packet type reserved for the use of network maintenance programs. NormalNCPs should simply discard any MN'' packets they receive. MNT packets are an escapemechanism to allow special programs to send packets that arc guaranteed not to get confiscd withnormal packets. MNT packcts are forwarded by bridges although usually one would not bedepending on this.

10 RUT Routing Information

RUT is a special packet type broadcast by bridges to inform other nodes of the bridge'sability to forward packets between subnets. 'Ihe source address is the network address of thebridge on the subnet on which the RU' was broadcast. lhc dcstination address is /cro. 'hebyte count is a mlltiple of 4, and the data field contains a series of pairs of 16-bit bytes: asubnet number and the "cost" of getting to that subnct via this bridge. 'lhe packet number andacknowledgement fields are not used and should contain /ero. See section 3.7, page 13 for thedetails.

4.6 Connection States

A user process ge'ts to Chaosnet by means of a capability or channel (dependent on the hostoperating system) sshich corresponds to one end ol" a connection. Associated %kith this channel area number of hulfcrs containing controlled p;ckets output by the user aid not yet receipted, anddala packets received from the mntwork Ihut not yet r'ead hy the tuser: some of" Ihc,.e incomingpackets arc in-order by packet number ;nrd hence may bc read by the user, while others are otitof, order aInd calllol be cil lintil pcIkls crr icr in the streiCr Iae been ic'cidil. Certaincontrol packets ac also gisen it the tier as i if hey were dalrl pickers. "lhcs' aic RI'C. ANS,('I S, I.()S. IO( )l", mid liNC. 1:0 1: is OI' eilh, ty e Ii r h a ri l ever I e ojt-( l*- ltr.

I I,.NI()( )N:,\MlII. 107 1L.J81

M

Page 31: ASAHUSETTS TECH CAMBRIDGE ARTIFICIAL F/S, UC · PDF fileboth the hardware and software protocols. It is intended to be the definitive documentation for Chaosne~ 1 9 11 3~ I ~ '7 1

Connection States 26 Chaosnet

Also associated with the channel is a state, usually called the connection state. Fullunderstanding of these states depends on the descriptions of packet-types above. 'he state can beone 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 ithas 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 Openif the user process accepts the request.

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

Lost The connection has been broken by receiving a LOS packet.

Incomplete TransmissionThe connection has been broken because the other end has ceased to transmit andto respond to SNS. Either the network or the foreign host is down. (This canalso happen if the local host goes down for a while and then is revived, if itsclock runs in the meantime.)

fbreign The channel is talking some foreign protocol, whose packets are encapsulated inUNC packets. As far as Chaosnet is concerned there is no conncction. Seechapter 6, page 32 for the details.

I)SKNO 'N:AM1I I 117 IS JUN-81

Page 32: ASAHUSETTS TECH CAMBRIDGE ARTIFICIAL F/S, UC · PDF fileboth the hardware and software protocols. It is intended to be the definitive documentation for Chaosne~ 1 9 11 3~ I ~ '7 1

Chaosnet 27 Fligher-Levcl Protocols

5. Higher-Level Protocols'This chapter briefly documents sonic of the higher-level protocols of the most general interest.

'There are quite a few other protocols which are too spccialized to mention here. All protocolsother than the STATUS protocol are optional and are only inplenentcd by those hosts that needthem. All hosts are required to implement the STATUS protocol since it is used fbr networkmaintenance.

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 networkmaintenance. 'rhe answer to a STATUS request should be generated by the Network ControlProgram, rather than by starting up a server process, in order to provide rapid response.

lhe STATUS protocol is used to determine whether a host is up. to determine whether anoperable 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 functionon the lisp machine, and the Hostat command of the CHATST program on 'IS are user endsfor this protocol.

'he first 32 bytes of die ANS contain the name of the node, padded on the right with zerobytes. [he rest of the packet contains blocks of information expressed in 16-bit and 32-bit words,low byte first (pdpll/l.isp machine style). '[he low-order half of a 32-bit word comes first. SinceANS packets contain 8-bit data (not 16-bit), machines such as pdpl0s which store numbers highbyte first will have to shuffle the bytes when using this protocol. The first 16-bit word in a blockis its identification. '[he second 16-bit word is the number of 16-bit words to follow. Theremaining words in the block depend on the identification.

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

word 0 A number between 400 and 777 octal. This is 400 plus a subnet nuniber. Thisblock contains information on this host's direct connection to that subnet.

word 1 [he number of 16-bit words to follow, usually 16.

words 2-3 The number of packets received from this subnet,

words 4-5 'I he number of packets transmitted to this subnet.

words 6-7 the number of transnissions to this subnct aborted by collisions or because thereceiver was busy.

words 8-9 The irtnohber of inoming packets from this stliblict lost becoause the host had notyet read a pruviou. pack't out of the intelAce and consequentl, the in terfaceCoulId not capture thle packet.

words 10-11 I'he numher of" incoiling pi;ckets fIomo this sohoct with CRC er ,,rs. Ilie erc- Cter IiaMISiniitel WlOIII,, 0I dillliil'd ill tall"MiSSiOnl.

10 i l.1 ! -. 1

Page 33: ASAHUSETTS TECH CAMBRIDGE ARTIFICIAL F/S, UC · PDF fileboth the hardware and software protocols. It is intended to be the definitive documentation for Chaosne~ 1 9 11 3~ I ~ '7 1

Pulsar 28 Chaosnet

words 12-13 The number of incoming packets from this subnet which had no CRC error whenreceived, but did have an error after being read out of the packet buffer. h'liserror indicates either a hardware problem with the packet buffer or an incorrectpacket length.

words 14-15 The number of incoming packets from this subnet which were rejected dIue toincorrect 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 16bits instead of 32, and consequently may overflow. This format should no longer be sent by anyhosts.

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 withcontact name PULSAR, which controls a "pulsar" feature. This feature periodically transmits ashort packet which can be used to test and adjust cable transceivers, The packet consists of thethree header words, a zero word, and a word of alternating ones and zeros. It is addressed tohost 177777 which is guaranteed not to exist.

'The returned ANS contains a single character, which is a digit. A 0 means that the pulsar isturned off. Any other digit indicates the number of sixtieths of a second between pulses. Sendingan RFC with a digit as an argument sets the state of the pulsar to that digit, and rctrns an ANScontaining the new state.

5.3 Telnet and Supdup

The TeInet and Supdup protocols of' the Arpanet [IENET] [SUPDUPJ exi,;.t in identical formin Chaosnet. These protocols allow access to a computer system as an interactive terminal fromanother network node.

'[he contact names are TELNET and SIJPDUP. The direct borrowing of the Icinct andSupdtp protocols was cased by thcir use of 8-hit hyte streams and only a single coniection. NoteIthat the l poto:ols define their own chracter sets, which difler from each other and froml the(hmosnct s ,aid.ird character set.

Chaisnct contains no countelliar of the INR/INS attention-gelling ture of' the Arpanet.I k 'ellncl protocol ;endsi a packet with opcode 21)1 in place of' the INS ,,ignal. Ihis ik acontrollcd Iacket and hence does not proide the "oit of iand" fCatlir' of the Atpammt INS,huwcv'er it is salisL ctoly for the ilncet "interrupt proc:,s" and "discard oo(lpti" oplritlion oii thek iinkS of liot"s attacied to ( Iiaosnet.

I 5 l1 :0it i ,2\MIIIR 117 15 -1N-l I

Page 34: ASAHUSETTS TECH CAMBRIDGE ARTIFICIAL F/S, UC · PDF fileboth the hardware and software protocols. It is intended to be the definitive documentation for Chaosne~ 1 9 11 3~ I ~ '7 1

Chaosniet 29 Vile Access

5.4 File Access

'The Fll.F protocol is primarily used by Lisp machines to access Files on network file servers.ITS and TIOPS-2O arc equipped to act ats fie scrvcrs. A user end for the file protocol Also existsfor 'lOS-2O and is used for general-purpose file transfer. F~or complete documlentation onl the ileprotocol. see HFI i[e Arpanet file transfer protocols have not been implemented on theChiaosnet (except through the Arpaniet gateway described below).

5.5 Mail

The MAIL protocol is used to transmit inter-user messages through the Chaosnet. TheArpanet mail protocol was not used because of its complexity and poor stite of documentation.'Iliis simple protocol is by no means the latst word in mail protocols-, however, it is adequate forthe mail systems we presently possess.

The sender of mail connects to contact name MAIL and cstablishes a streamn connection. Itthen sends the namies of all the recipients to which tie maii is to be sent at (or via) the serverhost. TIhe names are sent one to a line and terminated by a blank line (two catrriage returns inl arow). T[he L isp Machine character set is used. A reply (see below) is immediately reCturned foreach r'ecipient. A recipient is typically just the name of at user, but it can be at use r-atsign -hostsequence or anything else acceptable to the miail system onl thle server machine. After sending therecipients, the sender sends the text of the message, terminated by an V.O1'. After the mail hasbeen successfully swallowed, a reply is sent. After the sender of' mail has read the reply, bothsides close the connection.

In the MAIL. protocol, a reply is a signal from the server to the user (or sender) indicatingSuccess or' filuhre. The first character of at reply is a Plus sign for success, a minus sign forpermanent failure (e.g.*no such user exists), or a percent sign b1r temporary fiiure (e~g. unable toreceive message bcaiuse disk is full). T[he rest of a reply is a human-readable character stringexplatining the situation, followed by a carriage return.

'[he mecssage text transmitted through the mail protocol normally contains a header formattedin the Arpanet standard rishion. [RFC7331

5.6 Send

'Ihe S [N I) protocol is used to tran,;mit an interactive message (requiring immnediate attention)betweenI uIsers. 'I lie sender connects to con tact iaine SI: ,NDI at the m-achi zie to which the recipientis lo gged in. 'The remnainrder of the RFC packet contains thle namne of' the pers;on being senlt to.A stream conniection is oipened and the mec sage is transmnitted, lirlbowed by anl WV~. Bioth sidesclose aftter biollowing the en~d-of-daita protocol described in section 4.4, page 241. Ili he tct that the10-1. %4as rvepondcd to aflirniatively iridierites that thle recipient is in tCrct presoent and accepting

mev.ncs.I 1e11C .w tic t sloird ei n with at suitable header, naming the wicr lli ru sent( tilerrrc ',11W. lire ,t;lrIld,rId lor mch hecaders, riot curmentl1y adhereCd to by 3ll hosts, is (rile linehmiriiarletl j ill thn bilo1v rig exarrriple:

I''o''l 14C? h/15/81 0)?:?0: 1I.\rul,uric r mo i i ii i ice ar lejit pk to Owrer'te(al c lopl llk~ 11% w.rrcltirrr Imu tlhe fil' t "01I' " is rr.rr-tid wm *'1

11 Nl) t11tr1koi tr il' Ir1't br1(ihi irr (ihe \61 1iil tie ,rprirrt iree ililg it.

Page 35: ASAHUSETTS TECH CAMBRIDGE ARTIFICIAL F/S, UC · PDF fileboth the hardware and software protocols. It is intended to be the definitive documentation for Chaosne~ 1 9 11 3~ I ~ '7 1

Name 30 Chaosnet

57 Name

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

le contact name is NAME which can be followed by a space and a string of arguments likethe "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 NAMEprotocol. An RFC with contact name FINGER is transmitted and the response is an ANScontaining 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 fullname, and the user's group affiliation.

5.8 Time

The Time protocol of the Arpanet IrIME] exists on Chaosnet as a simple transaction. AnRFC to contact name TIME evokes an ANS containing the number of seconds since midnightGreenwich Mean Time, Jan 1, 1900 as a 32-bit number in four 8-bit bytes, least-significant bytefirst. Some computers-Lisp machines, for example-which don't have hardware calendar-clocksuse 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. Thegateway server runs on each ITS host that is connected to both networks. It creates an Arpanetconnection and a Chaosnet connection and forwards data bytes from one to the other. It alsoprovides for a one-way auxiliary connection, used for the data connection of the Arpanet FileTransfer Protocol.

The RFC packet contains a contact name of ARPA, a space, the name of the Arpanct host tohe connected to, optionally followed by a space and the contact-socket number in octal, whichdefaults to I if omitted. 'Ihe Arpanet Initial Connection Protocol is used to establish a bi-diiectional 8-bit connection.

If ,i dala packet with opcode 201 (octal) is received, an Arpanct INS signal will betinsnilitd. Any dala bytes in this packet are transiiitted normally.

If a data packet with opcode 210 (oclal) is received, ,in aiixiliaty conc'tioll on ech nctworki' opened.I lie li'et eight data bytes are the (hiiosnct ucolitCI na me Ir the ,luxiliariy :concction:Ow tl cr should .- iitl an RI"(' wilh this nane to the se' ei. [he next Iom dita hyte are theA111.11i(:i so, kct ti1iiihtir to be co'llfi cted to, in the wrolg order, Irl st-,,i ,.iiltu t h\ c first. u'leh, tc si/e ofl the aiuuXilim y contlicno is S bits.

I lie nlf'l,,I .I.i'h ui' o i \A :111 ul t (olel lion C ili kilk to m l O ' . (h;Icket hl,'. dll. toin , ll l , ',11h ,', I h', I )c dd, tLW cjI, IlOs 1o 4 (I S pickel.

I V, I.:,% 1( 1 N ,\ Il I " I / : 101i 1i

Page 36: ASAHUSETTS TECH CAMBRIDGE ARTIFICIAL F/S, UC · PDF fileboth the hardware and software protocols. It is intended to be the definitive documentation for Chaosne~ 1 9 11 3~ I ~ '7 1

Chaosnct 31 Dover

5.10 Dover

A press file may be sent to the I)over printer by connecting to contact name DOVER at hostAl-CHAOS-11. This host provides a protocol translation service which tranlatcs firom Chaosnetstream protocol to the EFTP protocol spoken by the )over printer. Only one File at a time cat)be sent to the l)over, so an attempt to use this service may be relused by a CI.S packetcontaining the string "BUSY". Once the connection has been established, the press file istransmitted as a sequence of 8-bit bytes in data packets (upcode 20(0). It is nccessar' (o providepackets rapidly enough to keep the [)over's program (Spruce) from timing out; a packet everyfive seconds suffices. Of course, packets are nonnally transmitted much more rapidly.

Once the file has been transmitted, an EOF packet must be sent. The tran-aittcr must waitfor that EOF to be acknowledged, send a second one, then close die connection. The two FOF'sare necessary to provide the proper connection-closing sequence for the EFTP pirot ol. Once thepress file has been transmitted to the Dover in this way and stored on the l)oD er's local disk, itwill 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 willbe reported back through the Chaosnet as a LOS containing the text of the error message. Sucherrors are fairly common: the sender of the press file should be prepared to retry the operation afew times.

Most programs that send press files to the Dover first wait for the Dover to be idle, using theForeign Protocol mechanism of Chaosnct to check the status of the Dover. This is optional, butis courteous to other users since it prevents printing from being held tip while additional files aresent to the Dover and queued on its local disk.

It would be possible to send to a press file to the )over using its EFTP protocol through theForeign Protocol mechanism, rather than using the Al-CHAOS-11 gatc.ay srvicc. Ibis is notusually done because EFTP, which requires a handshake for every packet, tends to be very slowon a timesharing system.

-A[, I)SKA100lN;,\MII Rt 1017 15 .1It.] N -H I .

Page 37: ASAHUSETTS TECH CAMBRIDGE ARTIFICIAL F/S, UC · PDF fileboth the hardware and software protocols. It is intended to be the definitive documentation for Chaosne~ 1 9 11 3~ I ~ '7 1

Using Foreign Protocols in Chaosnet 32 Chaos..t.

Using Foreign Protocols in Caosnet

As seen above, foreign protocols which are based on the idea of a bidirectional (orunidirectional) stream of 8-bit bytes can simply be adopted wholesale into Chaosnet, using aChaosnet stream connection instead of whatever stream protocol the protocol was originallydesigned for. ibis was done with the Arpanet Telnet protocol, for example.

When using such protocols between a Chaosnct process and a process on a foreign network, aprotocol-translating gateway stands at the boundary between the two networks and has aconnection on both networks. Bytes received from one connection are transmitted out the other.If the protocol uses any features besides a simple stream of bytes, for instance special out-of-bandsignals, these are translated appropriately by the gateway. The connection is initially set up bythe user end connecting explicitly to the protocol-translating gateway and demanding of it acertain service from a certain host on the other network; the gateway then opens the appropriatepair of connections. For an example of this, refer to the Arpanet gateway (see section 5.9, page30).

However, there are many packet-oriented protocols in the world and sometimes it is desirableto access these protocols at the packet level rather than the connection level, and to transport thepackets of these protocols through Chaosnct links without using a Chaosnet connection. Forexample, there are gateways attached to Chaosnet which provide connections to other networksthat use PUP and Internet as their packet protocols. User processes in Chaosnet hosts may talk tothese other networks in those networks' own protocols by using the foreign-protocol protocol ofChaosnct.

A foreign packet is transmitted through Chaosnct by storing it in the data field of an UNCpacket. The fo~reign packet is regarded as being composed of 8-bit bytes. The source and

destination addresses of the UNC.packet are used in the lsuial fashion to control the delivery ofthe packet within Chaosnet. The packet number and acknowledgement fields of the packet headerare not used for their normal purposes, since this packet is not associated with a Chaosnet streamconnection. Ily convention, the acknowledgement field of the packet contains a protocol number.The number 100000 octal means Internet and the number 100001 octal means PUP. Othernumbers will be assigned as needed. The packet number field of tie packet can be used for anypu rpose.

If a user process transmits an UNC packet through a Chaosnet channel which is in the Closedstate (see section 4.6. page 25). the channel goes into the loreign state and the NCP assumes thatthe user is not tlking normal Chaosnet protocol, hti is using Chaosnct to transport packets ofsumc other protocol. The NCP fills in the source addr ess and index in these packets, hut believeswhat'c~r dcstin ation address and index aie placed in the packet by the uiser. TIhe packet numberand acknowledgement fields of the IJNC packets are not touched by the NCP. Any incomingLINC packcts addressed to the uicrs index on this host will he given to he iser, regardless oftheir :sollicc addics /ildcex: it is tip to the user program to filter o1 atay tonwinted packets. TheNC1' shouihl Also pios ide a way f "r oneC user to receive amy tnclaimed incoming [INC packets, sothai rendc/vous sililrotocols of fIreign protocols may be ,inulated.

Vhcn a l)ckt,l-lrlVliljtiig gateway to a flrei.ll Otlwlvork iccive ai I IN(" pickct wilh the! - i lrf~l t )ltte frolocil n1llllcl. it exilit' I hc Ihrcil pllackt lin til , dall i 1 li; h ii d lics it illto the

lIo iln,,l ictA ilk. \Vhen it rece .s pickc s fiiit the Iitci. % t ork. it Inips elie dt ittiotl

IY. ):M00N:,NIII[R 107 15-ILlN-8l

Page 38: ASAHUSETTS TECH CAMBRIDGE ARTIFICIAL F/S, UC · PDF fileboth the hardware and software protocols. It is intended to be the definitive documentation for Chaosne~ 1 9 11 3~ I ~ '7 1

Chaosnet ad33 Using [orcigu Protocol- inl Chaosnet

address of the packet into a Chaosntil address and index in Some Suitable lfislion, cnauISlateCSthe packet ianUCanlanhstitoChaosnet.

F-or PUP the address mapping is straightforward, since PUP and Chiosnet usc Similaraddressing techniques IF'IWRNEl]. The host address spaces arc thie samec. Tlhe Chaosnet indexmaps drclinotelow-order 16 bits of the PUP port number, and tbe high-order 16 hits arezero. When aPUP is encapsulated in at Chaosnet packet, its PUP header dnlc th~re addressesin the Chaosnict header. When a PUP~ is received by a PUlP/Chaosw mte~ i Chaosnctheader can easily be construICted from the P1UP header. '[lhc Al-Cl AOS-Il is, atached to theMIT Chaosnet and the M IT Ethernet and provides a PUP/Chausknet giatcwas. It ad~ertises toeach network its ability to route packets to host addresses in the other network, using thatnetwork's routing protocols. When it receives a packet from one network that is destined for theother, it does the appropriate encapsulation or c-encapsulation and sends the packet onl its way.Al-CHAOS-1 1 also acts as at bridge between several Chaosnict Suibnets and provides a protocol-translating gateway for sending P~ress files to the D~ovcr printer (a protocol-translating gateway isnecessary for this application because the printer's native protocol, Which could be Used throughthe foreign-protocol protocol, cannot be imp~lemented efficiently under a timnesharing system).

In the case of Internet, only protocols built on the idea of ports canl be straightforwardlysupported without a table of connections in the gateway. The Internet address space includes theChiosnet host address space as a subset but does not provide any address hi eakdowtn %ithin ahost unless ports are used. However, it apeCar's that most protocols are built Onl a protocol thatuses ports, such as the User I atagramn Protocol [U I PJ or the Trawts ion C2ont rol Protocol

In the case of foreign protocols other than PUP, where the addressing structure is notidentical to Chaostnet, a program Must Somehow know the Chaostiet address ut' a packet-translating gateway to the foreign network. By sending UNC packets to ibis gateway. a userprogram can initiate connections to processes ofl that other network without iequiriiig his localNCIP (nor any bridges involved in routing the packets) to know anything Ahoitit ihe nrotocol hie isusing. If the inter-nietwork gateway translates rendleZVOUS protocols appropriately, connections maybe initiated in the reverse direction also--f-rm a user process onl the foreign network to a serverfor the foreign protocol that resides on it Chaosnet host.

T[he foreign-protocol protocol may also be used between two User processes onl Chaosnect, withno foreign network involved, if they simply wish to speak a dillecnt protocol from Chaosniet.[hey are on their own for a rendezvous mechanism, howcee. u tilss thes use ai (ihanv-iet simpletransaction fur rendei vous or otherwise have some way of coii~k\p d ~tu icir ildresses aind inldexnumnbers to each other.

When foreign packets are too large to lit inl the data field of' a ChII WIsnet packet funore than488 bytes), the user program and the piktp asaii ateway mu11st arlee onl at tec Iiniquc fordividing packels into lr~agmnents and re.~imlim them, uinless the tiiiegi prtokol it'ecltlrmi' idesfor this, ais Interniet docs. '[he acket-iumber field in aii I. NU packet is ai ailihlc I )r use byswim*f a (ill uikine, sinn' INAC packets are, not iiornm7,ihl ,v numilbered. [hlis is riot I probleml withl'I 111. silicek it i'odts it protocol by \011(11 p,11tics t0 a1 Loimni"t11li ndrlg~ts~ toi (omilain

I IN~(_' Im O il i 'i 'A~ sitti d cLIniI tim1 -ik imeL'lul l 'l110r thlui S ltIICO S 'LItltO,

Ime~iiim. e~iit ill k:h v ii'\ie 1,1\.I. 1ii. I "A 11,1 Vk ti i t n rot

It i

Page 39: ASAHUSETTS TECH CAMBRIDGE ARTIFICIAL F/S, UC · PDF fileboth the hardware and software protocols. It is intended to be the definitive documentation for Chaosne~ 1 9 11 3~ I ~ '7 1

Using Foreign Protocols in Chaosnet 34 Chaosnet

interfere with standard packets and so that the standard routing mechanisms may be used. Forexample, the MIT Architecture Machine uses UNC packets to communicate with non-stream-oriented 1/O devices such as graphic tablets. Here Chaosnct is being used as an I/O bus whichmay be attached to more than one computer. Numbers between 140000 and 177777 octal in theacknowledgement field of an UNC packet are reserved for such applications. Note that thisnumber is not part of the protocol; it is simply a hint about what a packet is being used for.Normally no program that is not specifically supposed to deal with such packets would everreceive one.

I )' :N(()N:,\M III I 10/ 15-JUN-81iOlW MO .... .- .. .. . .

Page 40: ASAHUSETTS TECH CAMBRIDGE ARTIFICIAL F/S, UC · PDF fileboth the hardware and software protocols. It is intended to be the definitive documentation for Chaosne~ 1 9 11 3~ I ~ '7 1

Chaosnet 35 -ardware Pirograinini ig I ) icuincntation

7. Hardware Programming Documentation

This section describes the Unibus version of the Chaosnet interface, which attaches to pdpllsand i.isp Machines. The interface contains one buffer which holds a receiked picket and a secondbuffer which holds a packet to be transmitted. Packets are moved between these butlers and thecomputer under program control. Direct memory access (I)MA) is not used: the small gain inperformance was not thought to be worth the extra hardware complexity. The usual performancepenalty of programmed 1/O is not incurred since the packct bullers can tranisfcr data al the fullspeed of the computer and neither busy waiting nor multiple interrupts are required.

To transmit a packet, successive 16-bit words of the packet are written into the outgoingpacket buffer. The last word to be written is the cable address of the destination of the packet,or 0 to broadcast it. The hardware is then told to initiate transmission. It wits until the cable isnot busy and this node's turn to transmit arriv-es, then shifts the packet out onto the cable. Aktthe completion of transmission transmit-done is set and the computer is interrupted. Iftransmission is aborted by a collision, transmit-done and transmit-abort are set and the computeris interrupted. As the packet is written into the outgoing packet buffer, a 16-bit cyclic redundancychecksum is computed by the hardware. This checksum is transmitted with the packet andchecked by the receiver.

'ro receive a packet, the clear-receiver bit is asserted by the program. The next packet on thecable which is addressed to this node, or is broadcast, will be stored into the incoming packetbuffer. After the packet has been stored, the computer is interrupted. The packet buffer willthen not be changed until the next clear-receiver operation is performed, gi ing the computer achance to read out the packet. If a packet appears on the cable addressed to this node while theincoming packet buffer is busy, a collision is simulated so as to abort the transmission. As apacket is stored into the incoming packet buffer, the 16-bit cyclic redundancy checksum ischecked, and it is checked again as the packet is read out of the packet blfl'Cr. Ihis provides fullchecking for errors in the network and in the packet buffers.

The standard interrupt-vector address fbr the Chaosnet interface is 270. The standard interruptpriority level is 5. The standard Unibtis address is 764140. These are the device registers:

764140 ('ommnd/Status RegisterThis register comtains a number of bits, in the usual pdpl1 style. All reld/write bits areinitiali/ed to ero on power-up. Identified by their masks, these are:

I 'Iimer Interrupt I 'nablc (read/w rite). 1:1nables ii terrupis from the interval tinierprescnt in some versions of the interface (not deo' ribed here).

2 loop Iick (read/write). If this bit is 1. the caible and trailmceiker are not usedand the interface is lo ed back to itself. 'IliS is for modimiiteliance.

4 Spy (reNd/w rite). If lhii hit is 1, tie inicifice ill receive ill pickets icgaidlessol" tlir destillation. 'Ii , i,, k'or maintenance and lctwo k ni iiioi in.

10 ('le.ir Receiver (wiite (ll). Witilig a I i10 this bit miis Rceiv 0I one and

eili~l~c the recciC'l to nl ii\e miilicr packet.

20 I'icm wl Interrupt I:iiil.bli. (read/rite). I1 t' .eIC J)()Mo ;iild Rei'C IiierruptliNiuI'h' ,11 e tilh I. VI piiIll i0 iirJUNtl81d.

I l.1,:\l()I V, \\11U 1 0' I1t -;.JIt.N 81

Page 41: ASAHUSETTS TECH CAMBRIDGE ARTIFICIAL F/S, UC · PDF fileboth the hardware and software protocols. It is intended to be the definitive documentation for Chaosne~ 1 9 11 3~ I ~ '7 1

Hardware Programming Documentation 36 Chaosnet

40 Transmit Interrupt Enable (read/writc). If Transmit )one and TransmitInterrupt Enable arc both 1, the computer is interrupted.

100 Transmit Abort (read only). This bit is I if the last transmission was aborted,by a collision or because the receiver was busy.

200 Transmit Done (read only). This bit is set to 1 when a transmission iscompleted or aborted, and cleared to 0 when a word is written into the outgoingpacket buffer.

400 Clear Transmitter (write only). Writing a 1 into this bit stops the transmitterand sets Transmit Done. 'T7his is for maintenance.

17000 Lost Count (read only). ihese 4 bits contain a count of the number of packetswhich would have been received if the incoming packet buffer had not beenbusy. Setting Clear Receiver resets the lost count to 0.

20000 Reset (write only). Writing a I into this bit completely resets the interface, justas at power up and Unibus Initialize.

40000 CRC Error (read only). If this bit is 1 the receiver's cyclic redundancychecksum indicates an error. This bit is only valid at two times: when theincoming packet buffer contains a fresh packet, and when the packet has beencompletely read out of the packet buffer.

100000 Receive Done (read only), A 1 in this bit indicates that the incoming packetbuffer contains a packet.

764142 My Address (read)Reading this location returns the network address of this interface (which is contained in aset of DIP switches on the board).

764142 Write Buffer (write)Writing this location writes a word into the outgoing packet buffer. The last word writtenis the destination address.

764144 Read Buffer (read only)Reading this locatiol reads a word from the incoming packet buffer. '[he last three wordsread are the destination address, the source addIess, and the checksum.

764146 Bi[ ('ount (read only)This locationi cottains the numhcr of hits in thc ilcoming packet buffer, minus one.Afker the whole packet has been read out, it will contait 7777 (a 12-bit minus-one).

76,1152 Slart I Uilsmi .sin (read only)tc;1ding this location initiatcs transmission of the packet in the outgoing packet huffer.Ilhe Ilie lo.ad is (ie iletwork addrcss of thi interlaIce. This mlethod ll m. ingtranmission fnay sceir strange, but it makes it cxier l'or the haldware to get the source,dthc',s in to the packet.

I '~.~ltn )".2\.llll~101l:ihNX

Page 42: ASAHUSETTS TECH CAMBRIDGE ARTIFICIAL F/S, UC · PDF fileboth the hardware and software protocols. It is intended to be the definitive documentation for Chaosne~ 1 9 11 3~ I ~ '7 1

Chaosniet 37 ic H S Implementation

8. T~he ITS Implementation

8.1 System Calls

Note that tile NETWRK subroutine package, page 42, provides aI convenlient interface to mostof these systemn calls for thle assembly-language programmer.

8.1.1 Opening 1/O Channels

Since 11S I/O Channels arc unidirectional, a Chaosnct connection is represented by a pair ofchannels, one for inpu)Lt and one for output. Operations that are not inhcrerulx directional, suchas finding out thle state of the connection, may be done onl either channel (it makes nodiff'erence).

Unlike every other device, you do not obtain these channels with the OPEN system call.Instead a special system call, CHAOSO, is provided. This does not open a Connection; it simplygives you a pair of' channels and a potential connection, in the Closed suite, %hich can he openedby transmitting a packet (an RF-C for instance) through the output channel.

CHAOSO takes three arguments: the input channel number, thle ou~tput channel number, andthe receive window size. If either channel is currently open it is closed first (jst aIs With OPEN).CHAOSO returns nio values, Error 0 (device full) is signalled if the s.ystem's comnection table isfuill.

8.1.2 Input and Output

Input and outputE can be done on a Chaosnect connection in termis of either packets or 8-bitbytes. 8-bit byte 1/0 is Usually done with thie SlOT system call: thle lOT systeml call or thle lOTitwo may also he used-the channel belba~ s as if it had been opened in unit mode. 8-bit byteouitput is collected by the systemI into packets containing thle Imaximum.1 allowed niumbehr of bytes;when a packet is full it is transmitted with the standard dlata opcode (201). U ntil a l'oll packet'sworth of bytes have heef) output nothinej kk ill be tranismiitted unle1ss Lihe FORCE systein call isuised. 8-bit input Con11eS from packets with the dat opcode (200). If an I OU packet is received,the standard cud-oh-file behavior "ill occo r-I OT %0il return thle 1:01[ chlaracter (- I-.3) and SlOTwill return with af non-zcro residualil byte c1111t. 11' ,onlc other kind of packet is, received, an 110Cerror will he signal led (see below). It' PKTIOT (scc below) is used to reaid out a noii-dLita packet.Streaul input my he coritinued past it.

Bit 1.4 in the control bits is "'don't hang'' mode for both input aind otput. When SlOT isdone %iih this bit ',pccificd, and no inputLI is tV-IhlC Or (ic outputII Nkindow is 111ll, It will siml~yreturn wkithouit iriii~lbi ring thie fuill fliIIIibcr of' bl is specified. I le li~to-polio' .ii11A byte-couintargumnent.- ito SlOT ilie ii11ilktd past the bI tes 111A were traiusk'i red. Whon input lor I, done in

Shld not 1w onk uI in 'it l1iv nlog' riIulc e it has nio \%Iny ill indicate ililit it did niot tr',uiis1lit

Mliythifir,. 11 :1 11011 (11. I )A dc i'; ICCCiI'-l "f' li ha Ifude ' ill belieW 1W 1oe112if Terwasin, 11 inpl i i.iil.

I )SuK:NI()Wi:A.Mll\ 1ll 15-.1,1N-8 I

Page 43: ASAHUSETTS TECH CAMBRIDGE ARTIFICIAL F/S, UC · PDF fileboth the hardware and software protocols. It is intended to be the definitive documentation for Chaosne~ 1 9 11 3~ I ~ '7 1

System Calls 38 Chaosnet

Before doing 8-bit byte I/O, the user program must open a Chaosnet stream connection bytransmitting and receiving the appropriate RFC, LSN, or OPN packets and following the protocoldescribed on page 21. Ibe NETWRK subroutine package can be useful for this.

Input and output can be done in terms of packets by using the PKTIOT system call. The firstargument is the I/O channel number and the second is the address of the packet to betransmitted or of a 126.-word buffer to contain the packet to be received. No values are returned.

Input PKTIOT will return data packets and the following types of control packets: RFC,OPN, FW), ANS, C1.S, LOS, EOF, and UNC. The other types of control packets are for theNCP's internal use only. If no input packets are available, PKTIOT will wait. If the connectionis in a bad state, an IOC error will be signalled. Ibis is discussed in the next section.

Output PKTIOT will accept data packets and CI.S, BOF, and UNC packets if the connectionis open. Transmitting an UNC packet when the connection is closed puts it into the foreignProtocol state. RFC, LSN, OPN, FWI), and ANS packets may be transmitted if the connectionis in the appropriate state. Transmitting a bad packet type or transmitting when the connection isin the wrong state signals an IOC error (see the next section). Normally the user sets only theopcode and number of bytes fields in the packet header; PKTIOT fills in the rest. When sendingan RFC, the user specifies the destination-host field and the system remembers it. When sendingan UNC, the user specifies everything but the source host and index.

Note that PKTIOT does not synchronize with 8-bit byte I/O. If a partial packet's worth ofbytes have been output, and then a packet is output with PKTIOT, that packet will get ahead ofthose bytes. rhe FORCE system call can be used to change this. If a partial packet's worth ofbytes have been input, and then a PKTIOT is done, those bytes will remain available to thestream and PKTIOT will read the next packet after them.

8.1.3 Interrupts

I/O (second-word) interrupts occur if enabled when an I/O operation formerly would havehung but now will not. In other words, an interrupt occurs on the input channel when a packetarrives while there are no input packets available, if the packet is of a type that input PKTIOTwould return. An interrupt occurs on the output channel if the window is full and an,|cknowledgement arrives which makes some space in the window. Completely interrupt-drivenI/O can easily be programmed for the Chaosnct, using the WHYINT system call (see below).

An interrupt also occurs on the input channel when the connection state changes.

A %PIIOC iil-rtiopt (alo ;illfed all ''OC err'o') tci.is if amy of ai %ariety of illegal)ei( )ations i,; l rill i tied. IOC Cri'or 3 ( n -rec werablle (t,1 a e rror) is signl tled if a packet is

tri-ismiiucd xith PKTIOT and it has an illegal si/e or op-l. il the header. IOC crrior 12 octal(.l linn I ill illcgal nll odc) is signldled if byte or p,ike input oi- oiltput is done with theumlnectlini ill Ihe wronlig SLate, or if byte input is dohc iiid a packet other than a nornlal data

p'm kvt or .0 ) 1. is 111- 1d.

I )SI.:M0( ) IAM] I .l 107 15-JLJN-81

Page 44: ASAHUSETTS TECH CAMBRIDGE ARTIFICIAL F/S, UC · PDF fileboth the hardware and software protocols. It is intended to be the definitive documentation for Chaosne~ 1 9 11 3~ I ~ '7 1

Chaosnet 39 System Calls

8.1.4 Miscellaneous Operations

h'lhe CLOSE system call. or the CLOSE uuo, may be used to close the 1/O channcls and theconnection. When both channels are closed, all buffers and other intbrMiation associated with theconnection arc immediately discarded. If the connection is open a CLS packet is transmitted.You can also transmit a CI.S yourself, with an explanatory message in it, before doing theCLOSE.

[he FORCE system call, or the .NETS 1.1o, can be used on an output channel. If there isbuffer containing a partial packet's worth of 8-bit byte output, it is transmitted as a packet of lessthan the maximum size.

h'le FINISH system call first does a FORCE and then waits for all packets that have beentransmitted to be acknowledged.

'[he RESET system call, and the RESET uuo, are ignored, as on most devices. 'lhe RCHSTand RFNAME system calls, and the .RCHST uuo, return the standard inftrmation for a non-filedevice, with device-name CHAOS:. No device-dependent information is returned.

The WHYINT system call, given either the input channel or the output channel of a Chaosnetconnection, returns a lot of usef'ul device-dependent information about the connection:

val I The device code, which is the valuc of the symbol %WYCHA.

,ial 2 The state of the comiection. Symbols for the connection states start with the prefix %CS:

%CSCLS Closed (or never opened).

%CSLSN l.istening for an incoming RFC.

%CSRFC RFC received while listening: neither accepted nor rejected yet.

%CSRFS RFC sent, awaiting acceptance, rejection, or answer.

%CSOPN Open.

%CSLOS Broken by receipt of a I OS packet.

%CSINC Broken by "incomplete transmission" (no response from foreign host for alonig time).

%CSFRN Using a foreign protocol, encapsulated in UNC packets.

val 3 "lhe left half is the number of' available input packets. 'Ibis does not count out-of-orderpackets. Ihis number is increased by one if there is ht, cred inuput available for 8-bitbyte input. This mumber is zero if' the Chaosnet connection is directly connected to aSTY (see STYNET).

The right half is the number of ,lilpUt packcts which have not yet been acknowledgedand henCe arc ICtClpying, 'pace ill the wlindOw.

,al 4 '1 lie 1l li f is the receive %vinimw J/, ild the ihi half iN Ih thr:iisinit %A ildOw si/e.

Val 5 Vahc I1. 1 h.df is th' inptlll hto'I 1uun1ht'r ,ulud th ti,'h l 1,lf is 0h 0uimptUt ChannelIuluulhurl. 11,"c 'nIub'1twls aie -1 il hK (hlcwI I,, hwc (:1i. l or I.0PUSIlctl.

I1)SK:07)t)N-\ NI I., II)] 15 .IUN-81

Page 45: ASAHUSETTS TECH CAMBRIDGE ARTIFICIAL F/S, UC · PDF fileboth the hardware and software protocols. It is intended to be the definitive documentation for Chaosne~ 1 9 11 3~ I ~ '7 1

Utility Programs 40 Chaosnet

Tilie NETBLK system call works similarly on the Chaosnet as on the Arpanct. The first

argument is a channel number (input or output). The second argument is a connection state code.The third argument, which is optional, is a timeout in 30ths of a second. If it is not immediateit is modified. NETBLK hangs until the connection state is different from the specified state orthe timeout (if specified) elapses. Two values are returned: the current state of the connectionand the amount of time left.

The STYNET system call works similarly on the Chaosnet as on the Arpanet. It allows aChaosnet connection and a STY (pseudo terminal) to be connected together so that aTclnet/Supdup server program can provide efficient service. ihe arguments are:

arg 1 The STY channel number.

arg 2 'he Chaosnet input channel number to connect it to, or -1 to disconnect it.

arg 3 The Chaosnet output channel number. This is not actually used on the Chaosnet.

- arg4 Up to three 8-bit characters, left-justified, to be transmitted when an output-reset is doneon the terminal. These characters are protocol-dependent. If any unusual conditionoccurs, including input of a byte with the high-order bit on from the network, the STYwill be disconnected from the Chaosnct channel and the user will be interrupted. It isillegal to do I/O on any of the involved channels without disconnecting them from eachother first.

The CHAOSO system call allows the ATSIGN CHAOS program, described below, to peek atthe queue of' pending RFC's. It takes one argument, which is the address of a 126-word buffer.'lhe first RFC packet on the queue is copied into this buffer and moved to the end of the queue.If the queue is empty, the system call takes the error return.

8.2 Utility Programs

The K mode in the :PEEK command gives one line of information for each Chaosnetconnection in existence on the local machine, lists the number of packet buffers in existence andfree, and lists any queued RFC's (see the following section). Packet buffers are dynamicallyallocated in groups of 8 from system memory. Packet buffers in existence and not l'ree may be inuse to contain packets being transmitted to or received from the hardware, unreceipted outputpackets, or input packets not yet r,!ad by the user program.

M[he information about a Chaosnet connection printed by PEEK consists of:

IDX h'lc connection index number (not including the tniquiiltion bits).

USR 'Tlie user index or ITS job number of the tio process wlicl owns the connection.

I JNAME

JN%\ME 'lhe name of the user process which owos the connection.

G FATE Ihe state of the connetlion. 'his is one o,' the statc, listed in section 4.6, page25. abbreviated to six chracters. .OWI.VL ,mnt Ihc fo l4ip':n iwtocol state.

1F '*lhc ntinher of input ptckets buflcred and ii ailable to be ca I by the user

I'llIF llie numnhcr of input ). (kes,; butlcred it not %el a' tlil'hic to Ihe iw!1' pro'esstIh('t . ih.y are owi oF orter. om' , lil i I f kts 11e 1 s,iuc': \W 1 i C: ,y Jlulive

I )!1\.M () , A 1 0 17 '-IN.1

Page 46: ASAHUSETTS TECH CAMBRIDGE ARTIFICIAL F/S, UC · PDF fileboth the hardware and software protocols. It is intended to be the definitive documentation for Chaosne~ 1 9 11 3~ I ~ '7 1

Chaosnet 41 Utility Programs

these packets will become available.

NOS The number of output "slots" available in the window. The user process maysend this man5 packets before it will have to wait for an acknowledgement.

ACK The number of received packets which should be acknowledged but which havenot yet been. This will not stay non-zero for more than a half second, since if itis non-i.cro an STS will be transmitted.

R WIN The window size for the incoming half of this connection.

WIN T The window size for the outgoing half of this connection.

FOREIGN ADDR'l'he host name and index number of the other end of this connection. The =command switches between host names and host numbers.

FLAG One or more single-letter flags indicating special things about the connection. Thefollowing flags exist:

C 'he connection is half-closed (one of its I/O channels has been closed andthe other remains open).

F The connection is turned "off' as far as die interrupt side of the NCP isconcerned. No packets will be received or tranqmitted.

I The connection has an input buffer for stream (non-packet) input.

0 The connection has an output buffer for stream (non-packet) output.

S An STS packet needs to be sent.

T The connection is connected to a STY. In other words it is an incomingTelnct or Supdup connection and the system is pro~iding the data transferbetween the connection and the pseudo terminal.

The :CHASTA command is a long-winded version of the above. It prints several lines ofinformation about each connection dat exists, including the number of the next packet to begiven to the user, die number of the next packet to be output by the user, and the number ofthe last packet acknowledged in each direction.

The :CHARFC command, given a host name and a contact name in the command line, willopen a connection and print whatever conics back (refusal, simple transaction, or any data thatemerge froin ;i strear colnection). The contact name may or couise be tblloed hy ;I ,pace andarguments. This command can be usefi in connection with the STATUS protocol, to see if ahost is up (it will print its name follovcd by some garbage characters), and in coniection withthe PULSAR protocol, to turn pulKrs (im and olf.

The :CHATST c(minnan(d piovides i, vdiieiv of simple (C'hliosict im ipulating commands. Run

- it and type ? bir ;I list of the coini;iiid,,. ih1 II (h!ost.,t) comanlllld 1i:1% be te most useful; it

uses the SrATLIFS protocol to get Mctc .il, otOrM.60iai from a hot and prints it llicclV.

Th lie :-1osr cotillmi .i i thc 11,111c f , t ill tltc oinii.iud line. ho ks Ip thi host ill'I le l host l.hi c .t1d plil ; AhL i, l u:,In'. hit, llt it. i,lli Ii i, us n iuciic , hi,'. Ihis

"",mk,, l'r hluIo , mo II nu',,%iks. I HI, . llAl oioiill,oi1d l oiii, , i l t ' ill tic ho t oil-. ( 'haosnlet.

10/

Page 47: ASAHUSETTS TECH CAMBRIDGE ARTIFICIAL F/S, UC · PDF fileboth the hardware and software protocols. It is intended to be the definitive documentation for Chaosne~ 1 9 11 3~ I ~ '7 1

F __...._.___ _ _

Server Programs 42 Chaosnet

8.3 Server Programs

When an RFC is received for a contact name for which there is no outstanding LSN, theRFC packet is saved on a pending-RFC queue and a new process is created and made to run theprogram in the file SYS:ATSIGN CHAOS. 'lbis program uses the CHAOSQ system call to findout the contact name of the RFC. The contact name name i., truncated to six characters if it islonger. If a file named DSK:DEVICE;CHAOS name exists, that file contains the desired serverprogram; it is loaded into the server process. When the s.erver process is started, register 0contains the contact name in sixbit and channel 1 is still open to the program file. The serverprogram must do a listen for its contact name, open the connection, log in, and so forth.

Thus a server for a new protocol can be added simply by putting a link on the DEVICEdirectory. Ibis directory is also used for Arpanet servers and for ITS I/O device servers.

If no file is found, a file named DSK:DEVICE;CHAOS DFAULT is loaded if it exists. If itdoes not exist either (which is normally the case) the RFC is ignored and the server process killsitself. After a while the system will refuse the RFC by sending bact a CLS unless someonecomes along and listens for it.

8.4 Subroutine Packages

The file SYSTEM;CHSDEF > can be .INSRT'ed into a Midas program to define symbols forthe format of a packet, die packet opcodes, and the states of a connection. The symbol prefixesare %CO for opcodes, %CS for states, $CPK for packet-format byte-pointers, and %CP forpacket-format values.

The file SYSENG;NETWRK > can be .INSRT'cd into a Midas program to provide a library ofsubroutines for opening connections, listening for requests for connection, analyzing networkerrors and printing useful messages to the user, and accessing the host-name table(SYSBIN;HOSTS2). All system programs that use the Chaosnet do so with the aid of these-ubroutines. NETWRK supports both Chaosnct and Arpanet. Documentation is provided inomments at the beginning of the file.

I )SK:Mt)( )N:AMII-R 107 15-i -

Page 48: ASAHUSETTS TECH CAMBRIDGE ARTIFICIAL F/S, UC · PDF fileboth the hardware and software protocols. It is intended to be the definitive documentation for Chaosne~ 1 9 11 3~ I ~ '7 1

Chaosnet 43 "ihe TOPS-20/r IT..FX Implementation

9. The TOPS-20/TENEX Implementa t ion

A Chaosnet connection is represented by a JFN obtained from the CHA: device. Thestandard I/O operations can be performed on such it JFN, in which case the system will open aChaosnet stream connection and transfer 8-bit bytes in both directions. When a Chaosnctconnection is used in this way. it is compatible with the rest of the TOl'S-20 file and 1/O system.

Alternatively, special opeiations can be used to send and receive packets and do otherChaosnet-specific operations on a Chaosnet JFN. These are described below.

For more information, see [CPR].

9.1 Opening Connections

A (potential) Chaosnet connection is represented by a JFN. When the JFN is opened, anactual 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 atthe other end of the connection, or a null string if it is desired to listen for an incoming RequestFor Connection rather than initiating a connection. The extension (filetype) is normally thecontact name; some special cases are described below. Use of * nanes and JFN stepping is notpermitted. The directory, generation (version) number, and semicolon attributes are ignored ifpresent.

When the JFN is opened (with OPENF), normally the system will wait for the connection toopen up; a user connection (nonblank filename) will wait for a response to be returned to itsRFC. and a server connection (blank filename) will wait for an RFC to come in to its contactname. If an RFC is refused or the foreign host is not up, OPENF will return an error. If datamode 6 or 7 is used with OPENF, it will return immediately, without waiting for the connectionto open. This is useful if you want to open several Chaosnet connections simultaneously, or ifyou want to determine the reason for f'ailure if the connection does not open; if the normal datamode 0 OPENF fails, the operating system will not let you read the CLS packet nor do the.MOERR opcration (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 die numberof characters in the contact name in liht left half, and the addrc.s of the contact iname in theright half. In listening mode (the filename is a null string), then if the extension is also null, thisJFN will listen to any RF[C that is not otherwise serviced. Privileges are required and only onejob at a time can (1o this. This mechanism is used by a system server proccs. If' the lilename isnull and the extension is a hyphen, the JFN is put in a special Inode for simple transactions;packet-level I/O may be used to transmit any number of RFCs and receive any response packets(ANS, FWI), LOS, or CIS).

When a JFN is thoscd A ilh CLOSfl, if it has an opcl coinot'tlill Ihc chld of-(Iatl prolocl is

fti.cI (al IV()I: p:m-ke cj. Imnsmiitii Mnd ita , inLmm wledw, nMClt is wailed), and then i (I S p',cketi- t.iiiiitiltd. tI Iii si (lm:vnplctcly itnmjhl, k'I1i1cdt 'CI: uircnitlv ni 1(01' is sent. ind .MOEOF('C I}' \A') Illn I bl, 'i.) II il1e 1i N i, il i' t> l"(ci\e' ,ld t', the lI( i , liwd 1v

,c.dimng a (i'( S.

l)%L:RlO( )',:,,\lllle I1 IS-hIJUN 81

Page 49: ASAHUSETTS TECH CAMBRIDGE ARTIFICIAL F/S, UC · PDF fileboth the hardware and software protocols. It is intended to be the definitive documentation for Chaosne~ 1 9 11 3~ I ~ '7 1

Stream Input and Output 44 Chaosnct

9.2 Stream Input and Output

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

On TOPS-20, but not T'enex, the SIBE, SOBE, DIBE, DOBE, SINR, and SOUTR JSYSesmay 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 databytes are transmitted. With a byte size of 7, the system converts between the ASCII code it usesnormally and the Lisp Machine character set, which is standard on Chaosnet. (This is not yetimplemented; 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 theChaosnet protocol by using the special operations described in the following section. Note thatstream I/O and packet I/O should not be mixed in the same connection, unless you know exactlywhat you afc 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 AC3returns the number of packet slots available in the output window in the left halt; and thenumber of available input packets in the right half. The symbolic names for the connection statesare as follows:

.CSCLS 'Ific connection is closed (or was never opened).

.CSLSN IThe connection is listening for an RFC.

.CSRFC An RFC has been received by a listening connection.

.CSRFS An RIC has been sent.

.CSOPN The connection is open.

.CSLOS The connection has been broken by a I.OS packet.

.CSINC I hc connection has beeun broken by Incomlplete T'ransinmission (no response fromthe other end for a long tinc).

.CSPRF This is the "pcrinaiint RIC" staic which is entered by GTJFN with a nullfil'ilanlc and al vxteiisilin of just a Ihyplh ll.

MroPf perfiln variety olf sl)cial operautions, with the JEN in AC1, ()ne of Ill' ltlowing"j tutu lintl uincs in A 2, 1n(d anl ,i'inimici i ail/ r ieinii ';ihi' in AC3.

.MSInS Scni t l)iapck&. AC3 toltiins hi. adiec',s olf lit first word ( it' ;iacket. An

elior relurn is taken ifi' t l olinoeiu i, in a hid siatc tiir the kind oh' pocket

I ",i . lt ( i) I,\MlIilR 107 15-JUN-81L A k I _ _.. . .. .

.-4 l l lll I II . . .... . . . . .... . .I . .. .. .. .... .. .. . ..I

I

Page 50: ASAHUSETTS TECH CAMBRIDGE ARTIFICIAL F/S, UC · PDF fileboth the hardware and software protocols. It is intended to be the definitive documentation for Chaosne~ 1 9 11 3~ I ~ '7 1

Chaosnet 45 Utility Programs

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 thepacket 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 F.OF packet.

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

.MOERR Returns the error message from a received CLS or I.OS packet. An error issignalled if no error message is available. AC3 is a string pointer to where to putthe error message: it is updated to point at the terminating null character whichmakes the message an ASCIZ string.

.MOACN Assigns PSI (interrupt) channels. The left half of AC3 is the channel number foroutput interrupts, and the right half is the channel number for input and state-change interrupts. Specifying -1 as a channel number disables interrupts. Outputinterrupts are signalled when the window is full and then an acknowledgement isreceived which makes some space so that more packets may be output. Inputinterrupts are signalled when the state changes, and when there are no inputpackets 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 windowsize 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 theChaosnet standard (488) on machines encumbered with an RSX2FI" front end.

.MOSRT Sets the RFC timcout period in milliseconds fromn AC3. The niaximuim is 262seconds.

9.5 Utility Programs

'There are two Chaosnet utility prugrins, bolb named CHASTA. One prints one line for eachconnection that exists, giving its stale, nnmlblhcr of inpul and output packets, " ho it is connectedto, etc. The oiher prints the STA'liI8 t)uulocol inliormtition iir eer host on the network,including the host nilil, wlhc it %M' 1;1,( np, ;ilmd itS IickLt thriuglIput ald c,, 10i C. Ullts. Ihisiiformnition is naintlamcd by a syslen (l;i, 'illmil plroess.

I S, :'1(i1N01klll; .Il 15-JUN-81

Page 51: ASAHUSETTS TECH CAMBRIDGE ARTIFICIAL F/S, UC · PDF fileboth the hardware and software protocols. It is intended to be the definitive documentation for Chaosne~ 1 9 11 3~ I ~ '7 1

Server Programs 46 Chaosnet

9.6 Server Programs

When an RFC is received for contaci-name, if no process is listening for conlact-nanme and

the file SYSTEM:CHAOS.conlact-name (or DSK:<SYSTEM>CHAOS.coniac-name on Tencx) exists,the server program contained in that file is run. The scrvcr program should open CHA:.(Vnlac1-tiame. This is implemented by the CHARFC program which runs as a dacmon job and opens

CHA:., the magic name which gets a copy of all unclaimed RFCs. Normally the server programis run in a freshly-creatcd job, and may log in if it wishes, but if the file is marked as ephemeral(the ";E" attributc), it is run in a subfork of die CHARFC job. l'phemcral servers should beused for protocols that don't involve a long-term connection.

The TELNET and SUPDUP servers attach their Chaosnct connection directly to an NVT, just

as the corresponding Arpanct servers do.

When the system starts tip. the file SYSTEM:HOSTS2.BIN (or DSK:<SYSTEM>HOSTS2.BINon Tencx) is read in and used to initialize the host name table inside the system used by GTJFN.'his is the I'frS'OPS-20/WAI'|'S standard multi-network host table.

-AM I 11 1.101

Page 52: ASAHUSETTS TECH CAMBRIDGE ARTIFICIAL F/S, UC · PDF fileboth the hardware and software protocols. It is intended to be the definitive documentation for Chaosne~ 1 9 11 3~ I ~ '7 1

Chaosnet 47 The lisp Machine Implementation

10. The Lisp Machine ImplementationLisp Machine Chaosnet support consists of a set of Lisp functions and data-structure

definitions in the chaos: package. There are three important data structures. A conn representsa connection. A pkt represents a packet. A stream is a standard 1/O stream which transmits toand receives from a connection. The details of these data structures are described later.

There arc two processes which belong to the Chaosnet NCP. thc receiver process looks atpackets as they arrive from the network. Control packets arc processed immediately. )ata packetsare put on the input packet queue of the connection to which they are directed. The backgroundprocess wakes up periodically to do retransmission, probing, and certain "background tasks" suchas starting up a server when an RFC arrives and processing "connection interrupts" (describedbelow).

10.1 Opening and Closing Connections

10.1.1 User-Side

chaos:connect host contact-name &optional window-size timeoutOpens a stream connection, and returns a conn if it succeeds or a string giving thereason for fhilure. host may be a number or the name of a known host. con/act-name isa string containing the contact name and any additional arguments to go in the RFCpacket. If window-size is not specified it defaults to 13. If timeout is not specified itdefaults to 600 (ten seconds).

chaos:simple host contact-name &optional limeoutTaking arguments similar to rhose of chaos:connect, this performs the user side of asinple-transaction. The returned value is either an ANS packet or a string containing afailure message. The ANS packet should be disposed of (using chaos:return - pkt, seebelow) when you are done with it.

chaos: remove-conn connMakes corn null and void. It becomes inactive, all its butfered packets are freed, and thecorresponding Chaosnet connection (if any) goes away.

chaos: close con &optional reasonCloses and removes the connection. It it is open, a Cl S packet is sent containing thestring reasmn. )on't use this to reject RFC's; use chaos:reject for that.

chaos:open-foreign-connection /o/ indeCv &optioiial pki-alhoalion dIstingid. hed-portCreates .i corn which aiy be irced to transmit and receive foreign protocols cncapsulatedin INC );,'kCls. ho.,t and tnd,-.karc theie dc.linationl ,ddr6'1, for packelt s,'im withrh;io5:sod imic -"kt. plo-'olh'o ti l is Ihe' "Window si/c'. i.e. ihc iol;mxilntlinmmm mi nmktr olfi1ptlit pLkt'. l ' 11i 1 Iihmnyv c htllkId. II dcl ilts to 10. It //,,lu',:uon ,?i olt is ipllit'd.t Iott uilx is st't to iL. lihi' Is flocssm: y (0mI ttpl lo(ou , %41141 dI 'ir d " lilt irt min ', of

pulikutirit idt's mmhcrs

I)SK:MtOON:AlIlFlY 117 V-IUN-81

Page 53: ASAHUSETTS TECH CAMBRIDGE ARTIFICIAL F/S, UC · PDF fileboth the hardware and software protocols. It is intended to be the definitive documentation for Chaosne~ 1 9 11 3~ I ~ '7 1

Connection States 48 Chaosnet

10.1.2 Server-Side

chaos :1 Isten contact-name &optional window-size wail-for-rfcWaits for an RFC for the specified contact name to arrive, then returns a conn whichwill be in the RFC Received state. If window-size is not specified it defaults to 43. Ifwait-for-rfc is specified as nil (it defaults to t) then the conn will be returned immediatelywithout waiting for an RFC to arrive.

chaos: server- M 1st VariableContains an entry for each server which always exists. When an RFC arrives for one ofthese servers, the specified form is evaluated in the background process- typically itcreates a process which will then do a chaos:listen. Use the add-initialization functionto add entries to this list.

chaos:accept conncunn must be in the RFC Received state. An OPN packet will be transmitted and connwill enter the Open state. If the RFC packet has not already been read with chaos:get-next-pkt, it is discarded. You should read it before accepting if it contains arguments inaddition to the contact name.

chaos:reject conn reasonconn must be in the RFC Received state. A CLS packet containing the string reason willbe sent and conn will be removed.

chaos:answer-strIng conn stringconn must be in the RFC Received state. An ANS packet containing the string string willbe sent and conn will be removed.

chaos:answer conn pktconn must be in the RIC Received state. pkt is transmitted as an ANS packet and connis removed. Use this function when the answer is some binary data rather than a textstring.

chaos: fast-answer-strlng contaci-nane stringIf a pending RFC exists to contact-namne, an ANS containing siring is sent in response toit and t is returned. Otherwise nil is returned. This function involves the minimumpossible overhead. No conn is created.

10.2 Connection States

chaos:state connReturns the current state of the connection, as one of the following symbols:

chaos:inactive-state A conn which does rot correspond to any Chaasnctconnection.

chan:s:open -state An open connection.

chaos:rc - sent.- state An RIFC has hcen iransmitted and no respoi ; has yet

becii receivcl.

I )Sl.:N(N:AMIlFI{ 107 15-JUIN-81

Page 54: ASAHUSETTS TECH CAMBRIDGE ARTIFICIAL F/S, UC · PDF fileboth the hardware and software protocols. It is intended to be the definitive documentation for Chaosne~ 1 9 11 3~ I ~ '7 1

Chaosnet 49 Stream Input and Output

chaos: answered -state An ANS has been received.

chaos: cls-received -state A CI.S has been received.

chaos:Ilos -received -state A LOS has been received.

chaos:host -down -state The connection is in the Incomplete Transmissvion state;communications With thc foreign host have broken down.

chaos:listening -state A I.SN has been "transmitted" and the connection isawaiting an RFC.

chaos:rfc -received -state An RFC has been received while listening and has not yetbeen responded to.

chaos:foreign -state TIhe connection is being used with a foreign protocolencapsulated in UNC packets.

chaos :wait conn state ftmeout &optional whostateWaits until thle state of conn is not the symbol state, or until ineout 6Oths of a sccondhave elapsed. If the timeout Occurs, nil is returned-, otherwise t is returned. whostate isthe process state to put in the who-line; it defaults to "net wait".

10.3 Stream Inputt and Output

chaos:stream connCreates a bidirectional stream which accesses conti, which should be open as a streamconnection, as 8-bit bytes. In addition to the USuL3 1/O operations, the following specialoperations are supported:

force-output Any buffered Output is transmitted. Normally output is accumulated untila full packet's worth of bytes are available, so that maximum-size packetsare transmitted.

:finish Waits until either all packets have been sent and acknowledged, or theconnection ceases to be open. If successful, returns tC if the connectiongoes into a bad state, returns nil.

:eof Forces out any buffered output, sends an EOF packet, and does a :finish.

:clear-eof Allows you to read past an EOF packet onl input. liachi :tyi will return nilor signal the specified eof error until a :clear-eot is done.

:close Send a CLS packet and remove the connection.

111.4 Pa~cket Iiput and OMu

In1put andl outpu)[t onl c Chaosnci ciilicttion can be done at the '% hole-packet level, uising thelu iiciions in tbis section. A Packet is tel)w seiiied by a pkt data StRiure . Allocation of pkts isconntrollcd bv tile sy,ciii echl pkt thati it iks von mnust he gijciu back. 'Ilicic alc finctijns tocomnit~' hvt \ccn plits muid Ati~'s I\ kt ik ani art- 161) array coma in iniz the Iacket heaoder and(Lim;: the rchoosimrji data word in pkt'ib (-cliint ()Ff th lrixi' k the hirqt l(6bit dta word. 'Ihleade-r of a JIMcniir LOIJV ,Iiun ol1111 01' 111 W-hJ) ilic sv.Steiun

I~0- 1k:~iNA lRII5-.I UN -81

Page 55: ASAHUSETTS TECH CAMBRIDGE ARTIFICIAL F/S, UC · PDF fileboth the hardware and software protocols. It is intended to be the definitive documentation for Chaosne~ 1 9 11 3~ I ~ '7 1

Packet Input and Output 50 Chaosnet

chaos pkt-opcode pktAccessor for the opcode field of pki's header. For each standard opcode a symbol existsin the chaos: package, consisting of the standard 3-letter code and a suffix of "-op",chaos:rfc-op for example. 'l'he value of the symbol is the numeric opcode.

chaos:pkt-nbytes pktAccessor for the number-of-data-bytes field of pki's header.

chaos:pkt-strlng pktAn indirect array which is the data field of pki as a string of 8-bit bytes. The length ofthis string is equal to (chaos:pkt-nbytes pkt).

chaos:set-pkt-strlng pkt &rest stringsCopies the strings into the data field of pkt, concatenating them. and sets (chaos:pkt-nbytes pkt) accordingly.

chaos :get-pktAllocates a pkt for use by the user.

chaos: return-pkt pktl)eallocates a pkt.

chaos:send-pkt conn pki &optional (opcodechaos:dat-op)Transmits pki on conn. pkt should have been allocated with ctaos:get-pkt and then hadits data field and n-bytes filled in. opcode must be a data opcodc (200 or more) or iOF.An error is signalled, with condition chaos:not-open -state. if con is not open.

chaos:send-string corn &rest stringsSends a data packet containing the concatenation of strings as its data.

chaos: send-unc-pkt conn pki &optional pki-nunbcr ack-numberTransmits pkt, an UNC packet, on conn. The opcode, packet number, and acknowledgenumber fields in the packet header are filled in (the latter two only if tie optionalarguments are supplied).

chaos :may-transmit cornA predicate which returns t if there is any space in the window,

chaos : finish conn &optional (whosiate "Net Finish")Waits until either all packets havc been sent and acknowledged, or the conncction ceasesto he open. If successfil, returns t: if thC connectiOn goes into a had state, returns nil.who.tatte is the process state to displiy in the who line "hile waiti|ng.

dlaos :got- nex t- pkt con &optional (no-htm/:-p nil)ReturnIts the flex[ inpuit p;cket from cot,. When you are done ith Ithe packet you ,mustgive it hack to the sys¢,n wilt chaos:;ctl rn -pkt. This ciin etimn all RI:(. 'I S, orANS packet, in addition to( data, INt, (1" 1""1 . I' no hang-1) is t, nil %ill ' ichtrittidif" there arc nto packets av-ilablie or the cot(h ioi i i a had *;1rtw. ()thl'twi'a' r11,o

v ill he sig itnllcd it theC (timimelion i, ill a1 had '-lltk', with o niditioi n;mmc (:I io-;:host-dohwn. choms:Ios-received state, ofr chaos:rr ol Ott closd conneclior. ii nu p;ketsale ,,aiImhle arod no-hangp is nil, chrtos:get 111'A -I)kt will wait 10r pItckcts to conic in

I idl ,IOt ; \N,11 1 R 107 I. IIIN-4I

Page 56: ASAHUSETTS TECH CAMBRIDGE ARTIFICIAL F/S, UC · PDF fileboth the hardware and software protocols. It is intended to be the definitive documentation for Chaosne~ 1 9 11 3~ I ~ '7 1

Chaosncc 5 Connection Interrupts

or the statc to change. '[he process state in the who-line is "NETI'.

chaos: data-avalable connA predicate which returns t if there any input packets available from conpi.

10.5 Connection Interrupts

chaos:interrupt-function conT[his attribute Of at conn is a Function to he called in the background process when certainevents Occur on this connection. Normally this is nil, which means not to call anyfunction. but YOU call use setf to store a function here. Since the function is called inthe Chaostiet background process, it should not do any operations that might have to waitfor the network, since that could permianently bang the background process.

TIhe fulnction's first argument is one of thle following symbols, giving the reason for the"interrupt". 'The function's second argument is conn. Additional arguments may bepresent depending on the reason. Tlhe possible reasons are:

:input A packet has arrived for the connection when it had no input packetsqueued. It is now possible to do chaos:get -next- pkt without having towait. There are no additional arguments.

:output A\n acknowledgemnitt has arrived for the connection and made space inthle window when formerly it wa, rull. Additional Output packets maynow be transmitted with chaos:send-pkt without having to wait. 'Ilhercare no additional arguments.

:change-of -state'The state of the connection has changed. '[he third argumient to thefunction is thle symbol for the new staite.

chaos:read-'pkts conSome interrupt functions will want to look at the queued input packets of a connectionwhen they get it :input interrupt. chaos: read -pkts returns thle first packet available forreading. Successive packets can be found by following chaos:pkt-link.

chaos:pkt-link pkiLists of packets in the NCP are threaded together by storing each packet in) tilechaos:pkt- link of its predecessor. '[he list is terminated with nil.

10.6 Iniformnationi mid Control

chaos host data &optional ho.51bst may hie a number or a knob Ii host none. anl deflmlts Io thle local hlost. Iw\o valuesle leturnecd. '11wi first v'alltc is ti1C host 11,111e and thle second is tile bus)t nntmi11Cr. II' the

ho~st is at numbe1hr I)(t ill the t-1htk. It is .islcd its wnme using thle STARK'J8 pittoul: it' notespuiie is iecci\d thw imic ''tlitonown"' is, rturnelId,

Page 57: ASAHUSETTS TECH CAMBRIDGE ARTIFICIAL F/S, UC · PDF fileboth the hardware and software protocols. It is intended to be the definitive documentation for Chaosne~ 1 9 11 3~ I ~ '7 1

Information and Control 52 Chaosnet

hostat &rest hostsInterrogates die specified hosts, or all known hosts if none are specified, with theSTATUS protocol and prints the results in columns as a table.

chaos: pri nt-conn conn &optional (short )Prints everything the system knows about the connection. If short is nil it also printseverything the system knows about each quuced input and output packet on theconnection.

chaos:prtnt-pkt pkt &optional (shortnil)Prints everything the system knows about the packet, except its data field. If short is t,only the first line of the information is printed.

chaos: print-all -pkts pkt &optional (shortt)Calls chaos:print-pkt on pkt and all packets on the threaded list emanating from it.

chaos:statusPrints the hardware status.

chaos : resetResets the hardware and software and turns off the network.

chaos: assure-enabledTurns on the network if it is not already on. It is normally always on unless you call oneof these finctions.

chaos :enableResets the hardware and turns on the network.

chaos:dlsableResets the hardware and turns oif the network.

I ),. :M(N:,III.I 107 I'-JUIN 81

Page 58: ASAHUSETTS TECH CAMBRIDGE ARTIFICIAL F/S, UC · PDF fileboth the hardware and software protocols. It is intended to be the definitive documentation for Chaosne~ 1 9 11 3~ I ~ '7 1

Chaosnct 53 '[he VAX/V MS Implementation

11. The VAX/VMS ImplementationT his decribes the interface to Chaosnict through the routines ill the "CHAOS.1332" BLISS-32

Subroutine package. D~efinitions of' standard values arc in "NICPI)FS.R32". '[bough it is possiblcto interf'ace to thc NC]P at the VMS 1/0 level, it is not recoimmended practice. All rcfecrences toChaosnet in this text arc with respect to die subroutine package, and not VMS QIO's.

A\ Chaosnlet connection is represenlted by a one loiig~ord "channel nIUInbcr'', " hich has nodirect relationship to a VMS channel number. I Iowc er. foi- c~cry Chaosnet channel currentlyallocated, there is an associated VMS channel maintained by the Subroutine package.

All of the routines described below arc declared "global".

11.1 Opening and Closing

parse_host (host, ret-host-num)Parses the string pointed to by host (which points to at standard VMS string descriptor),and stores the resulting host number in the word pointed to by ret-host-nwn. Returns astatus code.

chaos _r f c (ret-chan, host, contact- name, wait- time)Opens a new Chaosnet channel and sends an RFC. rei-c/ian is at longword to receive thechaIInel nuniber. host is a string acceptable to parse_host. confact-namec is a pointer to astring descriptor, wait-time is either /ero, which means to wait indefinitely 11or at responseto the RFC, or a pointer to a quadword bloc~k acceptable to the $SETIMR systemn service.A status code is returned, which will be SS$ TIMEOUT if' the routine times out.

chaos..1 sn (ret-chatt. contfact- name, wail-ftme)Like chaos-rfc, but "sends" a LSN instead of' anl RFC. No host is specified.

c haosac ce pt (c/in window, rfc-arg, ret- tfc- arg- size)Accepts an iinconming RFC. The connection Must be in RI"C-received state. window is thewindow size. tft-arg is an optional string descriptor which receives tie argumient to theRFC. revt- (i-t g- sizc is also optional, and gets the argument's length.

chaos-.ans (chan. (kila(. wait-ftme)Sends an A NS packet to the Chaosnct charnel. ita points to a string descriptor. wait-time is ignored. A status code is returned, and ii' all error occurs, the channel isdeassigned.

* - chaos~c Ilose (c/n, roiv~on)Closcs the connction, and dea'signs the channel. p'ea.%On is a pointer to at string(lcri ilior of' at Nring to be incliaded in the (TI S packet.

I ~K!~O NA~~l~107 1 5-.1 IN-81

Page 59: ASAHUSETTS TECH CAMBRIDGE ARTIFICIAL F/S, UC · PDF fileboth the hardware and software protocols. It is intended to be the definitive documentation for Chaosne~ 1 9 11 3~ I ~ '7 1

Stream Input and Output 54 Chaosnet

chaoe..aaa gn (rei-chan)Assigns a Chaosnet channel, and stores it in the longword pointed to by ret-c/ian. Thisroutine allocates a VMS channel, A status code is returned.

chaos...deassign (c/ian)Given a Chaosnet channel previously assigned by chaos..asign, dcassigns it and theassociated VMS channel.

11.2 Stream Input and Output

chaos-in-char (chan. ret-char timneoul)Returns the next character from the channel in the longword pointed to by ret-char.Waits until a character is available or until timeout, whichever comes first. A status codeis returned.

chaos~outchai' (chan, char)Outputs one character. Characters are buffered Until a packet fills up or until the outputis fiorced out by chaos-force_out. A status code is returned.

chaos...sout (c/ian, string)L ike repcated calls to chaos...out~char: sends string from string descriptor pointed to bystring.

chaos..!orce.out (c/ian)If doing serial output, and a partial packet is buffered, force it to be sent.

chaos..finlsh (chan)D~oes a chaos-force-out, then waits for all packets to be acknowledged by the foreignend.

chaoseof (chan)Sends an liOF packet after forcing out any buffiered output.

11.3 Packet Input and Output

allocate-.pkt (size. clian. rct-pkt)Allocates a packet sitahic for chaosinpkt and chaos~otitpkt. The packet can holdtip t4 NiZe bytes o1f diltil t11C 11uanher or hytes field in the packet's heaider is filled in Crumisiue(. rct-j1kt points to a h 3ugword to rceive at pointer to thie packet. A stat s co@de is

returned.

doallocato-pkt (pki)Returns a previouisly allocated packet to tie free pool. A packet inay be reuised, since the

I/0 routines (to flot deAlncate themtf. as long as (lie I/0 is being done synchronously.

I d O'K\llIR101 15-Rt IN-Nl

Page 60: ASAHUSETTS TECH CAMBRIDGE ARTIFICIAL F/S, UC · PDF fileboth the hardware and software protocols. It is intended to be the definitive documentation for Chaosne~ 1 9 11 3~ I ~ '7 1

Chaosnet 55 Checking the State

chaosout-pkt (chan, pkt. efn, astadr, astprnOutputs pkt to chan, waiting if there is no window room available. efn is the eventchannel to use for waiting. astadr and astlpn are as for VMS system services: an ASTaddress and parameter, respectivcly, that get signalled when the packet is read by theNCP. chaos_out returns as soon as there is space in the window, without waitingfor the NCP to finish transmitting the packet.

chaosi npkt (ct , t pkt, astadr, asiprm)

Reads the next input packet, whatever opcode it may be, from the connection, waitingindefinitely if there are no input packets, efn is the event channel to wait on, and astadrand astprm are for an ASI to be delivered when the read completes. chaos-in pkt doesnot return until the read completes. A status code is returned.

11.4 Checking the State

chaosxmittroom (c/ait, wait)Returns SS$_NORMAL if there is room left in the transmit window. Returns an error ifthe connection went into a bad state. If wait is true, and there is no room left, thenchaosxmit-room waits until room is available. If there is no room left and wail is false,it returns SS$.EXQUOTA.

chaosstate (chan)Updates die state of the Chaosnct channel via a request to the NC1. Returns a statuscode. To check the state of the connection, first call this routine then look at chan-statein the channel block described below.

chaoswait (chan, old-state, tflineout)Waits until the channel goes out of the specified state or until timeout occurs. Timeout iseither zero (no timeout) or a pointer to a quadword block acceptable to $SETIMR. Astatus code is returned.

chaoswal t_tt 1 (chan, stale, timeou)Waits until the channel goes into the specified state or until timeout occurs. Tineout iseither zero (no timeout) or a pointer to a quadword block acceptable to $SETIMR. Astatus code is returned.

The channel number is used as an index into the global blockvcctor channel, defined in the"CIIAOS.11,2" file. Since BI.ISS-32 does not allow the field definitions to be global, they shouldbe copied into any program that needs to look inside the channel hlockvcctor. The most usellfields are

chan-state One of the state codes defined below.

chansta txw Ilic window si/e in the tiinsmit direction.

chan-sta-rxw I he window si/e in thc rcceive direction.chan.stn txwa Ihc lniiiher of p;lLket 5hots o iihilhlc in the tIialnsinit window.chan-__ ,a..rxav 'l i iriihnr o c' hiipiii I , ktI .n,,ih lc.

I ) ,; Nt tI N \0l Ill l 11)7 15-.IUN-81

Page 61: ASAHUSETTS TECH CAMBRIDGE ARTIFICIAL F/S, UC · PDF fileboth the hardware and software protocols. It is intended to be the definitive documentation for Chaosne~ 1 9 11 3~ I ~ '7 1

Checking the State 56 Chaosnet

The states are as follows:

conn..st..closed (0) Connection closed by a CLS packet.

* conn..strfcrcv (1) RFC reccived by listening connection.

conn...st..rfcsnt (2) RFC sent, no response yet.

conn-.st-open (3) Connection open.

* conn...stlos (4) Connection broken by a LOS packet.

conn..st.Jncom (5) Incomplete transmission (no response from fo~reign host).

con n...snew (6) Connection newly allocated.

conn-.st-isn (7) Listening for an incoming RFC.conn..st~juI (%0'400') This bit is set when the transmit window is ffill. Usually, the

remainder of the state will be conn...stopen.

K .: N[1 0( )N -,AN II IR 10)7 15 .I11N-81

Page 62: ASAHUSETTS TECH CAMBRIDGE ARTIFICIAL F/S, UC · PDF fileboth the hardware and software protocols. It is intended to be the definitive documentation for Chaosne~ 1 9 11 3~ I ~ '7 1

Chaosnet 57 The Unix Implementation

12. The Unix ImplementationThe Unix implementation of Chaosnct works on both pdpll Unix and VAX Unix.

The network may be accessed in four different ways. A Chaosnet stream consection may beopened to a host and a contact name, and then standard Unix 1/O may be done over theconnection. A Chansnet connection may be accessed at the packet level (however. this is not yetimplemented). A Chaosnet stream conncction may be made into a Unix tty: this is how theTELNET server works. A subtree of one Unix host's file system may be mapped into anotherUnix host's file system, with the intermediate Chaosnet invisible to programs operating on theremote files.

You get access to Chaosnet by opening a file pathname which includes a special file whosemajor device is Chaosnet. The minor device number of that special file, together with its nameand any additional pathname components after it, are used to detcmine the host, RFC contactname, and RFC arguments. Remote file access is implemented by special files which map intothe desired host with contact name ftpread or ftpwrite. The remaining pathname after the specialfile is passed along and used as a pathname on the remote host.

The 8-bit Unix minor-device number is divided up into several fields which control details ofwhat happens when you open a Chaosnet special file. The current division is as follows:

bits 6-3 Host specifier. Small numbers are indices in a site-dependent table of hosts which arepa ticulayly useil to connect to. This is used primarily for the remote file-systemfacility. Otherwise this is one of:

015 The host number (in decimal) is read from the name of the special file.

016 The host number (in decimal) is read from the next pathname componentafter the special file.

017 Activates one of a number of special features selected by bits 2-0. See below.

bits 2-0 If the host specifier is not 017, this is a contact name specifier. Small numbers areindices in a site-dependent table of useful contact names. This is used primarily forthe remote file-system facility. Otherwise this is one of:

6 Read the contact name from the name of the special file.

7 Use the rest of the patlname, after the special file, as the contact name andR1C arguments.

When both the host number and the contact name are read from the patbnamc, thehost number is read first. Any character other than the digits 0 through 9 serves toseparawte them.

If' the host specifier is 017, this is instead one of the fillowing:

0 Pick lp unllnatched itioming RICs. Only one process at .1 linic, per system,inly opell lis dcice. [hC ioctl opertion chior next (,,e h'low) is usedOth this device.

I. I i,,t llmode. The rcs l m n 11hc mm;lailul. altelr ile ',hwe ti;al tile, is the collLictiinmc listened to. I Ii, %%ill Ait util R I C cL0iCS inl to that th pathurte. A

D)SK:M0N:AM l:R 107 15-ILIN-81

Page 63: ASAHUSETTS TECH CAMBRIDGE ARTIFICIAL F/S, UC · PDF fileboth the hardware and software protocols. It is intended to be the definitive documentation for Chaosne~ 1 9 11 3~ I ~ '7 1

Thc Unix Implementation 58 Chaosnet

typical pathnamc would be "/dev/chlisten/myprotocol".

2 l.isten-crror mode. Same as above, but if there is no pending RFC to thecontact namc, this will return an error rather than waiting for one.

3 Packet mode. This is not implemented yet.

bit 7 Specifies that this Chaosnet connection should be wired to a tty.

When a Chaosnet connection is wired to a Unix tty, input data from Chaosnet appearas keyboard input characters on that tty. Output typed on the tty goes out onChaosnet as data. When the tty is hung up (logged out), the Chaosnet connectionwill be closed. 1/0 operations done to the Chaosnet channel will be done to the ttyinstead, except for the special ioctl operations given below,

When a connection has been opened, the normal Unix 1/0 operations may be done on it. 8-bit bytes in standard data packets (opcode 200) are used. If the Chaosnet connection is not open,the I/O operations will return an error. When the close operation is performed, if the Chaosnetconnection is open the standard EOF protocol will be followed (see section 4.4, page 24).

The following operations are supported for the loctl system call:

fionread Returns the total number of data bytes in the available input packets. This is thenumber of bytes which can be read without waiting.

chiocflush Forces out buffered output. Normally stream output is held until a packet is filledup or 2 seconds have elapsed.

chiocrread Returns data from the RFC packet. This is only valid on a connection which wascreated by listening and which has not yet been read from. The source host (2bytes) is returned, followed by a null-terminated character string which is thecontact name and diny following arguments.

chiocrnext This is only valid on the unmatched-RFC connection, and is the only loctloperation valid on it. This waits until an unmatched RFC is present, and thenreturns its contact-name and arguments as a null-terminated string. The systemuninatched-RFC process uses this to start tip server processes as RFCs come in.(Currently this mechanism is used only for the remote file-system servers.)

chioctty If the Chaosnet connection is open, and is not already wired to a tty, this createsa new Unix tty and wires it to the connection.

L ,1:% ) ,,,\ II 117 15-11 N 31

Page 64: ASAHUSETTS TECH CAMBRIDGE ARTIFICIAL F/S, UC · PDF fileboth the hardware and software protocols. It is intended to be the definitive documentation for Chaosne~ 1 9 11 3~ I ~ '7 1

Chaosnet 59 References

Referenceslhe following documents arc of some related interest. AIM is an Al Memo of the MITI

Artificial Intelligence Laboratory. RFC is a Request for Comments of the Arpanet NetworkWorking Group. lEN is an Internet Experiment Note of the Arpanet Network Working Group.

[A1M444J A. Ilawden, R. Greenblatt, et aL, Lisp Machine Progress Report, AIM-444.

[CIIINUALI D). Weinreb, D. Moon, Lisp Machine Manual, MIT Al Lab.

* [CPR] C. Ryland, TOPS-20 Chaosnet Manual, unpublished.

[ETI-ERNFI] R. Metcalfe, D. B~oggs, Ethernet: D~istributed Packet Switching for LocalComputer Networks, CACM Vol. 19, No. 7, July 1976, p. 395.

[FILE] D~ocumented online on the file Af:LMDOC;CHFILE X.

[FINGER] K. Harrenstien, Namne/Finger, RFC-742.

[RFC733J D). Crocker et al.. Standard for the Format of Arpa Network Text Messages, RFC-733.

[SUPI)UP1 M. Crispin, Supdup Protocol, RFC-747, RFC-734.

rl'CPI D)01 Standard Transmission Control Protocol, lEN- 129.

[FFELNF-l] Telnet Protocol Specification, RFC-542.

jTJMEI K. flarrenstien, Time Server, RFC-738.

[UI)P] J. IPostel, User LDatagramn Protocol, IFN-88.

[UNIBUS] Pl)I1l I Peripherals Handbook, IDigital Equipment Corporation.

I ~LNlti )KMI~~ 117 1~l~l4 l1

Page 65: ASAHUSETTS TECH CAMBRIDGE ARTIFICIAL F/S, UC · PDF fileboth the hardware and software protocols. It is intended to be the definitive documentation for Chaosne~ 1 9 11 3~ I ~ '7 1

DATE

ILM Eill