Date: 7 June 1983 02:40 EDT From: Robert Elton Maas Subject: no feedback yet To: PCNET-DESIGN @ MIT-MC Any chance some of you will send me feedback on the proposals for organization of software that I sent to this forum several *months* ago? Any chance some of you will draft proposals for some of the issues that I didn't cover in my proposals? It's really frustrating to go to all that effort fleshing out "how do we implement PCNET" and get not one reply in return.  Date: 27 March 1983 15:51 EST From: Robert Elton Maas Subject: Overall design for electronic mail To: PCNET-DESIGN @ MIT-MC PROTO.WR2, written in early 1978, contains a sketch of the top-down design of a mail system for PCNET. Several of you are new since then and might not have read that document, so I'm duplicting one section here as a tickler for somebody to flesh out the details and present the fleshed-out proposed design in this forum. SNDMSG/MAIL AND RCVMSG PROGRAMS Although the design of the program for creating and initiating transit of a message, and the program for displaying the received message at the other end, are the responsibility of the individual computer system staff, not of the net per se, our net won't be of much use without such programs, so I'll give examples of each here. The message-creation program here is similar to the MAIL program at MIT-ITS currently. The message-display program is a concoction from several I've used at various places including RCV and E at SU-AI and BANANARD and RCVMSG on TENEX sites. Mr. Maas logs in and types "SNDMSG APH" followed by a carriage return. This starts up the message-sending program, then uses "APH" as destination. It looks up "APH" in Mr. Maas's personal correspondents file and discovers it refers to Abraham P. Hillman, whose network address is as shown in the MAIL: field earlier. It replaces the "APH" by the correct full destination address, and types out "MSG:" to indicate it is waiting for Mr. Maas to type in the text of the message. He types "I was wondering if you knew of any computer programs, other than the trivial ones I wrote t Santa Clara, that are set up explicitly to perform the usual differential algebra manipulations." At this point he notices he has missed the "a" key when typing the word "at", so he hits altmode to enter command mode and types the letter "E" to enter the text-editor. After correcting the error, so that it now reads "... I wrote at Santa Clara, ...", he hits control-C to return to the main type-in loop. He decides to add a subject line, so he now hits altmode and "S", then after getting the prompt "SUBJECT:" he types "Programs for Diff. Algebra" and carriage return. Back in the main type-in loop once more, he then completes his message "I am especially interested in any MACSYMA routines you may know about." and hits control-C to close the message and send it on its way. Upon logging in to UNM-10A the next day, Mr. Hillman gets a message on his screen saying "[You have new mail]". He types "RCV" followed by carriage return, and the RCVMSG program displays the sender and subject of the three messages he has received since last checking his messages. He selects the one from REM, and after glancing at it he gives the command for appending text to the end of the message and then types "[APH - Please tell REM where to find source for DIFSLV and MANIFOLD. Also send copy of info to me.]". Then he gives the command for sending the current message, and directs it to NEWTON who is a local user on the UNM-10A system. He also gives the command to copy the complete message (including his addenda) to his current archive file, then delete the original from his new-mail file. He then looks at the other two messages, deletes one, and transfers the other to his archive file without otherwise acting on it.  Date: 26 March 1983 21:23 EST From: Robert Elton Maas Subject: FTP1 use, part three of three today [corrected header] To: PCNET-DESIGN @ MIT-MC IMSSS-style user-FTP1. The user and host computers are already connected via modems&UARTs, and exchanging packets, in fact are running the TELNET protocol. This gives error control but allows arbitrary system commands to be executed on the remote system just like a bare modem&UART connection. The user types a magic escape character or command which invokes FTP mode. Here's what happens: Sub-FTP is called, which: (1) Sends a node-control message asking Please-Do OPNSTR of FTP1. If the reply is a refusal, the other node can't stack application programs. (2) Assuming it is acceptance, the stream range is used to set up mapping. (3) Enter user-FTP command loop as before, which eventually exits. (4) Clean up streams. (5) Control is returned to the TELNET program for talking to remote host.  Date: 26 March 1983 21:23 EST From: Robert Elton Maas Subject: FTP1 use, part two of three today To: PCNET-DESIGN @ MIT-MC IMSSS-style user-FTP1. The user and host computers are already connected via modems&UARTs, and exchanging packets, in fact are running the TELNET protocol. This gives error control but allows arbitrary system commands to be executed on the remote system just like a bare modem&UART connection. The user types a magic escape character or command which invokes FTP mode. Here's what happens: Sub-FTP is called, which: (1) Sends a node-control message asking Please-Do OPNSTR of FTP1. If the reply is a refusal, the other node can't stack application programs. (2) Assuming it is acceptance, the stream range is used to set up mapping. (3) Enter user-FTP command loop as before, which eventually exits. (4) Clean up streams. (5) Control is returned to the TELNET program for talking to remote host.  Date: 26 March 1983 21:16 EST From: Robert Elton Maas Subject: FTP1 use, part two of three today To: PCNET-DESIGN @ MIT-MC MODEM2-style user-FTP1. The user and host computers are already connected via modems&UARTs, but no error-control is in effect. The user types a magic escape character or command which invokes FTP mode. Here's what happens: (1) Semi-HELLO is called, to stay connected modemwise but now to start up the remote PCNET server, negotiate sub-mode, wait for end-of-HELLO brackets, then inside packet mode to exchange node IDs. (2) Send OPNSTR node-control message to start remote FTP1 program, get back ack and stream range, set up stream mapping. (3) Enter user-FTP command loop as before, which eventually exits. (4) Clean up streams. (5) Semi-BYE is called, to terminate PCNET mode but remain connected at the modem level. (6) Control is returned to the transparent-TTY mode for talking to remote host.  Date: 26 March 1983 21:10 EST From: Robert Elton Maas Subject: FTP1 use To: PCNET-DESIGN @ MIT-MC I haven't had time to send my straw-man proposals for design of FTP1 in originate (master, user) mode, but since I haven't yet gotten any replies to my proposals for stacking application programs and for FTP1 in slave mode I guess the rest of you haven't had any time to read what I already sent out... ---------------------------------------------------------------- Main command loop of user program for FTP1 protocol. The main command loop is the same in all three modes, so I'll describe it once here. The program first executes any commands that were passed via JCL if appropriate to the mode in use. Then it loops on user input. Each user input is a command, which may set some internal mode flag, may invoke some operation in conjunction with the slave FTP1 program on the other node, or may exit the command loop. The individual commands may take arguments on the same line, a la FTP at SU-AI, or may prompt for arguments individually a la FTP on MIT-MC. When the DONE (BYE) command is typed, the FTP command loop first sends a BYE command to the remote FTP1 slave program to make it exit, then this local FTP command loop exits itself. That's about all there is to the overall design of the user command loop. What happens before entering this, and what happens after the DONE command is typed and the command loop exits, is different in each of the three modes. ---------------------------------------------------------------- ARPANET-STYLE user-FTP Initially the user's computer isn't logically-connected at all to the host computer. The user starts up the FTP program, which asks for the remote host ID (or gets it from JCL). The FTP program then does: (1) Call the HELLO function, which establishes modem connection then starts up the remote PCNET server program then negotiates initial PCNET submode then waits for end-of-HELLO brackets; then inside PCNET packet protocol the HELLO function sends a NODE-ID message and gets back the remote node id likewise. (2) Send an OPNSTR control message to request remote FTP1 program to be started, gets ack and stream range, sets up stream mapping. (3) Call the FTP1 command loop described earlier, which eventually exits. (4) Clean up any streams used by the FTP1 program (optional since the whole program will exit next). (5) Call the BYE function, which sends a Please-Do BYE node-control message to the other node, then gracefully or not disconnects from the remote host.  Date: 20 March 1983 22:17 EST From: Robert Elton Maas Subject: Stacking application programs To: PCNET-DESIGN @ MIT-MC Simpleminded PCNET implementations have the application program talking to the directing layer through a very simple PREAD/PWRITE interface. PREAD checks the PREAD-satisfy buffer to see if there's a block already received during the last PWRITE cycle. (Tutorial for those not familar with this: When a block is sent out, a full half-duplex cycle is done, transmit-then-receive, before returning to the middle levels of protocol. But if the block wasn't acknowledged, another half-duplex cycle is done. This continues until the block is acknowledged. Finally then control can be passed up to the directing layer. In the course of getting an ack, either an empty block or a directing block is received. If the latter, it's stuck in the PREAD-satisfy buffer, pending when it's requested by the next PREAD. -- In full-duplex or more-than-1-out-of-8 mode, it's a little more complicated, but still any nonempty block received is stuck in a PREAD-SATISFY queue pending actually being requested by PREAD.) If there is a block already waiting, PREAD removes it from the buffer/queue and processes it, else it causes an empty block to be transmitted, and after that empty block is acknowledged (which requires at least one half-duplex cycle), the PREAD-satisfy buffer/queue is checked again. If it is still empty, a failure (no data available) result is returned, else the just-arrived block is processed. PWRITE makes sure the PREAD-satisfy buffer is empty (else the PWRITE can't proceed, because the acknowledgement of the outgoing block might ride a non-empty block, which has no place to go because the PREAD-satisfy buffer has room for only one block in simple mode). Assuming the PREAD-satisfy buffer is empty, the block is transmitted, and acknowledgement is waited-for, causing at least one half-duplex cycle. As before any nonempty block coming back is stuck in the PREAD-satisfy buffer. There are actually two flavors of PREAD and PWRITE, obtained by different entry points, or by an extra argument when called; one when called by the node-control program (which uses stream 0 for all its messages), and one when called by a normal application program (which never uses stream 0). PWRITE checks its argument to make sure neither type of "application program" is trying to violate protocol by using a stream it isn't supposed to use. PREAD checks the stream number of the block it has fetched from the PREAD-satisfy buffer to make sure it is zero or nonzero depending on whether node-control or a normal application program called it. Any attempt to send data on a nonzero stream while node-control is in command is a violation of protocol, because one must first invoke an application program before sending data to it. Any attempt to send data on stream 0 while an application program is in control is a violation of (Simple mode) protocol, because asynchronous (unsolicited) node-control messages aren't permitted, because application programs don't have the foggiest idea what to do with them. Going beyond simple mode now, there are two major ways we've considered for implementing asynchronous (unsolicited) node-control messages, i.e. allowing a node-control message to arrive and be properly handled even though this happens from inside a pending PREAD that was invoked by an application program, not the node-control program. METHOD 1 -- Reversing the caller/callee relationship between node-control and the directing layer. METHOD 2 -- Allowing node-control to be re-entrant, i.e. allowing a second incarnation of it to be invoked recursively inside a pending higher-level incarnation. Method 1 requires that we have UNPREAD whereby node-control or at least part of it is called from inside (underneath, i.e. as a subroutine of) the directing layer whenever the pending PREAD is from some normal application program but the actual block received is addressed to node-control. Unfortunately this method rather requires that node-control be contorted to be a state machine called by its I/O channels instead of a normal program that uses I/O as subroutines. Method 2 requires that all local variables used by node-control be kept on the stack whenever this sort of thing might happen unexpectedly, so that the local variables won't be clobbered by the recursive call to node-control. It also requires that globals be used to keep track of things that are in progress, so the two incarnations of node-control don't try to do things that might "step on each others toes", like start up a MAIL1 program when there's already one in effect. But these globals are needed with the other method anyway. My "straw man" proposal will use the reentrant node-control method. The node-control program, first incarnation of it in this case, sits at the top of all the software we'll be talking about now, in particular on top of the directing layer and on top of all slave-mode application programs that might get invoked. This is necessary because the node-control program makes the decision to exit PCNET online protocol, via exchange of Please-Do/I-Will Bye messages. PREAD as above knows whether it was called by node-control (any incarnation of it in this case) or not. When node-control has called it, any traffic on any nonzero stream is illegal because either the toplevel node-control did the call (in which case no application program is currently in operation) or some lower-level node-control incarnation did the call (in which case some negotiation is in progress, which must complete before control can be returned to an existing application program or given to a new (stacked) one. Of the four possible cases (node-control called, or app'l program called; block actually received is on stream 0, or not) only the case of block on stream 0 while PREAD pending for application program is now different. When PREAD is called in either of the two easy cases (node-control calls and block actually on stream 0; app'l calls and block actually on ononzero stream) it's handled as in simple mode, the PREAD returns the block to the calling program after extracting the stream number and EOD bit as separate parts of the returned result. The illegal case (node-control called, but block for nonzero stream) still generates a fatal error. In the newly-legal case, some application program has called PREAD (probably indirectly via PREADW) and is expecting a block of data on a nonzero stream, but a block addressed to stream 0 is sitting in the PREAD-satisfy buffer instead. In this case, the directing layer calls the recursive node-control program and upon return from it goes back to waiting for a block addressed to a nonzero stream. After the new incarnation of the node control program is called, before it returns, here's what happens... First the node-control program issues its own PREAD, which can now be satisfied by the block that has been sitting in th PREAD-satisfy buffer. It then processes this block the same the toplevel incarnation of node-control would, with minor differences. Just like the toplevel node-control, requests for starting up application programs are honored or refused, except that some streams may be already in use thus different streams will be allocated from what a toplevel request might have allocated. Any application program started up in this way would sit just under the current incarnation of the node-control program, just as the application program started earlier sits underneath the toplevel node-control. Upon return, execution proceeds with the recursive node-control, just like when the first application returns execution proceeds with the toplevel node-control. There may be some limitations on the number of applictions that can be stacked, and probably no application can be stacked underneath itself, thus sometimes a refusal to start up an application program at this level may occur even when permission may have been granted at the toplevel. But the only major difference between the node-control program at this level is that upon completion of any particular node-parameters negotiation or any calling of an application program (after first flushing streams used by it), the recursive node-control IMMEDIATELY returns to the directing layer rather than waiting for a Please-Do/I-Will Bye exchange. Only the toplevel node-control stays on-line between major actions, exiting only after exchanging Please-Do/I-Will Bye messages (or if communication breaks down totally). Summary of subroutine calling levels. At the left is the topmost program considered here, to the right are levels of subroutines called. Upon return from any subroutine, control proceeds in the parent routine that is just to its left. Routines listed normally are in effect for the duration of this mode, while those shown in brackets are called repeatedly to handle smaller steps within this mode. Initially after starting up PCNET server program: Node-control, HELLO routine, [modem control, hardware] After establishing starting mode and entering PCNET packet protocol: Node-control, PREAD, directing layer, [lower levels, modem control, hardw...] After receiving a Please-Do NODE-ID message: Node-control, ID handler To reply to the Please-Do NODE-ID message: Node-control, ID handler, PWRITE, directing layer, [lower levels, ...] Back to waiting for next request: Node-control, PREAD, directing layer, [lower levels, modem control, hardw...] After receiving a Please-Do OPNSTR message asking for FTP1: Node-control, OPNSTR handler Replying affirmatively: Node-control, OPNSTR handler, PWRITE, directing layer, [lower levels, ...] Streams opened and application program invoked: Node-control, OPNSTR handler, FTP1, FTP1 initialization stuff FTP1 awaiting a request: Node-control, OPNSTR handler, FTP1, PREAD, directing layer, [lower ...] FTP1 accepting the request: ...(2), FTP1, FTP1-specific-handler, PWRITE, directing layer, [lower ...] FTP1 transferring a file: ...(2), FTP1, FTP1-specific-handler, [PREAD&PWRITE, directing layer, ...] * **************************** * ********************** * ...(5), directing layer, recursive node-control Node-control issues PREAD to see the request: ...(5), directing layer, recursive node-control, PREAD, directing layer, [...] It's a Please-Do OPNSTR request, asking for MAIL1; accept it: ...(6), recursive node-control, OPNSTR handler, PWRITE, directing layer, [...] Starting MAIL1, awaiting service request: ...(7), OPNSTR handler, MAIL1, PREAD, directing layer, [...] Transferring short message: ...(7), OPNSTR handler, MAIL1, service handler, [PREAD/PRITE, ...] Done, awaiting next service request: ...(7), OPNSTR handler, MAIL1, PREAD, directing layer, [...] Got Please-Do Bye, sent I-Will Bye, returned to caller, i.e. OPNSTR handler. ...(6), recursive node-control, OPNSTR handler, routine for closing streams OPNSTR handler done, returns to caller: ...(5), directing layer, recursive node-control Recursive node-control always returns after each task is done, directing layer resumes control: ...(2), FTP1, FTP1-specific-handler, PREAD or PWRITE, directing layer If PWRITE was pending, it returns; if PREAD, it returns with failure result but of course PREADW immediately retries. In any case, FTP1 is back to exchanging info to finsh the task that was in progress: ...(2), FTP1, FTP1-specific-handler, [PREAD&PWRITE, directing layer, ...] Task done at last, back to FTP1 slave command loop: ...(2), FTP1, PREADW, [directing layer, ...] Got Please-Do Done, answering I-Will Done: ...(2), FTP1, PWRITE, [directing layer, ...] FTP1 exited: Node-control, OPNSTR handler, closing streams routine OPNSTR handler exited, node-control awaiting request: Node-control, PREADW, [PREAD, directing layer, ...] Got Please-Do Bye, replying: Node-control, PWRITE, [directing layer, ...] Final actions: Node-control, BYE operations Node control program exits to system wait loop, waiting for phone to ring.  Date: 20 March 1983 19:28 EST From: Robert Elton Maas Subject: FTP1 in use -- more intro, and slave To: PCNET-DESIGN @ MIT-MC Although it's possible for the answer node to send a node-control message asking Please Do OPNSTR (invoke an application program and open streams to it), this isn't common, and will be virtually unknown for the FTP1 protocol. Thus we assume originate=user and answer=server. Although it's possible for the server FTP1 program to send to the user FTP1 program such things as Please Do Send-Text-File, this isn't common usage. Thus we assume user=master and server=slave, that is that the user FTP1 program originate all requests for services, and the server FTP1 program merely answer them and perform duties as requested (limited by preset access restrictions). This message concerns only the answer=server=slave FTP1 program. The three following will concern only the originate=user=master FTP1 program. ---------------------------------------------------------------- SERVER FTP1 -- SLAVE ONLY Before the server FTP1 application program is invoked, several things happen: (1) The telephone rings, waking up the operating system and causing the call to be answered; (2) By some JCL, or by default, the PCNET software is started; (3) By means of the HELLO protocol, initial mode is selected and the actual PCNET protocol for exchanging packets and delivering them to application programs (only the node-control program initially) starts running; (4) Optionally the node IDs are exchanged and/or node parameters are changed and/or other application programs are run, before the FTP1 program is requested; (5) Finally the FTP1 program is requested, either at the top level or stacked underneath some other program such as TELNET. Streams are allocated, and the FTP1 server program is started. After the server FTP1 application program exits, several things happen: (1) Streams allocated to it are flushed; (2) Control reverts to what was in control before, either the node-control program or to some application program that had been running but was stacked; (3) Optionally node parameters can be changed and/or other application programs can be run; (4) A Please-Do Bye is issued, starting the BYE action, which gracefully or ungracefully terminates the telephone&modem&UART connection. How to stack application programs, and how the FTP1 program itself works, are the issues to resolve here... The FTP1 program itself is pretty trivial in design. At its top level it issues a PREADW to receive a service request on its personal control channel. If it receives anything on a different channel, that's a protocol error, and it may ignore it or generate a fatal error. If THROW/CATCH is implemented, that's a good way to handle fatal errors. Otherwise it should EXIT back to whatever called it, but returning an error result which signals that code to pass the fatal error up further until it reaches the top level of the whole node, which immediately hangs up the phone if possible. [It would be good for us to discuss the most generally-effective method for breaking off contact with the other node after finding it is violating protocol; since some hosts don't give the use program the power to hang up the phone.] Assuming the PREADW succeeds on the correct channel, the first byte of the block received is checked for a valid Please-Do opcode. If so, that operation is executed to completion, whether it be transferring a file or requesting information such as a directory or a list of commands. If the opcode isn't known, an I-Won't is issued in reply to the exotic Please-Do that was received. Other flavors of opcode received should be ignored or treated as protocol violations. Execution of each particular Please-Do opcode is handled by a subroutine that checks the arguments for syntactic correctness, checks the environment to see if that request is acceptable (requested file exists, filename for writing doesn't already exist, access is permitted to the directory, ...). If acceptable, it issues an I-Will and proceeds to carry out the operation, else it issues an I-Won't and immediately returns (to the PREADW command-wait loop above). One opcode is handled in a special way, Please-Do Quit. I is always answered I-Will Quit after which the FTP1 server program EXITs with a success returned value/flag, so the calling code will proceed normally. [Method for stacking application programs follows in next message, then the three modes of user-FTP1 originally promised.]  Date: 20 March 1983 18:41 EST From: Robert Elton Maas Subject: FTP1 in use -- "straw man" implementation proposal - intro To: PCNET-DESIGN @ MIT-MC Well, this mailing list / discussion&design working-group now has eleven members counting myself, so I guess it's about time I start things rolling with my promised "straw man" proposals for file transfer. The protocol for MAIL1 allows sending files qua mail, header in text followed by a blank line followed immediately by the binary file. This protocol allows forwarding the same as for electronic mail. The protocol for FTP1 negotiates directly with the end in real time, thus making forwarding impossible, but allows more interactive use such as we're used to with Arpanet FTP and MODEM2. This proposal will deal only with use of FTP1, not MAIL1 protocols. Application programs fall into two general classes: master and slave. The slave is easy, it gets invoked only when requested by the other node via an OPNSTR node-control message, performs duties as instructed by FTP1 opcodes&arguments, as limited by any access restrictions that may be programmed into it, and exits back to the node-control process when told "goodbye" by the FTP1 program on the other node. The master program is more interesting. It gets invoked under user command, and must then establish contact with the remote (slave) FTP1 program. (Strictly speaking the FTP1 master program might be invoked by an event timer and might run unattended, performing tasks that had been queued; but the protocol is designed to be interactive, and a lot of function is lost when run unattended. For running unattended, perhaps the MAIL1 protocol should be used instead.) There are three times that a user might invoke an FTP program: - When not connected at all, such as on Arpanet; The FTP program must first establish a network connection (which involves first establishing a modem&UART connection then invoking the PCNET software), then invoke the FTP1 slave program. - When connected using bare modems&UARTs such as when talking to a microprocessor-based CBBS (Computerized Bulletin-Board System) or to a direct-dial port on some other kind of host; The FTP program doesn't have to establish a modem&UART connection, but it does have to invoke the PCNET software before it can invoke the FTP1 slave program. - When already connected using PCNET but running TELNET, and desiring to switch to FTP1 without having to drop out of PCNET protocol and re-establish the PCNET connection; The existing TELNET program must be either flushed or pushed (stacked). Flushing the TELNET has the advantage that the mechanism for stacking application programs doesn't have to be implmented for this to work, but the disadvantage that the TELNET connection is disrupted, the TELNET login must be killed (logout) or detached, disrupting any activities that may have depended on continuous login. Pushing the TELNET program doesn't disrupt the login but does require the extra software for stacking application programs. The next four messages will describe my ideas for implementing these four modes of FTP1 operation: slave, offline-to-FTP1, online-non-PCNET-to-FTP1, and pushing TELNET to run FTP1. Flushing TELNET to run FTP1 is trivial and distateful so I won't consider it. In each proposal I'll assume a strictly subroutine-calling software system, with no co-routines or multi-processing (except that if TELNET protocol is used we assume the host system is a timesharing system or somesuch, with pseudo-teletype or lower-fork or somesuch for allowing a login from underneath a user program such as the PCNET server; the originate machine is always assumed to be a single-user system or a single user-job on a time-sharing system). [four messages follow...]  Date: 16 March 1983 13:31 EST From: Robert Elton Maas Subject: PCNET-DESIGN To: PCNET-PROTOCOL @ MIT-MC I'm going to be forming a new mailing list to discuss overall design aspects of PCNET and its software. This will not deal with protocol, that is agreements between machines as to the data exchanged between them and its meaning, thus I've decided not to use the PCNET-PROTOCOL list for this discussion, but since the people on PCNET-PROTOCOL are the ones most active currently (other than the workshop people, who have their hands full writing code), I'm sending this query here instead of to the general INFO-PCNET mailing list. Specific subjects to be discussed: How to maintain network directories telling NODE-IDs (which includes geographical location and phone number) and login JCL and modes available; How to organize the software for FTP1, MAIL1 etc. to permit all the modes of operation (interactive, unattended automatic) we've envisioned; ... Anyone wanting to be on this new list, contact me asap. I'll be presenting some "straw men" proposals for software organization within a few days.  Date: 17 March 1983 03:30 EST From: Robert Elton Maas Subject: New explanation of our layers of protocol and corresponding software To: PCNET-PROTOCOL @ MIT-MC, PCNET-DESIGN @ MIT-MC, PCNET-WORKERS @ MIT-MC (Persons on more than one list, pardon the duplication.) Now that I've been reorganizing PCNET knowledge in a tree structure, I've decided to create an introduction to PCNET protocol in this form, keeping all the details and explanations in sub-frames in the tree, with only the introductory material and simple listing of reasons for each layer at the top level. Below is the top level of this new information frame. I'm sending it to all three working-group lists because all members on all three lists need to understand the layered PCNET protocol, and previous documents which were not tree-structured tended to be confusing so that many of you still don't understand what you're trying now to modify&augment (PCNET-PROTOCOL members) or structure (PCNET-DESIGN members) or actually write code for (PCNET-WORKERS members). As usual, if you don't have an account on an ITS system (thus can't use the INFO program directly) and you want one of the sub-frames pointed at by the menu items (lines starting with *), send me the menu item line and I'll MAIL you the frame it points at as soon as it has been written (yes, this is top-down structured document writing; first the main outline, then the lower-level stuff later!). File: PCNET, Node: New layer run-thru, Up: Protocol Suppose we have two computers on opposite ends of a telephone line, with modems to convert between binary and analog signals, and a UART to convert between octets of binary data and carefully-timed sequences of bits in real time. Thus either of the two computers can send an octet of data to the other which will be received it if no phone line noise interefered with the analog signals used to carry the data. Suppose we an application program on one of the two machines that wants to communicate to an application program on the other. It wants to be able to open several data channels (streams) to the other so it can send commands on one channel and data on another, or perhaps several kinds of data on different channels. It wants the receiving program to be able to distinguish data on the different channels, and it doesn't want the data to be damaged (deleted, duplicated, changed, rearranged, put on the wrong stream) en route. The receiving program doesn't want to hassle with bad data or temporary errors. It wants to receive exactly the correct data on exactly the correct stream, without being bothered by temporary error conditions that can be corrected, but it does want to be told if the communication link has completely broken down preventing further data transfer. The purpose of the lower&middle layers of PCNET protocol is to fill the gap between the needs of the application program and the services offered by the low-level software that drives the telephone-interface hardware, i.e. to insulate the application program from the error-prone telephone line and to provide the multiple streams and other facilities not available on a bare modem&UART link. Below are the various problems that exist in two application programs trying to communicate with each other, and the solutions provided by various micro-layers of PCNET protocol. (There are two major layers, the Link layer and the Directing layer. But the Link layer is subdivided into about six smaller layers called "micro-layers", while the Directing layer is subdivided into about two microlayers.) Menu: (Numbers 0 thru 7 indicate the sequence in which all these microlayers are stacked on top of each other when putting them all together to make the full PCNET protocol.) * 0-1 Interface:: Interface by which software can easily send and receive raw data on the modem&UART. This is what's provided by the hardware-level interface software and available to be used by PCNET-specific software. * 7-8 Interface:: Interface by which an application program sends and receives data on various streams. This is what the application program wants to see available for its use, instead of what's provided by the level 0-1 interface. motivation for each micro-layer, rearranged into teaching sequence... * 7str Motive:: How to multiplex multiple streams on one modem? * 7eod Motive:: How to detect end-of-file on a particular stream? Needs are satisfied by the Directing layer * 5 Motive:: How to make sure only good data gets through? Needs are satisfied by the Validating microlayer * 6 Motive:: How to retransmit when data didn't get through the first time? Needs are satisfied by the Sequencing microlayer * 2 Motive:: How to recognize start&end of a block of data on the line? How to assure that the UART will be correctly framed at the start of a block even if it was misframed from noise during the preceding block? Needs are satisfied by the packet framing microlayer * 1 Motive:: When genuine full-duplex operation is impossible, how to decide whose turn it is to speak without getting confused? Needs are satisfied by the half-duplex turnaround handshake microlayer * 3&4 Motive:: If data in the block conflicts with framing or half-duplex-turnaround characters, how to avoid confusing the two? What if the operating system doesn't allow 8-bit data to be sent/received? Needs are satisfied by the translating microlayer Summary, micro-layers put back into normal sequence as data feeds through each micro-layer to the next: Application program sits at the top, transmitting data downward and receiving data that arrives at the bottom and makes its way to the top. Application-level command to other program "PLEASE DO ACCEPT MAIL" Encoded as [8-bit opcode and binary arguments], on some stream. Sent down via a call to PWRITE. Received on other node via PREAD 7 Directing layer Block prefixed by header octet telling stream number and EOD bit. 6 Sequencing layer Data object has sequence number and acknowledgement number. 5 Validating layer Numbers packed into one octet, checksum or CRC in two octets, appended to the [directing octet & opcode octet & args] from above. Now have: [dir. octet & opcode octet & args & sequence octet & cksm] 3&4 Translating layers All data from just above translated into Radix-41, which doesn't include any characters that would conflict with framing atsigns or turnaround characters below, or data kept in binary as-is except characters that would conflict with framing/turnaround or with quoting mechanism are quoted. 2 Packet framing layer Each block now has atsigns around it to refreame the UART and to signal the start of each block. 1 Half-duplex turnaround handshake (Used only when in HDX software mode using FDX modems.) Nodes take turns sending one or more packets, sending trailing brackets, watching for lead-in atsigns from the other node within ten seconds sure it saw the turnaound (if not, retransmit turnaround and wait for atsigns again), then buffering up the other node's transmissions until receiving the trailing brackets from the other node, immediately sending leading atsigns to acknowledge turnaround, then processing the data that has been buffered and preparing the outgoing data to be sent as packets at the top of this loop. 0 Modem interface software UART/modem hardware sit at the bottom. (Well, actually the telephone line is at the VERY bottom.)  Date: 16 March 1983 23:20 EST From: Robert Elton Maas Subject: Initial test message and intro To: PCNET-DESIGN @ MIT-MC Ok, I've created the PCNET-DESIGN mailing list, linked it into the mailing system, and now am sending this test message. Earlier today I drew on paper subroutine-calling charts for FTP1 in three originate modes (from offline a la Arpanet FTP; from raw modem talk a la MODEM2; from inside formal TELNET protocol a la IMSSS/SUMEX linker program) and one answer mode (slave only). I'll be sending these straw-man designs out to you-all for consideration. Later I plan to work out an overall design for an electronic mail system, complete with mail-monger (RMAIL, BABYL, MM et al), host table with JCL and modes available, automatic forwarding, and all online software. If anybody else has designs to submit to this forum, feel free to do so. Let's all stick our straw men up on a flagpole and see whether they get saluted or blown away .