📄 rfc2204.txt
字号:
ODETTE-FTP peer entities communicate with each other via the OSI Network Service or the Transmission Control Protocol Transport Service [TCP]. This is described by service primitives representing request, indication, response and confirmation actions. For the internet environment, the service primitives mentioned below for the Network Service have to be mapped to the respective Transport Service primitives. This section describes the network service primitives used by ODETTE-FTP and their relationship to the TCP interface. In practice the local transport service application programming interface will be used to access the TCP service.2.2 Service Primitives All Network primitives can be directly mapped to the respective Transport primitives when using TCP.Nash Informational [Page 7] RFC 2204 ODETTE File Transfer Protocol September 19972.2.1 Network Connection N_CON_RQ ------> N_CON_IND N_CON_CF <------ N_CON_RS This describes the setup of a connection. The requesting ODETTE-FTP peer uses the N_CON_RQ primitive to request an active OPEN of a connection to a peer ODETTE-FTP, the Responder, which has previously requested a passive OPEN. The Responder is notified of the incoming connection via N_CON_IND and accepts it with N_CON_RS. The requester is notified of the completion of it's OPEN request upon receipt of _CON_CF. Parameters Request Indication Response Confirmation --------------------------------------------------------------------- Dest addr ------> same same same2.2.2 Network Data N_DATA_RQ ------> N_DATA_IND Data exchange is an unconfirmed service. The Requester passes data for transmission to the network service via the N_DATA_RQ primitive. The Responder is notified of the availability of data via N_DATA_IND. In practice the notification and receipt of data may be combined, such as by the return from a blocking read from the network socket. Parameters Request Indication --------------------------------------------------------------------- Data ------------------> same2.2.3 Network Disconnection N_DISC_RQ ------> N_DISC_IND An ODETTE-FTP requests the termination of a connection with the N_DISC_RQ service primitive. It's peer is notified of the CLOSE by a N_DISC_IND event. It is recognised that each peer must issue a N_DISC_RQ primitive to complete the TCP symmetric close procedure.Nash Informational [Page 8] RFC 2204 ODETTE File Transfer Protocol September 19972.2.4 Network Reset ------> N_RST_IND An ODETTE-FTP entity is notified of a network error by a N_RST_IND event. It should be noted that N_RST_IND would also be generated by a peer RESETTING the connection, but this is ignored here as N_RST_RQ is never sent to the Network Service by ODETTE-FTP.2.3 Port Assignment A ODETTE-FTP requester will select a suitable local port. The responding ODETTE-FTP will listen for connections on Registered Port 3305, the service name is 'odette-ftp'.3. File Transfer Service The File Transfer Service describes the services offered by an ODETTE-FTP Entity to it's User Monitor. The implementation of the service primitives is a local matter.Nash Informational [Page 9] RFC 2204 ODETTE File Transfer Protocol September 19973.1 Model o-------------------o o-------------------o | | | | | USER MONITOR | | USER MONITOR | | | | | o-------------------o o-------------------o | A | A ...............|...|... FILE TRANSFER SERVICE ...|...|............... | | | | F_XXX_RQ/RS | | F_XXX_IND/CF F_XXX_RQ/RS | | F_XXX_IND/CF V | V | o-------------------o o-------------------o | |- - - - - - >| | | ODETTE-FTP Entity | E-Buffer | ODETTE-FTP Entity | | |< - - - - - -| | o-------------------o o-------------------o | A | A N_XXX_RQ/RS | | N_XXX_IND/CF N_XXX_RQ/RS | | N_XXX_IND/CF | | | | ...............|...|...... NETWORK SERVICE ......|...|............... V | V | o---------------------------------------------------------o | | | N E T W O R K | | | o---------------------------------------------------------o Key: E-Buffer - Exchange Buffer F_ - File Transfer Service Primitive N_ - Network Service PrimitiveNash Informational [Page 10] RFC 2204 ODETTE File Transfer Protocol September 19973.2 Session Setup3.2.1 Session Connection Service | | F_CONNECT_RQ ---->|------------|----> F_CONNECT_IND | | F_CONNECT_CF <----|------------|<---- F_CONNECT_RS | | Parameters Request Indication Response Confirm --------------------------------------------------------------------- called-address -> same --- ---- calling-address-> same --- ---- ID1 ------------> same ID2 ------------> same PSW1------------> same PSW2 -----------> same mode1 ----------> mode2 ----------> mode3 ----------> same restart1 -------> same -----------> restart2 -------> same --------------------------------------------------------------------- Mode Specifies the file transfer capabilities of the entity sending or receiving a F_CONNECT primitive for the duration of the session. Value: Sender-Only The entity can only send files. Receiver-Only The entity can only receive files. Both The entity can both send and receive files. Negotiation: Sender-Only Not negotiable. Receiver-Only Not negotiable. Both Can be negotiated down to Sender-Only or Receiver-Only by the User Monitor or the ODETTE-FTP entity.Nash Informational [Page 11] RFC 2204 ODETTE File Transfer Protocol September 1997 Request Indication Response Confirm --------------------------------------------------------------------- Sender-only ----> Receiver-only --> Receiver-only --> Sender-only Receiver-only --> Sender-only ----> Sender-only ----> Receiver-only Both -----+-----> Both ----+------> Both -----------> Both | or +------> Receiver-only --> Sender-only | or +------> Sender-only ----> Receiver-only | or +-----> Receiver-only --> Receiver-only --> Sender-only or +-----> Sender-only ----> Sender-only ----> Receiver-only --------------------------------------------------------------------- Restart Specifies the file transfer restart capabilities of the User Monitor. Value: Negotiation: Request Indication Response Confirm --------------------------------------------------------------------- restart = Y ----> restart = Y --+-> restart = Y ----> restart = Y or +-> restart = N ----> restart = N restart = N ----> restart = N ----> restart = N ----> restart = N ---------------------------------------------------------------------Nash Informational [Page 12] RFC 2204 ODETTE File Transfer Protocol September 19973.3 File Transfer3.3.1 File Opening | | F_START_FILE_RQ ---->|------------|----> F_START_FILE_IND | | F_START_FILE_CF(+|-) <----|------------|<---- F_START_FILE_RS(+|-) | | Parameters: Request Ind. RS(+) CF(+) RS(-) CF(-) -------------------------------------------------------------------- file-name ----> same ---- ---- ---- ---- date-time ----> same ---- ---- ---- ---- destination---> same ---- ---- ---- ---- originator----> same ---- ---- ---- ---- rec-format----> same ---- ---- ---- ---- rec-size -----> same ---- ---- ---- ---- file-size-----> same ---- ---- ---- ---- restart-pos1--> same-> restart-pos2-> same ---- ---- ---- ---- ---- ---- cause ------> same ---- ---- ---- ---- retry-later-> same -------------------------------------------------------------------- Notes: 1. Retry-later has values "Y" or "N". 2. Cause is the reason for refusing the transfer (1,..,13,99). 3. Restart-pos1 not equal 0 is only valid if restart has been agreed during initial negotiation. 4. Restart-pos2 is less than or equal to restart-pos1.3.3.2 Data Regime | | F_DATA_RQ ---->|------------|----> F_DATA_IND | | Notes: 1. The data format within a F_DATA primitive is locally defined. 2. The File Transfer service may have to provide a flow control mechanism to regulate the flow of F_DATA primitives.Nash Informational [Page 13] RFC 2204 ODETTE File Transfer Protocol September 19973.3.3 File Closing | | F_CLOSE_FILE_RQ --->|------------|----> F_CLOSE_FILE_IND | | F_CLOSE_FILE_CF(+|-) <---|------------|<---- F_CLOSE_FILE_RS(+|-) | | Parameters Request Ind RS(+) CF(+) RS(-) CF(-)⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -