;;; -*- Mode:gate; Fonts:(HL12 HL12I HL12B CPTFONTB HL12BI HL12B HL12I ) -*- =Node: 4Chaosnet Errors* =Text: 3CHAOSNET ERRORS sys:network-error* (3error*) 1Condition Flavor* All errors from the Chaosnet code use flavors built on this one. =Node: 4Local Problems* =Text: 3LOCAL PROBLEMS sys:local-network-error* (3sys:network-error* 3error*) 1Condition Flavor* This flavor is used for problems in connection with the Chaosnet that have entirely to do with what is going on in this Lisp Machine. 3sys:network-resources-exhausted* 1Condition* (3sys:local-network-error* 3sys:network-error* 3error*) Signaled when some local resource in the NCP was exhausted. Most likely, there are too many Chaosnet connections and the connection table is full. 3sys:unknown-address* (3sys:local-network-error* 3sys:network-error* 3error*)1Condition* The 1address* argument to 2chaos:connect* or some similar function was not recognizable. The 2:address* operation on the condition instance returns the address that was supplied. =Node: 4Problems Involving Other Machines' Actions* =Text: 3PROBLEMS INVOLVING OTHER MACHINES' ACTIONS sys:remote-network-error* (3sys:network-error* 3error*) 1Condition Flavor* This flavor is used for network problems that involve the actions (or lack of them) of other machines. It is often useful to test for as a condition name. The operations 2:connection* and 2:foreign-host* return the 2chaos:conn* object and the host object for the foreign host. All the condition names listed below imply the presence of 2sys:remote-network-error*, 2sys:network-error* and 2error*. For brevity, these are not mentioned in the individual descriptions. Every instance of 2sys:remote-network-error* is either a 2sys:connection-error* or a 2sys:bad-connection-state*. 3sys:connection-error* 1Condition* This condition name categorizes failure to complete a connection. 3sys:bad-connection-state* 1Condition* This condition name categorizes errors where an existing, valid connection becomes invalid. The error is not signaled until you try to use the connection. 3sys:host-not-responding* 1Condition* This condition name categorizes errors where no packets whatever are received from the foreign host, making it seem likely that that host or the network is down. 3sys:host-not-responding-during-connection* 1Condition* (3sys:connection-error* 3sys:host-not-responding*) This condition is signaled when a host does not respond while it is being asked to make a connection. 3sys:no-server-up* (3sys:connection-error*) 1Condition* This condition is signaled by certain functions which request service from any available machine which can provide it, if no such machine is responding or no host is listed as a server for a particular service. 3sys:host-stopped-responding* 1Condition* (3sys:bad-connection-state* 3sys:host-not-responding*) This condition is signaled when a host does not respond even though a connection to it already exists. 3sys:connection-refused* (3sys:connection-error*) 1Condition* This is signaled when a connection is refused. The 2:reason* operation on the condition instance returns the reason specified in the CLS packet (a string) or 2nil* if no reason was given. Note that many Chaosnet implementations do not send CLS packets when there is no process or server listening for a contact name. Also, it is possible for the CLS packet to get lost in the network, so that the error actually signalled is not unlikely to be 2sys:host-not-responding-during-connection*. 3sys:connection-closed* (3sys:bad-connection-state*) 1Condition* This is signaled when you try to send on a connection which has been closed by the other host. The 2:reason* operation on the condition instance returns the reason specified in the CLS packet (a string) or 2nil* if no reason was given. 3sys:connection-lost* (3sys:bad-connection-state*) 1Condition* This is signaled when you try to use a connection on which a LOS packet was received. The 2:reason* operation on the condition instance returns the reason specified in the CLS packet (a string) or 2nil* if no reason was given. 3sys:connection-no-more-data* (3sys:bad-connection-state*) 1Condition* This is signaled when you try to read from a connection which has been closed by the other host, when there are no packets left to be read. (It is no error to read from a connection which has been closed, if you have not yet read all the packets which arrived, including the CLS packet). The 2:reason* operation on the condition instance returns the reason specified in the CLS packet (a string) or 2nil* if no reason was given. =Node: 4Information and Control* =Text: 3INFORMATION AND CONTROL chaos:host-up-p* 1host* &optional 1(timeout* 3180.1)** 2t* if 1host* responds over the Chaosnet within 1timeout* sixtieths of a second, otherwise 2nil*. The value is always 2nil* if 1host* is not on the Chaosnet. 3chaos:up-hosts* 1host-list* &optional 1number-of-hosts* 1(timeout* 3250.1)** Returns a list of all the hosts in 1host-list* which are currently responding over the Chaosnet. 1host-list* is a list of host names and/or host objects. The value is always a list of host objects, possibly 2nil* for none of them. If 1number-of-hosts* is non-2nil*, it should be a positive integer; when that many hosts have responded, 2chaos:up-hosts* returns right away without bothering to listen for replies from the rest. 1timeout* is an integer; if a host fails to respond for that many sixtieths of a second, it is assumed to be down. 3chaos:host-data* &optional 1host* 1host* may be a number or a known host name, and defaults to the local host. Two values are returned. The first value is the host name and the second is the host number. If the host is a number not in the table, it is asked its name using the 2STATUS* protocol; if no response is received the name 2"Unknown"* is returned. 3chaos:print-conn* 1conn* &optional 1(short* 3t1)** Prints everything the system knows about the connection. If 1short* is 2nil* it also prints everything the system knows about each queued input and output packet on the connection. 3chaos:print-pkt* 1pkt* &optional 1(short* 3nil1)** Prints everything the system knows about the packet, except its data field. If 1short* is 2t*, only the first line of the information is printed. 3chaos:print-all-pkts* 1pkt* &optional 1(short* 3t1)** Calls 2chaos:print-pkt* on 1pkt* and all packets on the threaded list emanating from it. 3chaos:status* Prints the hardware status. (Currently works for the CADR only.) 3chaos:reset* Resets the hardware and software and turns off Chaosnet communication. 3chaos:assure-enabled* Turns on Chaosnet communication if it is not already on. It is normally always on unless you call one of the functions in this section. 3chaos:enable* Resets the hardware and turns on Chaosnet communication. 3chaos:disable* Resets the hardware and turns off Chaosnet communication. 3chaos:show-routing-table* 1host* &optional 1(stream* 3*standard-output1)** Print out 1host*'s routing table onto 1stream*. 3chaos:show-routing-path* &key 1(from* 3si:local-host1)** 1to* 1(stream* 3*standard-output1)** Show how a packet would get from 1from* to 1to*. For this to work when the hosts are on different subnets, the bridge must respond to the 2DUMP-ROUTING-TABLE* request. 3chaos:my-address* 1Constant* The sixteen bit Chaosnet address of this Lisp Machine. On the CADR, this is set by reading a location off the Chaosnet (I/O) board. On a Lambda, this is set by looking at the name of the disk pack, and using that as a host name to get the Chaosnet address. (This is because a Lambda talks Chaosnet through an Ethernet interface, which has a pre-assigned address of its own.) 3chaos:my-subnet* 1Constant* The high eight bits of 2chaos:my-address*. 3chaos:routing-table* 1Constant* This is an 2art-16b* array which contains for each subnet the address of a bridge which is the best way of getting to that subnet. Since (currently) Lisp Machines can only have one interface to the network, the addresses in the table all contain the same subnet, namely, the name of 2chaos:my-address*. 3chaos:maximum-routing-cost* 1Constant* The maximum cost that a route can be in the routing table. Subnets with a cost greater than this do not appear in the Peek Chaosnet display 3chaos:routing-table-cost* 1Constant* This is an 2art-16b* array which contains for each subnet the cost for getting to that subnet. 3chaos:*receive-broadcast-packets-p** 1Variable* If not 2nil* (the default), broadcast packets are responded to. 3chaos:*brd-history** 1Variable* A list of elements of the form 2(1contact-name address*)* recording what hosts have been contacting this machine with broadcast requests. 3chaos:*brd-pkts-in** 1Variable* The number of broadcast packets (opcode 2BRD-OP*) that have been received. This should never be less than 2(length chaos:*brd-history*)*. The PEEK program has a mode that displays the status of all of the Lisp Machine's Chaosnet connections, and various other information, in a continuously updating fashion. =Node: 4Higher-Level Protocols* =Text: 3HIGHER-LEVEL PROTOCOLS* This section briefly documents some of the higher-level protocols of the most general interest. There are quite a few other protocols which are too specialized to mention here. All protocols other than the 2STATUS* protocol are optional and are only implemented by those hosts that need them. All hosts are required to implement the 2STATUS* protocol since it is used for network maintenance. The site files tell the Lisp Machine which hosts at your site implement certain higher-level protocols. See 4(MISCELL-4)Site Options and Host Table*. =Node: 4Status* =Text: 3STATUS* All network nodes, even bridges, are required to answer RFC's with contact name 3STATUS*, returning an ANS packet in a simple transaction. This protocol is primarily used for network maintenance. The answer to a 3STATUS* request should be generated by the Network Control Program, rather than by starting up a server process, in order to provide rapid response. The 3STATUS* protocol is used to determine whether a host is up, to determine whether an operable path through the network exists between two hosts, to monitor network error statistics, and to debug new Network Control Programs and new Chaosnet hardware. The 2hostat* function on the Lisp Machine uses this protocol. The first 32 bytes of the ANS contain the name of the node, padded on the right with zero bytes. The rest of the packet contains blocks of information expressed in 16-bit and 32-bit words, low byte first (little-endian convention). The low-order half of a 32-bit word comes first. Since ANS packets contain 8-bit data (not 16-bit), big-endian machines such as PDP-10s have to shuffle the bytes explicitly when using this protocol. The first 16-bit word in a block is its identification. The second 16-bit word is the number of 16-bit words to follow. The remaining words in the block depend on the identification. This is the only block type currently defined. All items are optional, according to the count field, and extra items not defined here may be present and should be ignored. Note that items after the first two are 32-bit words. 2word 0* A number between 400 and 777 octal. This is 400 plus a subnet number. This block contains information on this host's direct connection to that subnet. 2word 1* The number of 16-bit words to follow, usually 16. 2words 2-3* The number of packets received from this subnet. 2words 4-5* The number of packets transmitted to this subnet. 2words 6-7* The number of transmissions to this subnet aborted by collisions or because the receiver was busy. 2words 8-9* The number of incoming packets from this subnet lost because the host had not yet read a previous packet out of the interface and consequently the interface could not capture the packet. 2words 10-11* The number of incoming packets from this subnet with CRC errors. These were either transmitted wrong or damaged in transmission. 2words 12-13* The number of incoming packets from this subnet that had no CRC error when received, but did have an error after being read out of the packet buffer. This error indicates either a hardware problem with the packet buffer or an incorrect packet length. 2words 14-15* The number of incoming packets from this subnet that were rejected due to incorrect length (typically not a multiple of 16 bits). 2words 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 word 0, the identification, is a number between 0 and 377 octal, this is an obsolete format of block. The identification is a subnet number and the counts are as above except that they are only 16 bits instead of 32, and consequently may overflow. This format should no longer be sent by any hosts. Identification numbers of 1000 octal and up are reserved for future use. =Node: 4Routing Information* =Text: 3ROUTING INFORMATION* For network and NCP debugging, this RFC/ANS protocol should be implemented. The contact name is 3DUMP-ROUTING-TABLE*, and the response is an ANS packet whose words alternately contain a method to getting to a subnet, and the cost. If the method is zero, then the machine knows of no way to get to that subnet. If the method is positive and less than 400 (octal), it is an interface of some kind to that subnet. If the method is 400 (octal) or greater, this is actually a bridge (host) off which the machine is bouncing packets destined for the subnet. =Node: 4Telnet and Supdup* =Text: 3TELNET AND SUPDUP* The Telnet and Supdup protocols of the Arpanet exist in identical form in Chaosnet. These protocols allow access to a computer system as an interactive terminal from another network node. The contact names are 3TELNET* and 3SUPDUP*. The direct borrowing of the Telnet and Supdup protocols was eased by their use of 8-bit byte streams and of only a single connection. Note that these protocols define their own character sets, which differ from each other and from the Chaosnet standard character set. For the Telnet protocol, refer to the RFC 854 (An RFC is a network document put out by the NIC or Network Information Center.) For the Supdup protocol, see MIT AI Lab memo 644. Chaosnet contains no counterpart of the INR/INS attention-getting feature of the Arpanet. The Telnet protocol sends a packet with opcode 201 octal in place of the INS signal. This is a controlled packet and hence does not provide the ``out of band'' feature of the Arpanet INS, however it is satisfactory for the Telnet `interrupt process' and `discard output' operations on the kinds of hosts attached to Chaosnet. =Node: 4File Access* =Text: 3FILE ACCESS* The FILE protocol is primarily used by Lisp Machines to access files on network file servers. ITS, TOPS-20, Tenex, Unix, VMS, and Lisp Machines are equipped to act as file servers. A user end for the file protocol also exists for all the operating systems mentioned (except VMS) and is used for general-purpose file transfer. For complete documentation on the file protocol, see 2SYS: DOC; FILE TEXT*. The Arpanet file transfer protocols have not been implemented on the Chaosnet (except through the Arpanet gateway described below). =Node: 4Mail* =Text: 3MAIL* The MAIL protocol is used to transmit inter-user messages through the Chaosnet. The Arpanet mail protocol in FTP was not used because of its complexity and poor state of documentation. This simple protocol is by no means the last word in mail protocols; however, it is adequate for the mail systems we presently possess. The sender of mail connects to contact name 3MAIL* and establishes a stream connection. It then sends the names of all the recipients to which the mail is to be sent at (or via) the server host. The names are sent one to a line and terminated by a blank line (two carriage returns in a row). The Lisp Machine character set is used. A reply (see below) is immediately returned for each recipient. A recipient is typically just the name of a user, but it can be a user-atsign-host sequence or anything else acceptable to the mail system on the server machine. After sending the recipients, the sender sends the text of the message, terminated by an EOF. After the mail has been successfully swallowed, a reply is sent. After the sender of mail has read the reply, both sides close the connection. In the MAIL protocol, a reply is a signal from the server to the user (or sender) indicating success or failure. The first character of a reply is a plus sign for success, a minus sign for permanent failure (e.g. no such user exists), or a percent sign for temporary failure (e.g. unable to receive message because disk is full). The rest of a reply is a human-readable character string explaining the situation, followed by a carriage return. The message text transmitted through the mail protocol normally contains a header formatted in the Arpanet standard fashion. Refer to the Arpanet Protocols Handbook. The SMTP protocol can also be used over Chaosnet; the contact name is 3SMTP*. See RFC 821 for details. =Node: 4Send* =Text: 3SEND* The SEND protocol is used to transmit an interactive message (requiring immediate attention) between users. The sender connects to contact name 3SEND* at the machine to which the recipient is logged in. The remainder of the RFC packet contains the name of the person being sent to. A stream connection is opened and the message is transmitted, followed by an EOF. Both sides close after following the end-of-data protocol described in 4(CHAOSNET-1)Chaosnet Overview*. The fact that the RFC was responded to affirmatively indicates that the recipient is in fact present and accepting messages. The message text should begin with a suitable header, naming the user that sent the message. The standard for such headers, not currently adhered to by all hosts, is one line formatted as in the following example: 3Moon@MIT-MC 6/15/81 02:20:17* Automatic reply to the sender can be implemented by searching for the first `@' and using the SEND protocol to the host following the `@' with the argument preceding it. =Node: 4Name* =Text: 3NAME* The Name/Finger protocol of the Arpanet exists in identical form on the Chaosnet. Both Lisp Machines and timesharing machines support this protocol and provide a display of the user(s) currently logged in to them. The contact name is 3NAME*, which can be followed by a space and a string of arguments like the ``command line'' of the Arpanet Name protocol. A stream connection is established and the ``finger'' display is output in Lisp Machine character set, followed by an EOF. Lisp Machines also support the FINGER protocol, a simple-transaction version of the NAME protocol. An RFC with contact name 3FINGER* is transmitted and the response is an ANS containing the following items of information separated by carriage returns: the logged-in user ID, the location of the terminal, the idle time in minutes or hours-colon-minutes, the user's full name, and the user's group affiliation. =Node: 4Time* =Text: 3TIME* The Time protocol allows a host such as a Lisp Machine that has no long-term timebase to ask the time of day. An RFC to contact name 3TIME* evokes an ANS containing the universal time as a 32-bit number in four 8-bit bytes, least-significant byte first. 3chaos:host-time* &optional 1hosts* Returns either a universal time, or a string explaining why the time couldn't be found out, from one of 1hosts*. 1Hosts* defaults to the list of Chaosnet time server hosts. 3chaos:print-host-times* &optional 1hosts* 1(stream* 3*standard-output*1)** Print out on 1stream* the times given by 1hosts*. Any host that returns a time that is more than three minutes off this hosts time will have its repsonse marked with ``!'' 1Hosts* defaults to the list of Chaosnet time server hosts. =Node: 4Time Server Control* =Text: 3TIME SERVER CONTROL* For a time server that does not have any other way to correct its own time (usually because it is a bridge), that host should support this simple way of accepting a request to reset its own timebase. The contact name is 3RESET-TIME-SERVER*, and the response (on successful completion) is an ANS. Following such a request, if the network is the only source of a timebase, it may be wise to immediately disable the 3TIME* server, wait about 20 seconds, and then attempt to get the time from the network. This may prevent the host from getting bad times from other machines that were ``infected'' with it. 3chaos:reset-time-server* 1host* Reset the network time server of 1host*. It will try to tell you the time it gets afterward, if possible. =Node: 4Uptime* =Text: 3UPTIME* This is similar to the TIME protocol, except that the contact name is 3UPTIME*, and the time returned is actually an interval (in seconds) describing how long the host has been up. 3host-uptime* 1host* &optional 1(stream* 3*standard-output*1)** Return the number of seconds that 1host* has been up, and print that out in human-readable form if 1stream* is not 2nil*. 3uptime* &optional 1(stream* 3*standard-output*1)** 1hosts* Print out the uptimes for 1hosts* (which if not supplied defaults to all Chaosnet hosts) onto 1stream*. =Node: 4Internet Gateway* =Text: 3INTERNET GATEWAY* This protocol allows a Chaosnet host to access almost any service on the Internet. The gateway server runs on each ITS host that is connected to both networks. It creates an Internet connection and a Chaosnet connection and forwards data bytes from one to the other. It also provides for a one-way auxiliary connection, used for the data connection of the Arpanet File Transfer Protocol. The RFC packet contains a contact name of 3TCP*, a space, the name of the Internet host to be connected to, optionally followed by a space and the contact-socket number in octal, which defaults to 1 if omitted. The name of host can also be an Internet-format address. The bi-directional 8-bit connection is made by connecting to the host with TCP. If a data packet with opcode 201 (octal) is received, an Arpanet INS signal is transmitted. Any data bytes in this packet are transmitted normally. (This does nothing in the current server, since TCP does not define an interrupt signal.) If a data packet with opcode 210 (octal) is received, an auxiliary connection on each network is opened. The first eight data bytes are the Chaosnet contact name for the auxiliary connection; the user should send an RFC with this name to the server. The next four data bytes are the TCP socket number to be connected to, in the wrong order, most-significant byte first. The byte-size of the auxiliary connection is 8 bits. The normal closing of an TCP connection corresponds to an EOF packet. Closing due to an error, such as Host Dead, corresponds to a CLS packet. =Node: 4Host Table* =Text: 3HOST TABLE* The 3HOSTAB* protocol may be used to access tables of host addresses on other networks, such as the Arpanet or Internet. Servers for this protocol currently exist for Tenex, TOPS-20, ITS, and Lisp Machines. The user connects to contact name 3HOSTAB*, undertakes a number of transactions, then closes the connection. Each transaction is initiated by the user transmitting a host name followed by a carriage return. The server responds with information about that host, terminated with an EOF, and is then ready for another transaction. The server's response consists of a number of attributes of the host. Each attribute consists of an identifying name, a space character, the value of the attribute, and a carriage return. Values may be strings (free of carriage returns and 1not* surrounded by double-quotes) or octal numbers. Attribute names and most values are in upper case. There can be more than one attribute with the same name; for example, a host may have more than one name or more than one network address. The standard attribute names defined now are as follows. Note that more are likely to be added in the future. 3ERROR* The value is an error message. The only error one might expect to get is ``no such host''. 3NAME* The value is a name of the host. There may be more than one 3NAME* attribute; the first one is always the official name, and any additional names are nicknames. 3MACHINE-TYPE* The value is the type of machine, such as 3LISPM*, 3PDP10*, etc. 3SYSTEM-TYPE* The value is the type of software running on the machine, such as 3LISPM*, 3ITS*, etc. 3ARPA* The value is an address of the host on the Arpanet, in the form 1host*/1imp*. The two numbers are decimal. 3CHAOS* The value is an address of the host on Chaosnet, as an octal number. 3DIAL* The value is an address of the host on Dialnet, as a telephone number. 3LCS* The value is an address of the host on the LCSnet, as two octal numbers separated by a slash. 3SU* The value is an address of the host on the SUnet, in the form 1net*#1host*. The two numbers are octal. =Node: 4Dover* =Text: 3DOVER* A press file may be sent to the Dover printer at MIT by connecting to contact name 2DOVER* at host 2AI-CHAOS-11*. This host provides a protocol translation service that translates from Chaosnet stream protocol to the 2EFTP* protocol spoken by the Dover printer. Only one file at a time can be sent to the Dover, so an attempt to use this service may be refused by a CLS packet containing the string 2"BUSY"*. Once the connection has been established, the press file is transmitted as a sequence of 8-bit bytes in data packets (opcode 200). It is necessary to provide packets rapidly enough to keep the Dover's program (Spruce) from timing out; a packet every five seconds suffices. Of course, packets are normally transmitted much more rapidly. Once the file has been transmitted, an EOF packet must be sent. The transmitter must wait for that EOF to be acknowledged, then send a second one, and then close the connection. The two EOF's are necessary to provide the proper connection-closing sequence for the 2EFTP* protocol. Once the press file has been transmitted to the Dover in this way and stored on the Dover's local disk, it will be processed, prepared for printing, and printed. If an error message is returned by the Dover while the press file is being transmitted, it is reported back through the Chaosnet as a LOS containing the text of the error message. Such errors are fairly common; the sender of the press file should be prepared to retry the operation a few times. Most programs that send press files to the Dover first wait for the Dover to be idle, using the Foreign Protocol mechanism of Chaosnet to check the status of the Dover. This is optional, but is courteous to other users since it prevents printing from being held up while additional files are sent to the Dover and queued on its local disk. It would be possible to send to a press file to the Dover using its 2EFTP* protocol through the Foreign Protocol mechanism, rather than using the 2AI-CHAOS-11* gateway service. This is not usually done because 2EFTP*, which requires a handshake for every packet, tends to be very slow on a timesharing system. =Node: 4Remote Disk* =Text: 3REMOTE DISK* The Remote Disk server exists on Lisp Machines to allow other machines to refer to or modify the contents of the Lisp Machine's disk. Primarily this is used for printing and editing the disk label. After first establishing a connection to contact name 3REMOTE-DISK*, the user process sends commands as packets which contain a line of text, ending with a 2Return* character. The text consists of a command name, a space, and arguments interpreted according to the command. The server processing the command may send disk data to the user, or it may read successive packets and write them to the disk. It is up to the user to know how many packets of disk data to read or send after each command. The commands are: 2READ 1unit* 1block* 1n-blocks** Reads 1n-blocks* of data from disk 1unit* starting at 1block* and transmits their contents to the user process. 2WRITE 1unit* 1block* 1n-blocks** Reads data from the net connection and stores it into 1n-blocks* disk blocks on disk 1unit* starting at 1block*. 2SAY 1text** Prints 1text*, which is simply all the rest of the line following 2SAY*, on the screen of the server host as a notification. Each disk block is transmitted as three packets, the first two containing the data for 121 (decimal) Lisp Machine words, and the third containing the data for the remaining 14 (decimal) words of the disk block. Each packet's data ends with a checksum made by adding together all the 8-bit bytes of the actual disk data stored in the packet. =Node: 4The Eval Server* =Text: 3THE EVAL SERVER* The Eval server is available on Lisp Machines with contact name 3EVAL*. It provides a read-eval-print loop which reads and prints using the Chaosnet connection. The data consists of text in the ASCII character set. Each time a complete s-expression arrives, the Eval server reads it, evaluates it and prints the list of values back onto the network connection, followed by a CRLF. There is no way for the user process to tell the end of the output for a particular s-expression; the usual application is simply to copy all the output to a user's terminal asynchronously. The Eval server is disabled when the Lisp Machine is logged in, unless the user requests to enable it. 3chaos:eval-server-on* 1mode* Turn the Eval server on this Lisp Machine on or off. 1mode* can be 2t* (on), 2nil* (off), or 2:notify* (on, but notify the user when a connection is made). =Node: 4Using Higher Level Protocols* =Text: 3USING HIGHER LEVEL PROTOCOLS qsend* 1user* &optional 1text* Sends a message to another user. 2qsend* is different from 2mail* because it sends the message immediately; it will appear within seconds on the other user's screen, rather than being saved in her mail file. 1user* should be a string of the form 2"1usernamehost3 is the name of the Lisp Machine*** 3or timesharing system the user is currently logged-in to. Multiple* 3recipients separated by commas are also allowed. 1text* is a string which* 3is the message. If 1text* is not specified, you are prompted to type in a* 3message.* 3Unlike 2mail* and 2bug*, 2qsend* does not put up a window to allow you to compose* 3the message; it just reads it from the input stream. Use Converse if* 3you wish to compose sends in the editor. Converse can be invoked by* 3typing 2System* 2C*. If you have started typing in a message to 2qsend*, you* 3can switch to Converse by typing 2Control-Meta-E* (``Edit''). The text you* 3have typed so far is transferred into Converse.* 2qsend3 does give you the ability to insert the text of the last message** 3you received. Type 2Control-Meta-Y* to do this. reply* &optional 1text* 3qreply* &optional 1text* Sends 1text* as a message to the last user who sent a message to you, like 2qsend* with an appropriate first argument provided. The two names are synonymous. 3chaos:shout* &optional 1message* Sends 1message* to every Lisp Machine at your site. If you do not specify 1message*, it is read from 2*standard-input**. 3print-sends* Reprints any messages that have been received. This is useful if you want to see a message again. 3supdup* &optional 1host* 1host* may be a string or symbol, which is taken as a host name, or a number, which is taken as a host number. If no 1host* is given, the machine you are logged-in to is assumed. This function opens a connection to the host over the Chaosnet using the Supdup protocol, and allows the Lisp Machine to be used as a terminal for any ITS, UNIX or TOPS-20 system. To give commands to 2supdup*, type the 2Network* key followed by one character. Type 2Network* followed by 2Help* for documentation. 3telnet* &optional 1host* 1simulate-imlac* 2telnet* is similar to 2supdup* but uses the Arpanet-standard Telnet protocol, simulating a printing terminal rather than a display terminal. 3hostat* &rest 1hosts* Asks each of the 1hosts* for its status using the 3STATUS* protocol, and prints the results. If no hosts are specified, all hosts on the Chaosnet are asked. Hosts can be specified either by name or by number. For each host, a line is output that either says that the host is not responding or gives metering information for the host's network attachments. If a host is not responding, that usually means that it is down or there is no such host at that address. A Lisp Machine can fail to respond if it is looping inside 2without-interrupts* or paging extremely heavily, such that it is simply unable to respond within a reasonable amount of time. 3finger* &optional 1spec* 1(stream* 3*standard-output*1)** 3whois* &optional 1spec* 1(stream* 3*standard-output*1)** Prints brief (2finger*) or verbose (2whois*) information about a user or users specified by 1spec*, on 1stream*. 1spec* can be a user name, 2@* followed by a host name, or a user name, 2@*, and a host name. If there is no host name, the default login host is used. If there is no user name, all users on the host are described. Examples: 3(finger "@OZ")* 3(whois "RMS@OZ") chaos:finger-all-lms* &optional 1stream* 1print-free* 1return-free* 1hosts* Prints a line of information about the user of each Lisp Machine in 1hosts* (the default is all Lisp Machines at this site) on 1stream* (default is 2*standard-output**). If 1print-free* is non-2nil*, information on free Lisp Machines and nonresponding Lisp Machines is also printed. If 1return-free* is non-2nil*, then this function returns two values, the first a list of host objects of free Lisp Machines, the second a list of host objects of nonresponding Lisp Machines. 3chaos:user-logged-into-host-p* 1username* 1host* Returns 2t* if there is a user named 1username* logged in on 1host* (a host name or host object). 3chaos:find-hosts-or-lispms-logged-in-as-user* 1user* 1hosts* Return a list of host objects for hosts on which 1user* is logged in. All Lisp Machines at this site are checked, and so are 1hosts* (which are presumably non-Lisp machines). 3tv:close-all-servers* 1reason* Close the connections of all network servers on this Lisp Machine, giving 1reason* (a string) as the reason in the CLS packet. Note that PEEK has a mode that displays information on the active network servers.