Movatterモバイル変換

Network Working Group                                Ed Belove (Harvard)Request for Comments: 56                            Dave Black (Harvard)                                                       Bob Flegel (Utah)                                                 Lamar G. Farquar (Utah)                                                               June 1970Third Level Protocol                            Logger Protocol                          General DescriptionIn our view of the world each host has a set of four programs to allow auser teletype to communicate with a foreign monitor. The exactimplementation of these programs is highly installation-dependent.  Thusall explanations are meant to describe functional characteristics ratherthan design.The four programs come in two male/female pairs. A user employs a send-logger at his site to communicate with receive-logger at the appropriateforeign site in order to establish a full duplex link between the user'steletype and the foreign machine's monitor. This puts him in theequivalent of a pre-logged in state at the other machine.  After thelink has been established, the two loggers drop out of the picture, andthe user is left talking to a sender in his machine, whose main functionis to take input from the user's teletype and send it down the link thatwas established by the loggers to the receiver in the foreign host whichpasses it along to its monitor (making it look like input from a localteletype). Replies from the foreign monitor are given by it to thereceiver, which transmits them back along the link to the sender, whichoutputs them on the user's teletype. The sender and receiver in eachmachine must either exist in multiple copies, one for each network user,or there must be a single copy which can handle all of the networkusers. The loggers, however, need be able to handle only one user at atime, since their task is quickly accomplished, leaving them free tosatisfy other requests.  However there should be some method of queuingrequests that can not be satisfied immediately. A less satisfactoryalternative would be to give a busy message to any user who tries to usethe logger while it is busy. (This, of course, does not preclude thepossibility of an installation having a re-entrant logger, or of havingmultiple copies of the logger.)The receive-logger should be user zero in every machine and shouldalways be listening to socket zero. (This same thing can be accomplishedby having the NCP intercept all messages to user zero, socket zero, andsend them to the receive-logger; but it is simpler and cleaner to have                                                                [Page 1]

the logger actually be user zero and have the NCP handle its messagesthe same as everyone else's.)When the send-logger is called, it pulls a pair of unused sockets (2Nand 2N+1) from a pool of free sockets and CONNECT from 2N+1 to User 0,Socket 0 in the desired foreign host. This activates the receive-logger,which accepts the connection if it has an available slot for the foreignteletype. He then immediately closes down this connection to allow linksfrom other sources to be initiated. If, on the other hand, there is noroom for the foreign teletype (or if, for some other reason, thereceive-logger does not wish to connect) the attempted link to socketzero is refused. This notifies the send-logger that he cannot log on theforeign host and it then notifies the user of this fact. There is noguarantee, however, that the close was actually sent by the foreignlogger. It could have been sent by the NCP if, for example, the pendingcall queue for the socket was overloaded.If the link to socket zero has been accepted (thus indicating that thereceive-logger can accommodate the request) after closing that link, thereceive-logger picks an available pair of sockets (2M and 2M+1) from itspool, and connects from 2M+1 to 2N. (It found the identity of 2N whenits listen was answered by the link with 2N+1.)  The send-logger hasmeanwhile listened to socket 2N and now accepts the link, and CONNECTSfrom 2N+1 to 2M. The receive-logger has been listening to this socketand accepts the attempted link.At this point, there is a full duplex connection between the twologgers. They then activate the sender and receiver, which handle allother communication between the user and the foreign monitor.  (Thesenders and receivers can be part of the loggers, or can be called bythem, etc.)When the user is finished and escapes back to his monitor, it is up tothe sender to close down the links. On the receiving end, it would behighly desirable for the NCP to notify the receiver of this fact, so itcould log the user off (if he had failed to do that himself) and couldfree any resources that he had been using.A more formal outline of the proposed protocol described in the scenarioabove follows:                                                                [Page 2]

   1. Stable state: receive-logger at foreign host listening to User 0,   Socket 0.   2. Local user calls send-logger.   3. Send-logger calls CONNECT (port, 2N+1, <foreign host#,0,0>).   4. Send-logger calls LISTEN (port, <local host#, user#, 2N>).   5. Foreign logger's LISTEN is answered, and he is told local user   number, host and #2N+1.   6. Foreign logger looks for available sockets (2M and 2M+1).  If they   exist and it is able to establish connection, it accepts and then   immediately closes the link.   7. Foreign logger calls CONNECT (port, 2M+1, <local host#, user#,   2N>).   8. Foreign logger calls LISTEN (port, <local host#, user#, 2M>).   9. Send-logger has listened to 2N and accepts link, then calls   CONNECT (port, 2N+1, <foreign host#, user#,2M>).   10. Receive-logger, which is listening on 2M, accepts link.   11. Loggers activate appropriate handlers.   12. When the user is finished, sender closes down both links.This basic method of establishing a full duplex connection should bestandard throughout the network. The particular way each installationhandles the implementation of the sender, receiver, and the two loggersis of no consequence to the network and is highly machine dependent.(Even the fact of needing a sender and receiver is machine dependent inthat some members of the network might be able to handle their functionsin other ways.) However, some conventions must be established regardingcommunication between the sender and receiver, or their equivalents.Network Standard CodeIn order to facilitate use of the network, we propose the conventionthat all teletype-to-foreign-monitor communication be done using 128character USASCII. (This is the code used by the IMP's and is in theappendix to the IMP operating manual.) It makes sense to requiremachines to make only one conversion to a standard code, than to have tomake conversions to every code on the net.                                                                [Page 3]

In addition, since most of the network machines use ASCII as theirinternal character code, it will be no trouble for them. Even thosemachines that use a different code must translate to and from ASCII inorder to communicate with local teletypes. Extending this translation tothe network should cause very little trouble. We envision thistranslation as taking place in the sender and receiver, but again thatis implementation dependent.If ASCII is adopted as a standard, we would suggest that all non-ASCIImachines create a monitor to the machine's internal code. This wouldmake the complete character set available to those who wished to use it(and were willing to write a simple conversion routine for the localmachine.) In this way, those users who wanted to could use any machineon the net from their teletype, without requiring their machines to haverecords of all the network codes, and yet could use the full power ofthe foreign machine if they wanted.Again, this standard applies only for teletype-to-foreign-monitorcommunication.Break CharactersA standard way of handling the break character has to be established forthe network and be included in the protocol. Problems with the breakcharacter arise in several contexts. First, there are two distinctpurposes served by the break character. One is as a panic button. Thissays, "I do not care what is happening, stop and get me out to monitorlevel now." This command is executed immediately upon receipt, and ismost commonly used to get out of a program that one does not want to bein (e.g., one that is in an infinite loop, etc.)The other purpose that is served is that of an exit from a subsystem, oron a machine with a forking structure as a method to get back to thenext higher level fork. This second purpose is not an immediate one inthat the user wants the system to finish all that he has told it to dobefore exiting.We assume that there does not exist in every system 1) a way ofperforming each of these functions, or 2) a clear cut distinctionbetween the calling and operation of the two. Furthermore, there aresubtle distinctions as to how each system treats the commands.The panic button function can easily be performed by the proposedcontrol command <INT>. This function must be accomplished by using acontrol command, since a program can enter a state where it is acceptingno input: hence, the program cannot be aborted by sending it a messagedown the teletype link. There is no reason to worry about the racecondition caused by sending this command down the control link since its                                                                [Page 4]

whole purpose is to force the machine to disregard everything else theuser has sent.In our implementation of this, we would ask the user to specify to thelogger a seldom used character that he wants to be his foreign panicbutton. Then, it would be a simple task for the sender to map thischaracter into an <INT> command, which the foreign machine mustinterpret properly. This scheme would work well for most machines, butsome may lend themselves to different ways of generating the <INT>.The other problem that presents itself is what to do if the foreignmachine's "exit" character is the same as the local machine's.  Theproblem is that while a user is talking to a foreign machine, he wouldwant to be in a transparent mode, where everything he types is sentdirectly to the other machine. The way he would get himself out of thismode is to type either his machine's "exit" character or its panicbutton. Thus, if the foreign machine has the same one, there would be noway to send it. The way out of this is the same as above--merely amapping of another seldom used character into the foreign machine's"exit" character. This type of mapping can be carried as far as eachinstallation deems necessary. Giving the user complete control overtranslation is helpful in that it allows him to user characters that histeletype cannot generate.Command Message FormatsEach site should establish its now conventions about when to send amonitor command string, and in what size chunks. When performing aroutine operation, one might want to send several command lines as asingle message. If working with the monitor as usual, a reasonable breakpoint might be at every carriage return. When using a highly interactivelanguage such as QED, one might decide character-by-charactertransmission was a necessity. We feel that each user should have thechoice between these three methods (and possible more). Furthermore, theuser should be able to change between each mode at will. The differencesin syntax of the send-message commands mentioned above should be noted.For the first, a special send-message command character must be defined,and it should not be sent along with the message. For the second, thecarriage return acts dually as the send-message command and as a commanddelimiter. Therefore it must be sent with the message. Finally, the caseof character-by-character transmission with its implicit send commandshould pose no significant problems.                                                                [Page 5]

The preceding discussion is meant to imply also that the receiver mustbe able to buffer up each of the above types of transmission into a formacceptable to its own monitor interface.In addition, all echoing should be done in the local host, with theforeign machine suppressing its echoes (if it can.)We would like to thank Carl Ellison (of Utah) for his valuablesuggestions and criticisms of this work, and Jim Curry (of Utah) for hisencouragement and support of the effort.       [ This RFC was put into machine readable form for entry ]          [ into the online RFC archives by Jon Ribbens 7/97 ]                                                                [Page 6]