📄 rfc983.txt
字号:
Cass & Rose [Page 7] RFC 983 April 1986ISO Transport Services on Top of the TCP5. The Protocol It is the goal of this memo to offer a TP interface on top of the TCP. Fortunately, the TCP does just about everything that TS-provider offers to the TS-user, so the hard parts of the transport layer (e.g., three-way handshakes, choice of ISS, windowing, multiplexing, ad infinitum) are all taken care of by the TCP. Despite the symmetry of TP, it is useful to consider the protocol with the perspective of a client/server model. The information exchanged between TSAP-peers is in the form of packets termed "TPKT"s. The format of these packets is described in the next section. For the purposes of the description below, a TPKT has a code which is one of: CR - request connection CC - confirm connection DR - request disconnection DT - data ED - expedited data A TSAP server begins by LISTENing on TCP port 102. When a TSAP client successfully connects to this port, the protocol begins. A client decides to connect to the port when a TS-user issues a T-CONNECT.REQUEST action. This action specifies the TSAP ID of the remote TS-user, whether expedited data is to be supported, and (optionally) some initial TS-user data. The client consults the TSAP ID given to ascertain the IP address of the server. If the expedited data option was requested, the client opens a passive TCP port, in non-blocking mode, noting the port number. This TCP port is termed the "expedited port". The client then tries to open a TCP connection to the server on port 102. If not successful, the client fires T-DISCONNECT.INDICATION for the TS-user specifying the reason for failure (and, closes the expedited port, if any). If successful, the client sends a TPKT with code CR containing: - the TSAP ID of the TS-user on the client's host (the "caller") - the TSAP ID of the TS-user that the client wants to talk to (the "called") - if the expedited data option was requested, the TSAP ID of the expedited port for the client's host - any TS-user data from the T-CONNECT.REQUEST The client now awaits a response.Cass & Rose [Page 8] RFC 983 April 1986ISO Transport Services on Top of the TCP The server, upon receipt of the TPKT, validates the contents of the TPKT (checking the version number, verifying that the code is CR, and so forth). If the packet is invalid, the server sends a TPKT with code DR specifying "PROTOCOL ERROR", closes the TCP connection, and goes back to the LISTEN state. If the packet is valid, the server examines the TSAP ID that the remote TS-user wants to communicate with. If the TS-user specified can be located and started (e.g., the appropriate program which implements the indicated protocol is present), then the server starts this TS-user by firing T-CONNECT.INDICATION. Otherwise, the server sends a TPKT with code DR specifying "SESSION ENTITY NOT ATTACHED TO TSAP" or "REMOTE TRANSPORT ENTITY CONGESTED AT CONNECT REQUEST TIME" as appropriate, closes the TCP connection, and goes back to the LISTEN state. The server now waits for a T-CONNECT.RESPONSE or T-DISCONNECT.REQUEST from the TS-user it started. if the latter is given, the server sends a TPKT with code DR containing the reason for the disconnect as supplied by the TS-user. The server then closes the TCP connection and goes back to the LISTEN state. Instead, if T-CONNECT.RESPONSE is given, the server sees if an expedited port was specified in the connection request. If so, the server opens a second TCP connection and connects to the specified port. If the connection fails, the server sends a TPKT with code DR specifying "CONNECTION NEGOTIATION FAILED", closes the TCP connection, and goes back to the LISTEN state. If the connection succeeded, the server notes the local port number used to connect to the expedited port. If an expedited port was not specified in the TPKT with code CR, and the server's TS-user indicates that it wants to use expedited data, then the server sends a TPKT with code DR specifying "CONNECTION NEGOTIATION FAILED", fires T-DISCONNECT.INDICATION with this error to the TS-user, closes the TCP connection, and goes back to the LISTEN state. The server now sends a TPKT with code CC containing: - the TSAP ID of the TS-user responding to the connection (usually the "called") - if an expedited port was specified in the TPKT with code CR,Cass & Rose [Page 9] RFC 983 April 1986ISO Transport Services on Top of the TCP the TSAP ID of the port number on the server's host that was used to connect to the expedited port - any TS-user data from the T-CONNECT.RESPONSE After sending the TPKT, the server enters the SYMMETRIC PEER state. The client, upon receipt of the TPKT, validates the contents of the TPKT (checking the version number, verifying that the code is CC or DR, and so forth). If the packet is invalid, the client sends a TPKT with code DR specifying "PROTOCOL ERROR", fires T-DISCONNECT.INDICATION with this error to the TS-user, and closes the TCP connection (and the expedited port, if any). If the packet's code is DR, the client fires T-DISCONNECT.INDICATION with the reason given in the TPKT to the TS-user, and closes the TCP connection (and the expedited port, if any). If the packet's code is CC, the client checks if an expedited port was specified and that a connection is waiting on the expedited port. If not, a protocol error has occurred, a TPKT with code DR is returned, T-DISCONNECT.INDICATION is fired, and so on. Otherwise, the client checks the remote address that connected to the expedited port. If it differs from the port listed in the TPKT with code CC, a protocol error has occurred. Otherwise, all is well, two TCP connections have been established, one for all TPKTs except expedited data, and the second for the exclusive use of expedited data. The client now fires T-CONNECT.CONFIRMATION, and enters the SYMMETRIC PEER state. Once both sides have reached the SYMMETRIC PEER state, the protocol is completely symmetric, the notion of client/server is lost. Both TS-peers act in the following fashion: If the TCP indicates that data can be read, the TS-peer, upon receipt of the TPKT, validates the contents. If the packet is invalid, the TS-peer sends a TPKT with code DR specifying "PROTOCOL ERROR", fires T-DISCONNECT.INDICATION with this error to the TS-user, and closes the TCP connection (and expedited data connection, if any). If the TS-peer was the server, it goes back to the LISTEN state. NOTE: If the expedited data option was requested, then there are two TCP connections that can supply data for reading. The dialogue below assumes that only ED TPKTs are read from the expedited data connection. For simplicity's sake, when reading from TCP the relation between connections and TPKTs is unimportant and this memo URGES all implementations to be very lenient in thisCass & Rose [Page 10] RFC 983 April 1986ISO Transport Services on Top of the TCP regard. When writing to TCP, implementations should use the expedited data connection only to send TPKTs with code ED. Section 7 of this memo discusses the handling of expedited data in greater detail. If the packet's code is DR, the TS-peer fires T-DISCONNECT.INDICATION with the reason given in the TPKT to the TS-user, and closes the TCP connection (and expedited data connection, if any). If the TS-peer was the server, it goes back to the LISTEN state. If the packet's code is ED or DT, the TS-peer fires T-DATA.INDICATION or T-EXPEDITED DATA.INDICATION as appropriate with the enclosed user data for the TS-user. It then goes back to the SYMMETRIC PEER state. If the packet is invalid, the TS-peer sends a TPKT with code DR specifying "PROTOCOL ERROR", fires T-DISCONNECT.INDICATION with this error to the TS-user, and closes the TCP connection (and expedited data connection, if any). If the TS-peer was the server, it goes back to the LISTEN state. If the TCP indicates that an error has occurred and the connection has closed, then the TS-peer fires T-DISCONNECT.INDICATION to the TS-user specifying the reason for the failure. If the expedited data connection, if any, is still open, it is closed. If the TS-peer was the server, it goes back to the LISTEN state. If the TS-user issues a T-DATA.REQUEST or T-EXPEDITED DATA.REQUEST action, the TS-peer sends a TPKT with code DT or ED containing the TS-user data. It then goes back to the SYMMETRIC PEER state. If the TS-user issues a T-DISCONNECT.REQUEST action, the TS-peer sends a TPKT with code DR containing the reason for the disconnect as supplied by the TS-user. The TS-peer then closes the TCP connection, (and expedited data connection, if any). If the TS-peer was the server, it goes back to the LISTEN state. In terms of (augmented) state tables, the protocol can be explained as follows. The server starts in state S0, the client starts in state C0. "TCP:" refers to an event or action from the TCP service, "SS:" refers to an event or action from the TS-user (e.g., the ISO session service [ISO-8327]).Cass & Rose [Page 11] RFC 983 April 1986ISO Transport Services on Top of the TCP S E R V E R S T A T E S state event action goto ----- ----- ------ ---- S0 TCP: listen on port 102 S1 S1 TCP: connected TCP: read TPKT parse, on error TCP: send DR, close S0 code is CR start session server SS: T-CONNECT S2 .INDICATION otherwise, TCP: send DR, close S0 S2 SS: T-CONNECT.RESPONSE if expedited option, TCP: open port EXPD TCP: send CC P0 S2 SS: T-DISCONNECT TCP: send DR, close S0 .REQUEST Any event occuring for a state not listed above is considered an error, and handled thusly: state event action goto ----- ----- ------ ---- S* TCP: other if TCP is open, TCP: close S0 otherwise ignore S0 S* SS: other SS: T-DISCONNECT .INDICATION if TCP is open, close S0Cass & Rose [Page 12] RFC 983 April 1986ISO Transport Services on Top of the TCP C L I E N T S T A T E S state event action goto ----- ----- ------ ---- C0 SS: T-CONNECT.REQUEST if expedited option, TCP: non-blocking listen on port EXPD TCP: open port 102 C1 C1 TCP: connected TCP: send CR C2 C1 TCP: connect fails TCP: close SS: T-DISCONNECT C0 .INDICATION C2 TCP: data ready TCP: read TPKT parse, on error TCP: send DR, close SS: T-DISCONNECT C0 .INDICATION code is CC if expedited option, verify port EXPD connected correctly, if not, treat as error SS: T-CONNECT P0 .CONFIRMATION code is DR TCP: close SS: T-DISCONNECT C0 .INDICATION otherwise TCP: send DR, close SS: T-DISCONNECT C0 .INDICATIONCass & Rose [Page 13] RFC 983 April 1986ISO Transport Services on Top of the TCP Any event occuring for a state not listed above is considered an error, and handled thusly: state event action goto ----- ----- ------ ---- C* TCP: other if TCP is open, close C0 otherwise ignore C0 C* SS: other SS: T-DISCONNECT .INDICATION if TCP is open, close C0⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -