📄 rfc426.txt
字号:
RFC 426 Reconnection Protocol January 1973 ___ ___ | P |---------------| Q | |___| |___| ____________________ | P --> Q || R R Q | |_________||_________| | +---------+ | ____V_______________________________________ | || | | | | Q --> P || R O K | R N O ----| R R Q | | || | | E | | |_________||_________|_________|___|_________| | | +------------+ v | Yes +----------+ No | +------------------------| NP > NQ? |------+ | | +----------+ | __v___v_______________________________ | | || | | | | P --> Q || R D O ----| R N O ----| | | || | E | | E | | |_________||_________|___|_________|___| | | +--------------------------------------------+ | ____v_________________________________ | || | | | Q --> P || R D O ----| R N O ----| | || | E | | E | |_________||_________|___|_________|___| NP and NQ are the 40 bit numbers for P and Q; E indicates end of sequence.3. Adding the Reconnection Mechanism to Host-Host Protocol The four reconnect commands could be included directly in Host-Host protocol as follows: RRQ <my socket> <your socket> ROK <my socket> <your socket> RNO <my socket> <your socket> RDO <my socket> <your socket> <new host> <new socket> The ROK and RDO commands for a send connection should not be sent until there are no messages in transit over the connection. The RDOThomas [Page 7] RFC 426 Reconnection Protocol January 1973 command is to be interpreted as a CLS. The reconnection: H2 H3 H2 H3 ___ ___ ___ ___ | | | | | C|--------|D | |_C_| |_D_| |___| |___| | | | | ===> | ____ | ____ ---|A B|--- | | |____| |____| H1 H1 could be accomplished as follows: H1->H2: RRQ A C H1->H3: RRQ B D H2->H1: ROK C A H3->H1: ROK D B H1->H2: RDO A C H3 D H1->H3: RDO B D H2 C H2->H1: CLS C A H3->H1: CLS D B H2->H3: STR C D size H3->H2: RTS D C link Note that it is possible for the STR from H2 to arrive at H3 before the RDO from H1. H3 must be prepared to queue such an RFC until it gets an RDO or RNO from H1. Stated differently, transmission of an ROK for a local socket causes the socket to move from an "open" state to a "reconnect pending" state and indicates willingness to queue subsequent RFC's until receipt of a "matching" RDO or RNO.4. Reconnection in TELNET Protocol Independently of whether Host-Host protocol directly supports reconnection, the reconnection mechanism could be included in TELNET with the addition to the TELNET protocol of the five commands: RRQ ROK RNO RDO <host> <socket> RWT <host> <socket>Thomas [Page 8] RFC 426 Reconnection Protocol January 1973 where RRQ, ROK, RNO, RDO, and RWT are appropriately chosen characters in the range 128 to 255. The first three commands require no parameters since they refer to the connections they are received on. For RDO and RWT, <host> is an 8 bit (= 1 TELNET character) host address and <socket> is a 32 bit (= 4 TELNET characters) number that specifies a TELNET receive socket at the specified host. A pending reconnection can be activated with either RDO or RWT. The response to either is to first break the TELNET connection with the sender and then reopen the TELNET connection to the host and sockets specified. For RDO, the connection is to be reopened by sending two RFC's; for RWT, by waiting for two RFC's. The RWT command is introduced to avoid races such as the one between the STR and CLS (RDO) discussed above. In Host-Host protocol the race is avoided by putting a connection into "reconnect pending" state upon transmission of ROK. For TELNET the race can be avoided by the initiator of the reconnection by judicious use of RWT and RDO. For example the reconnection: H2 H3 H2 H3 +---+ +---+ +---+ M +---+ | |----+ +---->| | | |------->| | | Y | N | | Q | Z | ==> | Y | N | Z | | |<-+ | H1 | +---| | | |<-------| | +---+ | | M +---+ P | | +---+ +---+ +---+ | +--->| |----+ | | | X | | H1 +------| |<-----+ +---+ +---+ | | H1 | X | | | +---+ could be accomplished as follows: X->Y: RRQ X->Z: RRQ Y->X: ROK Z->X: ROK X->Y: RWT H3 P X closes connections to Y Y closes connections to X Y waits for STR and RTS from H3 X->Z: RDO H2 N X closes connections to Z Z closes connections to X Z sends STR and RTS to H2 which Y answers with matching RTS and STR to complete reconnectionThomas [Page 9] RFC 426 Reconnection Protocol January 1973 The reconnection mechanism for TELNET can be made to fit nicely into the command format suggested by Cosell and Walden in RFC #435. Consider the addition of three new commands to TELNET: Prepare for Reconnect: RCP Begin Reconnect by sending RFC's: RCS Begin Reconnect by waiting for RFC's: RCW Using these three command and the DO, DON'T, WILL, WON'T commands of RFC #435, the commands proposed earlier become: RRQ => DO RCP ROK => WILL RCP RNO => WON'T RCP ;for responses to DO RCP DON'T RCP ;for responses to WILL RCP ;i.e. used to cancel an RCP. RDO <host> <socket> => DO RCS <host> <socket> RWT <host> <socket> => DO RCW <host> <socket> As RFC #435 notes the nice thing about this structure is that a host choosing not to implement reconnection does not even have to know what RCP means. All that it need do in response to DO RCP is to transmit WON'T RCP.5. Recommendation I feel that reconnection is a basic notion and that its proper place within the protocol hierarchy is at the Host-Host level where it would be available for use in all higher level protocols. The difficulty is that placing it there would, of course, require NCP rewrites. Reluctance to make NCP modifications would probably be sufficient to kill interest in the proposal. Therefore, for pragmatic reasons, I recommend that the reconnection mechanism be included in TELNET as an "option" in the spirit of RFC #435. This can be accomplished with the addition to the TELNET protocol of the RCP, RCS, RCW commands as described in Section 4. Modification of user- and server-TELNET programs to handle these new commands should be straightforward. If a reconnection option is made part of TELNET protocol the TENEX hosts will support it. In addition, the TIP guys (Walden and Cosell) have said that they like the reconnection mechanism and have agreed, in principle, to implement it for TIPs if it is accepted as part of TELNET protocol.Thomas [Page 10] RFC 426 Reconnection Protocol January 1973 Addition of reconnection at the TELNET level rather than the Host- Host level is admittedly a compromise. However, with it, activity of the sort described in Examples A and B of Section 1 will be possible.6. Additional RemarksA. Reconnection is not a new notion. An early proposal for Host-Host protocol (RFC #36) included facilities to support reconnection. The reconnection mechanism in RFC #36 supposes a configuration in which entities are "daisy-chained" together by connections: __ __ __ __ __ ___| |____| |____| |____| |____| |___ |__| |__| |__| |__| |__| and specifies how one or more entities can break out of the chain. As suggested above (Figure 5) the mechanism proposed in this note supports that kind of reconnection.B. In practice one would expect simultaneous initiation of reconnects by adjacent entities to be relatively rare.C. The approach taken in RFC #36 to handle simultaneous reconnection attempts by entities adjacent in the chain is to accomplish the reconnect as a single, carefully coordinated, global reconnect. I feel that the sequence of locally coordinated reconnects as proposed above is preferable. When N adjacent entities simultaneously attempt reconnection the single, globally coordinated reconnect as outlined in RFC #36 requires ~N^2 control messages whereas the sequential locally coordinated reconnect requires ~N.D. A word about security is in order. It should be clear that the decision to accept or reject a particular reconnection request is the responsibility of the entity (person at a terminal or process) using the connection. In many cases the entity may choose to delegate that responsibility to its NCP or TELNET (e.g., Example A, Section 1). However, the interface a Host provides to the reconnection mechanism should include means for local entities to exercise control over response to remotely initiated reconnection requests. For example, a user-TELNET might support several modes of operation with respect to remotely initiated reconnections: 1. transparent: all requested reconnections are to be performed in a way that is invisible to the user; 2. visible: all requested reconnections are to be performed and the user is to be informed whenever a reconnection occurs;Thomas [Page 11] RFC 426 Reconnection Protocol January 1973 3. confirmation: the user is to be informed of each reconnection request which he may accept or reject; 4. rejection: all requested reconnects are to be rejected.E. Reconnection can be achieved almost trivially within the Message Switched Protocol (MSP) proposed by Bressler, Murphy and Walden in RFC #333 (within MSP, "reconnection" is probably not the correct term). For example use of the following conventions with that MSP (expressed in the terminology of RFC #333) support reconnection: 1. unless a reconnection is in progress, rendezvous is to occur at the sending site; 2. the receiving end of a communication path can be moved by passing the names of the rendezvous site and the ports to the new receiver; 3. receipt of an OUT message for which the source site differs from the rendezvous site signals that the sending end is being moved; the source site should be used as the rendezvous site for subsequent IN messages; 4. the sending end of a communication path can be moved by passing the names of the ports to the new sender; to complete the move the new sender uses the previous sender's site as rendezvous site for its first OUT message and its own site as rendezvous for subsequent OUT messages. As simple and appealing as this procedure seems, I doubt that it would be used in practice if MSP were to be implemented as a replacement for or alternative to existing Host-Host protocol. The reason is that the ability to pass ports from Host to Host (needlessly) complicates port name allocation by requiring cooperation among Hosts to manage the allocation (e.g., before a Host can safely allocate a port name for use by a local process it must not only insure that the port is not in use locally but also that no process out in the network is using it.) The inter-Host cooperation required to support the passage of ports among Hosts can probably not be reliably achieved in practice. Therefore port passage of the sort described in RFC #333 should not be supported at the Host-Host protocol level. For this reason, I feel that within an MSP "reconnection" would be best handled by a mechanism such as the one proposed in this note. [ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Anthony Anderberg 4/99 ]Thomas [Page 12] ⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -