Network Working GroupRequest for Comments #98Network Information Center #5744 Logger PRotocol Proposal Edwin W. Meyer, Jr. Thomas P. SKINner February 11, 1971 With the ARPA Network Host-to-Host Protocol specified and atleast partially implemented at a number of sites, the question of whatsteps should be taken next arises. There appears to be a widespreadfeeling among Network participants that the first step should be thespecification and implementation of what has been called the "LoggerProtocol"; the Computer Network Group at project MAC agrees. The term"logger" has been commonly used to indicate the basic mechanism to gainaccess (to "login") to a system from a console. A network logger isintended to specify how the existing logger of a network host is tointerface to the network so as to permit a login from a console attachedto another host. To implement network login capability now seems quitedesirable.In the first place, it is natural for Network participants towish to learn more about the remote systems in the immediate fashionafforded by direct use of those systems. In the second place, thetechnical problems introdUCed by remote logins are probably less complexthan those involved with such further tasks as generalized filetransfer; thus, a Logger Protocol could be implemented relativelyquickly, furnishing additional impetus and encouragement for takingstill further steps. In order to furnish at least a basis for discussion (and at mostan initial version of a Logger Protocol), we have prepared thisdocument, which attempts to present a minimal set of conditions forbasing a Logger Protocol. This proposal covers only the mechanism foraccomplishing login. What occurs following login is not discussed here,because we feel more eXPerimentation is necessary before any protocolfor general console communication can be established as standard. In itsabsence, each site should specify its own experimental standards forconsole communications following login. Some of the points raised in this document have already reacheda certain level of consensus among network participants while at leastone point is rather new. It should be clearly understood, however, thatwe feel regardless of the disposal of particular issues, Networkwideagreement should be reached as soon as possible on some general
protocol. This is all the more desirable in view of the fact that it isquite likely that certain points which should be covered in thisprotocol will only become apparent during the course of implementation;therefore, the sooner a common basis for implementation can be reached,the sooner a more rigorous protocol can be enunciated. Before turning to 1) a discussion of the points with which todecide the protocol should deal, and 2) specifications for the currentstate of the protocolm we feel that we should acknowledge theconsideration that a case could be made for avoidingthe difficulty ofgenerating a Logger Protocol by simply declaring that each host mayspecify its own, perhaps unique, preferences for being approached overthe Network. Although such a course is certainly possible, it does notseem to us to be desirable. One reason for avoiding such a course issimply that following it hamper general Network progress, in thatadressing the task of interfacing with some 20 systems is bound to moretime-consuming than to interface with "one" system, even though eachindivudual one of the former, multiple interfaces might be in some sensesimpler than the latter, single interface. Another consideration is lesspragmatic, but nonetheless important: agreement on a common protocolwould tend to foster a sense of Network "community", which would tend tobe fragmented by the local option route. After all, the Host-to-HostProtocol could have been handled on a per-host basis as well; assumedly,one reason why it has not had something to do with similar, admittedlyabstract considerations.Context Structurally, the mechanism serving to login a user over the Networkconsists of two parts, one part at the using host, the other at theserving host. The using or local host is the one to which the userstypewriter is directly connected; it contains a modulewhich channels andtransforms communications between the Network connection and thetypewriter. The serving or foreign host provides the service to be used;it contains programming that adapts the logger and command system to usethrough the Network rather than a local typewriter. There are three different phases to a login through the network. 1. During the connection phase the users console is connected to the serving logger through the network. This is, of course, the most important phase from the protocol viewpoint. 2. The second or dialog phase consists of a sequence of exchange between the user and the logger that serves to identify the user and verify his right to use the system. In some hosts, this phase may be minimal or non-existent. 3. The admission phase occurs after the user has successfully completed the login dialog. It consists of switching his network typewriter connections from the logger to an entity
providing a command processor of some sort. In some hosts this switching may be totally conceptual; in others there may be a real internal switching between entities.The Connection Phase The issues involved in specifying a protocol for implementinglogin can be separatedintop two major parts: how to establish andmaintain the network connection between the typewriter and the logger,and how to conduct a dialog after the connection is made. The first partis called the Initial Connection Protocol by Harlem and Heafner in RFC80. It in turn consists of two subparts: how to establish a connectionand how and when to destroy it. We endorse the proposal for establishing a connection made inRFC 80, which we summarize briefly for convenience. It is a two-stepprocess utilizing the NCP control messages to effect a connectionbetween the logger and the console of a potential user. First, the usercauses the hosts NCP to send out a "request for connection" controlmessage destined for the serving hosts loggers contact socket. The twopurposes of this message are to indicate to the logger that this userwishes to initiate a login dialog and to communicate the identifiers ofthe and send socket he wishes to Operate for this purpose. The loggerrejects this request to free its contact socket. As the second step thelogger choses two sockets to connect to the user's sockets, anddispatches connection requests for these. If the user accepts theconnection within a reasonable period, the connection phase is over, andthe dialog phase can begin. If the user does not respond, the requestsare aborted and the logger abandons this login attempt. There is another part to an NCP: when and how to disconnect.There are two basic situations when a logger should disconnect. Thefirst situation may arise of the serving host's volition. The logger maydecide to abandon a login attempt or a logged-in user may decide to logout. The second situation may be due to the using host's volition ornetwork difficulties. This situation occurs when the serving hostreceives a "close connection" control message or one of the networkerror messages signifying that further transmission is impossible. Thismay happen for either the "read" or the "write" connection,Disconnecting involves both the deletion of the network connections andthe stoppage of any activity at the serving host related to that user.If the login is in progress, it should be abandoned. If the user isalready logged in, his process should be stopped, since he no longer hascontrol over what it is doing. This is not intended to restrict absentee(i.e. consoleless) jobs.The Dialog Phase The second major part other than getting connected is how toconduct the login dialog. This resolves itself into two parts: what to
say and in what form to say it. The login dialog generally consist of asequence of exchanges, a prompting by the logger followed by a userreply specifying a name, a project, or passWord. However, exactly whatinformation is desired in what sequence is idiosyncratic to each host.Rather than attempt to specify a standard sequence for this dialog, wehave taken the approach that each host may specify its own sequence, solong as it is expressible as an exchange of messages in a basictransmission format. A message is a set of information transmitted byone of the parties that is sufficient for the other party to reply.Byhost specification, either the logger or the user sends sends the firstmessage of the dialog. After that, messages are exchanged sequentiallyuntil the dialog is completed. In this context "message" has no relationto "IMP message". The other issue involved in the login dialog is the format fortransmitting a message. We propose that it be transmitted as a sequenceof ASCII characters (see Specificarions) in groupings calle transactionblocks. 1. Character Set, We feel that there should be a standard character set for logging-in. The alternative, requiring a using host to maintain different transformation between its set and of each serving host, is a burden that can only narrow the scope of interhost usage, The character set proposed, ASCII is widely used standard. Each host must define a transformation sufficient to transform an arbitrary character sequence in the host's code into ASCII and back again, without any ambiguity, The definition of ASCII sequences to express characters not contained in ASCII is appropriate. 2. Transaction Blocks. A message is transmitted as an arbitrary integral number of transaction blocks. A transaction block consists basically of a string of ASCII characters preceeded by a character count. (It also contains a code field. See below.) The count is included as an aid to efficiently assembling a message. Some systems do not scan each character as it is input from the console. Rather, such systems have hardware IO controllers that place input characters into a main memory buffer and interrupt the central processor only when it receives an "action" character (such as "newline"). This reduces the load on the central processor. Because such a hardware facility is not available for interpreting network messages this scheme is proposed as a substitute. It helps in two ways. First, a system need take no action until it receives all characters specified in the count. Second, it need not scan each character to find the end of the message. The message ends at the end of the of a transaction block.
Other Issues There are several other issues involved in the area of remotelogins which we feel should be raised, although most need notnecessarily have firm agreements reached for an intial protocal.1. "Echoplex". Echoplex is a mode of typewriter operation in which all typed material is directed by the computer. A key struck by a user does not print directly. Rather the code is sent to the computer, which "echoes" it back to be printed on the typewriter. To reduce complexity, there is to be no option for network echoplexing (for the login only). A using system having its typewriters operating in echoplex mode must generate a local echo to its typewriters. However, a serving system operating echoplexed should suppress the echo of the input during the login phase.2. Correction of Mistakes. During the login dialog the user may make a typing mistake. There is no mistake correction ecplicitly proposed here. If the message in error has not yet been transmitted, the user can utilize the input editing conventions of either the using or the serving host. In the first case, the message is corrected before transmission; in the second, it is corrected at the serving host. If the user has made an uncorrectlable mistake, he should abort the login and try again. To abort, he instructs the local (using) host to "close" one of the connections. The connections are disconnected as specified in the Initial Connection Protocol.3. "Waiting". It may happen that the user may get into a login dialog but for some reason does not complete it. The logger is left waiting for a response by the user. The logger should not wait indefinitely but after a reasonable interval (perhaps a minute) abort the login and "close" the connections according to the provisions of the Initial Connection Protocol.4. Socket Assignments. The Initial Connection Protocol does not specify the ownership of the sockets to be used by the logger in connecting to the user. (The use code field of the socket identifier determines ownership.) The sockets may belong to the logger or may have an arbitraryuser code not used by another process currently existing at the serving host. Under this initial scheme, it is not possible to implement administratively assigned user codes, because the logger must assign permanent sockets before the identity of the user is verified. A future connection protocol can avoid this problem by implementing a socket connection as a part of the admission phase. The logger would talk to the user over the logger's sockets. Following identification it would transfer the connections to the sockets belonging to the user.5. General Console Communications. A companion paper under preparation outlines a protocol for general console communcations between hosts. This paper will seek to adress most of the
problems associated with typewriter like communications. This includes discussion of full and half duplex, character escapes, action characters and other pertinent topics. Such a protocol might not be suitable for all terminals and host systems but would include solutions to problems for many. It is not intended as a monolithic standard, but rather as a recommendation for those sites who wish to implement a common protocol. The important point is that we feel quite a bit of actual network usage is required before all the problems are better understood. This is a prerequisite for devising a standard. SPECIFICATIONSInitial Connection Protocol - Connection Phase The following sequence is as presented in RFC80. It is restated here for completeness.1. To intiate contact , the using process requests a connection of his receive socket (US) to a socket (SERV) in the serving host. By convention, this socket has the 24-bit user number field set to zero. The 8-bit tag or AEN field is set to one indicating the socket gender to be that of a sending socket. There is no restriction on the choice of the socket US other than it be of of the proper gender; in this case a receive socket. As a result the using NCP sends: User -> Server 8 32 32 8 +-----+------------+------------+-----+ RTS US SERV P +-----+------------+------------+-----+ over the control link one, where P is the receive link assigned by the user's NCP.2. The serving host now has the option of accepting the request for connection or closing the the connection. a. If he sends a close it is understood by the user that the foreign host is unable to satisfy a request for service at this time. The serving host's NCP would send: Server -> User 8 32 32 +-----+-----------+------------+ CLS SERV US +-----+-----------+------------+ with the user's NCP sending the echoing close: User -> Server 8 32 32 +-----+-----------+------------+ CLS US SERV +-----+-----------+------------+ b. If the serving host is willing to provide service it will accept the connection and immediately close the connection. This results in the the serving host's NCP sending: Server -> User 8 32 32 +-----+-----------+------------+ STR SERV US +-----+-----------+------------+
8 32 32 +-----+-----------+------------+ CLS SERV US +-----+-----------+------------+ with the user's NCP sending the echoing close. It sends: User -> Server 8 32 32 +-----+-----------+------------+ CLS US SERV +-----+-----------+------------+ It should be mentioned that the echoing closes are required by the host-to-host protocol and not by the logger initial connection protocol.Character Set The character set used in conducting the login dialog isstandard ASCII as documented in "American National Standard Code forInformation Interchange", ANS X3, 4-1968, American National StandardInstitute, October, 1968. A logger at a serving host may demand any kindof input that can be expressed as a string of one or more ASCIIcharacters. It similarly, it may output any such string. All ASCII characters are legal, including the graphics andcontrol characters. However, it is proposed that the only standard wayof indicating the end of a console line be the line feed character(012). This is in accordance with an anticipated change to the ASCIIstandard. Currently the ASCII standard permits two methods of ending aline. One method defines a single character, line feed (012), asincorporating the combined functions of line space and carriage returnto the lefthand margin. The second method, implicitly permitted byASCII, uses the two character sequence line feed (012) and carriagereturn (015) to perform the same function. There is a proposal that the ASCII standard be changed toinclude a return to the left-hand margin in all vertical motioncharacters of at least one full space (line feed, vertical tab and newpage). This will disallow the dual character sequence to end a line. It is suggested that a character in a hostst character set nothaving any ASCII equivalnet be represented by the ASCII two charactersequence ESC (033) and one of the ASCII characters. Each host shouldpublish a list of the escape sequence it has defined.Transaction Block Format All textual messages exchanged between user and logger are toconsist of one or more "transaction blocks". Each transaction block is asequence of 8-bit elements in the following format: <code> <count> <char1> ... <charn><code> is an 8-bit element that is not interpreted in this protocol. In the proposed general console communications protocol, this field specifies communication modes or special characteristics of this transaction block. Here <code> is to be zero.
<count> is an 8-bit element that specifies the number of character elements that follow in this transaction block. It is interpreted as a binary integer which has a permissible range between 0 and 127. The most significant bit is zero.<chari> is an 8-bit element containing a standard 7-bit ASCII character right-adjusted. The most significant bit is zero. The number of <chari> in the transaction block is governed by the <count> field. A maximum of 127 and minimum of zero characters are permitted in a single transaction block. The most significant bit of each of these elements is zero,effectively limiting each of these elements to seven bits ofsignificance. The reason for doing this is twofold: the eighth bit ofthe <chari> elements is specifically reserved for future expansion, andit was desired to limit all the elements so as to permit certainimplementations to convert the incoming stream from 8-bit elements to7-bit elements prior to decoding. With one exception, there is to be no semantic connotationattached with the division of a logger-user message into one or moretransaction blocks. The character string comprising the message to betransmitted may be divided and apportioned among multiple transactionblocks according to the whim of the sending host. If less than 128characters in length, the message may be sent as a single transactionblock. The exception is that separate messages may not appear in thesame transaction block. That is, a message must start at the beginningof a transaction block and finish at the end of one. Note also thatthere is no syntactic device for specifying the last transaction blockof a message. It is presumed that the logger end user both havesufficient knowledge of the format to know when all of a message hasarrived Note that the first 8-bits of data transmitted through a newlyestablished connection must be a type code as specified in ProtocolDocument 1. This type code must be sent prior to the first transactionblock and should be discarded by the receiving host.Acknowledgments Robert Bressler, Allen Brown, Robert Metcalfe, and MichaelPadlipsky contributed directly to the establishment of the ideaspresented here. Thanks are due Michael Padlipsky and others foreditorial comments. [ This RFCwas put into machine readable form for entry ] [ into the online RFCarchives by Carl Moberg 1/98 ]
新闻热点
疑难解答
