Copyright Xerox Corporation 1979Inter-Office MemorandumToCommunication ProtocolsDateJuly 2, 1978FromEd TaftLocationPalo AltoSubjectState Machine forOrganizationPARC/CSLRendezvous/Termination ProtocolXEROX Filed on: [Maxc1]RTPStates.pressThis is a revision of Pup Connection State Diagram, dated October 4, 1975. Only minor changeshave been made.The attached diagram purports to illustrate Tenex's management of Pup connections according tothe Rendezvous/Termination Protocol. While some aspects of this diagram are peculiar to theTenex implementation, we are presenting it as a model for implementation of the protocol on othermachines. Familiarity with Pup Specifications is assumed, and Implementation of Pup in Tenexmight be of some help.Pup connections are controlled by a Finite State Machine (FSM) consisting of states, events, actions,and transitions. At any given moment, a port is in some state, indicated by one of the labelledcircles. Leading out of each state are one or more arcs, each labelled with one or more events and(optionally) an action. For example, extending down and to the right from the Closed state is an arcleading to the RFC Out state and labelled "OPENFC, Send RFC". This means that if the port is inthe Closed state and event OPENFC occurs, the action Send RFC is performed and the port's state ischanged to RFC Out.If an event occurs and no path out of the current state is labelled with that event, we assume that aprotocol violation or similar error has occurred. Such events give rise to no action and cause thestate to loop back to itself.Before going into detail, we should note that Tenex implements only a special case of theRendezvous Protocol, namely that in which the local Rendezvous Port and Connection Port are thesame. This topic is elaborated upon in the memo Implementation of Pup in Tenex.EventsThere are three classes of events that potentially cause changes to a port's state. Events may beinitiated by operations performed on the port by the local process (OPENF, CLOSF), by receipt ofa Rendezvous/Termination Protocol Pup from the appropriate foreign port, or by a timeout. Theseevents will now be described in some detail.OPENF is the name of the Tenex JSYS used to open a file. In the case of an OPENF applied todevice PUP:, the OPENF may be executed in one of three modes, corresponding to the eventsOPENFC, OPENFL, and OPENFN.The OPENFC operation is used when the local process desires to actively initiate a connection with &pX]g~qi cr]pX-r7Bp \r]p-r7Bp Vr]p-r 7Bp]TOsp I% Ctp$ BD ?_J =+1 /d >State Machine for Rendezvous/Termination Protocol2a specific foreign port, while the OPENFL operation puts the port in a passive, Listening state forthe purpose of accepting incoming requests from other ports. Note that a successful rendezvousrequires that one party "listen" while the other "connects".The OPENFN operation is a means by which a BSP port may be placed immediately in the Openstate without Tenex performing a rendezvous. Obviously, it is assumed that the process has alreadyperformed a rendezvous by some other means. This is the mechanism by means of which servers mayimplement separate Rendezvous and Connection ports.CLOSFN is the normal means by which the local process requests that a connection be terminated,while CLOSFT requests an abnormal termination. In the Tenex implementation, either operationmay be initiated by the CLOSF JSYS, which generates a CLOSFN event normally but a CLOSFTevent if a timeout error has occurred (i.e. no activity has taken place for a long time despiterepeated probing of the foreign port).The events RFC rec'd, End rec'd, End Reply rec'd, and Abort rec'd are triggered by receipt of Pupsof those respective types. An incoming Pup of any of the latter three types must (a) have aDestination Port exactly matching the local port, (b) have a Source Port exactly matching the foreignport to which the connection has been established, and (c) have a Pup ID equal to the ConnectionID (established by the initiating RFC). If these conditions do not hold, the Pup is discardedwithout generating an event. In the case of an RFC, the conditions checked depend on the currentstate, and the action performed depends on parameters obtained from the incoming RFC. This willbe described later on.Whenever a port enters a state (even if it is the state it was in before), a timer is initialized to afairly short interval (on the order of a second unless the state being entered is Dally, in which casethe interval should be somewhat longer, say 5 to 10 seconds). If this interval elapses, a Timeoutevent is generated. The Timeout event may cause Pups to be retransmitted (RFC Out, End Out),and is also used to force termination of the Dally state. In other states, the Timeout event isignored. The timer used to generate this event is different from the one used to detect long-terminactivity. That one is typically on the order of several minutes; its expiration does not itselfgenerate an event but rather signals an error to the process, which may then choose to perform aCLOSFT to abort the connection.ActionsThe actions Send RFC1, Send RFC2, and Send RFC3 all cause an RFC Pup to be transmitted;however, the RFC's parameters are set up in a different manner for the three cases, and there aresome differing auxiliary actions performed as well.The action Send RFC1 is performed when the local port is taking the initiative in establishing theconnection. In this case, the RFC's Source Port and Connection Port fields are set to the local portaddress; the Destination Port is set to the desired foreign Rendezvous Port, and the Pup ID (i.e.the Connection ID) is chosen locally by some suitable means (e.g. reading a real-time clock). Notethat the same Pup ID should be used for any retransmission of the RFC as was used for the initial RFC.Send RFC2 is the action performed when the local port is in the Listening state and an RFC isreceived which passes through whatever address filtering has been specified (generally it iscompletely wildcard). In this case, the Connection ID and foreign Connection Port are gotten fromthe incoming RFC. The answering RFC is then generated by exchanging the Pup Source andDestination and supplying the local port address as the Connection Port.Send RFC3 is the action performed when an RFC is received while the state is Open or End Out(meaning that we believe the connection has been fully established but the foreign process has notyet seen our answering RFC). In this case, the incoming RFC is accepted only if all the followingconditions hold: (a) the port was previously in the Listening state; (b) the Connection Port isexactly the same as the foreign Connection Port previously remembered (in action Send RFC2); and gp1Gf b#taubp'tp `TT ^< [t[]u[p0t Z p-6 X+r1 W:3 TytSuTypM RtR"uRp< P6tPXuPptPXu OpX M& J tptptpt p I,5' GP F"U D(6 CD A V @ =)R ;6tp :3(t 8ptptptp 7-tptp 5/3 4 21 2` 1t0tu1p ,v )p t)&u)pt)&u)pt)&u)p  '-4 &d3 # t"u#pN !D! 0b Lr J+; tup6tp  & 6 :3/ 9 0H KtuKpDtpt p6, P wtp" Pt eu p B?/]State Machine for Rendezvous/Termination Protocol3(c) the Connection ID is the same as the ID already established for the connection. If theseconditions are satisfied, the answering RFC is generated as in the action Send RFC2. Requirement (a)is important, since if we were to reply to an RFC after having been the initiator of a connection, receipt of a delayedduplicate RFC could result in both parties bouncing the RFC back and forth between them indefinitely. This memory of"having been listening" should really be represented by other states in the FSM (duplicates of Open and End Out), butwe have not done so in the interest of avoiding excessive clutter.The action Open Connection is performed only for a port in the RFC Out state when an answeringRFC is received. The RFC should not be accepted unless the Source and Destination Port fields(reversed) and the Pup ID match the corresponding fields of the RFC we sent previously (by actionSend RFC1). The only operation performed by this action is to remember the foreign ConnectionPort contained in the incoming RFC.The actions Send End, Send End Reply and Send Abort are self-explanatory. Each of these isconstructed using the local and foreign Connection Ports and the Connection ID for the SourcePort, Destination Port, and Pup ID, respectively.MiscellaneousThe FSM just described deals only with the Rendezvous/Termination Protocol and not with theactual transfer of data by means of the Byte Stream Protocol (or, possibly, some alternativeprotocol). However, this protocol interacts with BSP in two important ways.First, BSP operations should be performed only when the connection state is Open, End In, or EndOut. Furthermore, the local process should not be permitted to generate more output when thestate is End Out, and should be given an end-of-file indication upon exhausting the input streamand finding the state to be End In. Incoming Acknowledgments should be ignored and no Datas orADatas should be transmitted (or even retransmitted) when the state is End Out, and incoming Datasand ADatas should be ignored and no Acknowledgments transmitted when End In.Second, the CLOSFN event must not be generated until all outgoing data has been successfullytransmitted and acknowledged. This ensures clean termination of the outgoing byte stream beforesending either an End or an End Reply, as required by the protocol.The Abort state is included in the FSM purely as a means by which the local process may discoverthat the connection has been aborted by the foreign process. In most other respects, this state isequivalent to Closed, and the transition from Abort to Closed generates no action.SummaryThe following table enumerates all states, events, and actions in the FSM.StatesEventsActionsClosedOPENFCSend RFC1ListeningOPENFLSend RFC2RFC OutOPENFNSend RFC3OpenCLOSFNOpen ConnectionEnd InCLOSFTSend EndEnd OutRFC rec'dSend End ReplyDallyEnd rec'dSend AbortAbortEnd Reply rec'dAbort rec'dTimeout fp1G bC `Bt` u`pr ^!V ][ \x[urur [;B Xzp tp%tp V;# UpV StS^uSpS R!# O< tptpt p( M8% L21 Gv DpR C;J AL >3tptpt =LpE ;tpA :Btp1 8&t p tp 78Etp 4S3r4Sp; 2#= 1C .tp$3 ,K + tptptp &v #pJ t#6@p#Lr6@pLrp#r6@prEp#r6@Epr{p#r6@{p#$r6@p#6@ b#6@##X # >/Y~rrrrrrrrrrrrrrqqqr><rTimeoutSend EndRFC rec'dSend RFC3Abortrec'dSend EndReplySend EndReplyCLOSFNSend EndReplyCLOSFTSendAbortAbortrec'dEndReply rec'd orTimeout or CLOSFTEnd rec'dSend EndReplyrec'dAbortCLOSF<rqSendAbortq<3Send RFCRFC rec'dRendezvous/Termination State DiagramRTPStates.silEnd rec'drEnd rec'd!V^Gr!V^uG*:^uG!Vb +G SX +GNG NG O-Gr7O-Gr7NG@tNG7SX +G!VC +G*:?WG!V?WG!V?Gr 0Gr /G/G 4; +G74; +G@t/G7/G70Gr!V Gr!V :G*: :G!V$ +G!V +G*:G!VG!VGr#X$W$(X$(W$%D$(8$(8$94$r)e$)A$#$$r($$r#c $]9eC!z$9$V9!V$#$]9QC $H$H_$9H$(H_$(D$r%d$ 9$:($(d$r@tQC$GQ$(eCA$(c.$9@t2%$G2%$92% $()A$ <+$r<+z9$9"A$$:$#d$r>;H$>;H_ V$K$.9$*:A!V$A$4$ V%;-$r#; ]$#; $<S|$<W9$>;S$r*:"9$,sH$r(%$(%$]9|K9;K=K#I 2Bf Bf +W:/t9+Wp7I<<A6,Ett5>;4^$>;9$F|1>;+z@$=#?W+$r>;+$r?p.e?,?) ?(HFt':Wp":W!+0 <;- )st)p' r2t2lrp0r. )e 'V#HV!t -p! -e !!VHH|t4K4X0 M ]!tFMBp4B2F|6<=]!%:t7lp79 (2%$z$t S$r9S$r#D$r+p2 V4^$ V89$4$r|, rp9 Kd TIMESROMAN  TIMESROMAN  TIMESROMANLOGO TIMESROMAN  TIMESROMAN TIMESROMAN  HELVETICA  HELVETICA  HELVETICA  TEMPLATE@ !b )QiQiP "=M##=I#B"*iG "*iA !OiO%1)Mi19KZ%+*iH%')Fi'9AZ%!*i>%)*%T9T9R =  %)ii9Z%-i%)ii@EmY Z  %+9+9)   Z  TWZ :Z"*i?B"Pj/#!$iRTPStates.pressTaftP 3-Sep-79 18:33:29 PDT!