📄 rfc2204.txt
字号:
| |<-------------+ | IDLE SPEAKER |
| IDLE SPEAKER | | (4) |
| (1) | decision | CD_IND |
| |<-----------------------------| just received |
o=================o F_EERP_RQ o-----------------o
A A | |
| | | decision and P1 decision and P1 |
| | +-----------------+ +---------------------+
| | F_START_FILE_RQ | | F_START_FILE_RQ
| | V V
| | o---------------o
| | f_file_start_cf(-) | |
| +----------------------| OPENING |
| | |
| o---------------o
| |
f_file_close_cf(-) f_start_file_cf(+)
and not P2 |
| V
o---------------o o---------------o
| | | |------------------+
| CLOSING | | DATA TRANSFER | record to send |
| | | |<-----------------+
o---------------o o---------------o F_DATA_RQ
| A |
| | end of file |
| +-------------------+
| F_CLOSE_FILE_RQ
| o-----------------o
| f_close_file(+) and P2 | IDLE LISTENER |
+--------------------------------------------->| see (2), Listen |
| State Diagram |
Predicates: o-----------------o
P1: Mode = Both or (Mode = Sender-Only)
P2: Negative confirmation or (positive confirmation, Speaker = YES)
Nash Informational [Page 20]
RFC 2204 ODETTE File Transfer Protocol September 1997
3.5.3 Listener State Diagram
o-----------------o o-----------------o
| IDLE SPEAKER | | IDLE |
| CD_IND just | | |
| received see(4) | | see (0) |
| Speaker State | | Idle |
| Diagram | | State Diagram |
o-----------------o o-----------------o
A A
| |
decision f_eerp_ind decision
F_CD_IND +--------------+ F_RELEASE_IND
| | | |
o=================o | o-----------------o
| |<-----------+ f_eerp_ind | |
| |<-----------------------------| IDLE LISTENER |
| IDLE LISTENER | | (3) |
| | f_start_file_ind | CD_RQ |
| (2) | and not p2 | just sent |
| |---------------------+ | |
o=================o F_START_FILE_RS(-) | o-----------------o
A | A A | | |
| | | +-----------------------+ | |
| | | | |
| | | f_start_file_ind and not p2 | |
| | +--------------------------------------+ |
| | F_START_FILE_RS(-) |
| | |
| | f_start_file_ind f_start_file_ind |
| | and p2 and p2 |
| +-------------------------------+ +------------------+
| F_START_FILE_RS(+) | | F_START_FILE_RS(+)
| V V
| o---------------o
| f_close_file_ind and not p1 | DATA |-------------+
+------------------------------| TRANSFER | |
F_CLOSE_FILE_RS(-) | |<------------+
o---------------o F_DATA_IND
o---------------o |
| IDLE SPEAKER | f_close_file_ind and p1 |
| see (1), Spkr |<--------------------------+
| State Diagram | F_CLOSE_FILE_RS(+)
o---------------o
Predicates:
P1: (decision to send F_CLOSE_FILE_RS(+)) and
(decision to set Speaker = yes in F_CLOSE_FILE_RS(+))
P2: (decision to send F_START_FILE_RS(+))
Nash Informational [Page 21]
RFC 2204 ODETTE File Transfer Protocol September 1997
4. Protocol Specification
4.1 Overview
The ODETTE-FTP protocol is divided into five operating phases.
Start Session
Start File
Data Transfer
End File
End Session
After the End File phase an ODETTE-FTP entity may enter a new Start
File phase or terminate the session via the End Session phase.
ODETTE-FTP peers communicate by sending and receiving messages in
Exchange Buffers via the Network Service. Each Exchange Buffer
contains one of the following commands.
SSRM Start Session Ready Message
SSID Start Session
SFID Start File
SFPA Start File Positive Answer
SFNA Start File Negative Answer
DATA Data
CDT Set Credit
EFID End File
EFPA End File Positive Answer
EFNA End File Negative Answer
ESID End Session
CD Change Direction
EERP End to End Response
RTR Ready To Receive
The remainder of this section describes the protocol flows. Section
five details the command formats.
4.2 Start Session Phase
The Start Session phase is entered immediately after the network
connection has been established.
4.2.1 Entity Definition
The ODETTE-FTP entity that took the initiative to establish the
network connection becomes the Initiator. It's peer becomes the
Responder.
Nash Informational [Page 22]
RFC 2204 ODETTE File Transfer Protocol September 1997
4.2.2 Protocol Sequence
The first message must be sent by the Responder.
1. Initiator <-------------SSRM -- Responder Ready Message
-- SSID ------------> Identification
<------------ SSID -- Identification
4.3 Start File Phase
4.3.1 Entity Definition
The Initiator from the Start Session phase is designated the Speaker
while the Responder becomes the Listener. The roles are reversed by
the Speaker sending a Change Direction command to the Listener.
4.3.2 Protocol Sequence
1. Speaker -- SFID ------------> Listener Start File
<------------ SFPA -- Answer YES
2. Speaker -- SFID ------------> Listener Start File
<------------ SFNA -- Answer NO
Go To 1
Note: The User Monitor should take steps to prevent a loop
situation occurring.
2. Speaker -- CD --------------> Listener Change Direction
Listener <------------ EERP -- Speaker End to End Response
-- RTR -------------> Ready to Receive
<------------ SFID -- Start File
4.3.3 Restart Facilities
The Start File command includes a count allowing the restart of an
interrupted transmission to be negotiated. If restart facilities are
not available the restart count must be set to zero. The sender will
start with the lowest record count + 1.
4.3.4 Broadcast Facilities
The destination in a Start File command can be specified as follows.
1. An explicitly defined destination.
Nash Informational [Page 23]
RFC 2204 ODETTE File Transfer Protocol September 1997
2. A group destination that allows an intermediate location to
broadcast the Virtual File to multiple destinations.
The Listener will send a negative answer to the Speaker when the
destination is not known.
4.3.5 Priority
The prioritisation of files for transmission is left to the local
implementation. To allow some flexibility, a change direction
mechanism is available in the End File phase.
4.3.6 End To End Response (EERP)
The End to End Response (EERP) command notifies the originator of a
Virtual File that it has been successfully delivered to it's final
destination. This allows the originator to perform house keeping
tasks such as deleting copies of the delivered data.
A Response Command must be sent from the location performing the
final processing or distribution of the data to the originator. The
Response is mandatory and may be sent in the same or in any
subsequent session.
When an intermediate location broadcasts or distributes a Virtual
File it must receive a Response command from all the locations to
which it forwarded the data before sending it's own Response. This
ensures that the Response received by the Virtual File's originator
accounts for all the destination locations. An intermediate location
therefore needs to track the status of files it processes over time.
Example: Point to Point
Location A sends file Ba to Location B which will send an EERP to
location A after it successfully receives the file.
o----------o o-----------o
| Loc. A |----------- S1 ---------->| Loc. B |
| | | |
| [Ba] |<---------- R2 -----------| [Ba] |
+----------o o-----------o
Key:
S - File Transfer R - Response EERP [Ba] - File for B from A
Nash Informational [Page 24]
RFC 2204 ODETTE File Transfer Protocol September 1997
Example: Data distribution
Location A sends a Virtual File containing data for distribution to
locations B and C via clearing centres E1 and E2. Clearing centre E1
must wait for a response from E2 (for file Ba) and location C before
it sends it's response, R8, to location A. Clearing centre E2 can
only send response R7 to E1 when location B acknowledges file Ba with
response R6.
o---------o o---------o o---------o o---------o
| Loc. A |-- S1 ->| Loc. E1 |-- S2 ->| Loc. E2 |-- S5 ->| Loc. B |
| | | | | | | |
| [Ba,Ca] |<- R8 --| [Ba,Ca] |<- R7 --| [Ba] |<- R6 --| [Ba] |
o---------o o---------o o---------o o---------o
A |
| | o---------o
| +----- S3 ->| Loc. C |
| | |
+--------- R4 --| [Ca] |
o---------o
Example: Data collection
Locations A and B send files Ca and Cb to clearing centre E1 which
forwards both files to location C in a single Virtual File. When it
receives response R4 from C, clearing centre E1 sends response R5 to
location A and R6 to location B.
o---------o o---------o o---------o
| Loc. A |-- S1 ->| Loc. E1 |-- S3 ->| Loc. C |
| | | | | |
| [Ca] |<- R5 --| [Ca,Cb] |<- R4 --| [Ca,Cb] |
o---------o o---------o o---------o
A |
o---------o | |
| Loc. B |-- S2 -----+ |
| | |
| [Cb] |<- R6 ---------+
o---------o
4.3.7 Ready To Receive Command (RTR)
In order to avoid congestion between two adjacent nodes caused by a
continuous flow of EERP's, a Ready To Receive (RTR) command is
provided. The RTR acts as an EERP acknowledgement for flow control
but has no end-to-end significance.
Nash Informational [Page 25]
RFC 2204 ODETTE File Transfer Protocol September 1997
Speaker -- EERP ------------> Listener End to End Response
<------------- RTR -- Ready to Receive
-- EERP ------------> End to End Response
<------------- RTR -- Ready to Receive
-- SFID ------------> Start File
or
-- CD --------------> Exchange the turn
After sending an EERP, the Speaker must wait for an RTR before
sending any other commands.
4.4 Data Transfer Phase
Virtual File data flows from the Speaker to the Listener during the
Data Transfer phase which is entered after the Start File phase.
4.4.1 Protocol Sequence
To avoid congestion at the protocol level a flow control mechanism is
provided via the Credit (CDT) command.
A Credit limit is negotiated in the Start Session phase, this
represents the number of Data Exchange Buffers that the Speaker may
send before it is obliged to wait for a Credit command from the
Listener.
The available credit is initially set to the negotiated value by the
Start File positive answer, which acts as an implicit Credit command.
The Speaker decreases the available credit count by one for each data
buffer sent to the Listener.
When the available credit is exhausted, the Speaker must wait for a
Credit command from the Listener otherwise a protocol error will
occur and the session will be aborted.
The Listener should endeavour to send the Credit command without
delay to prevent the Speaker blocking.
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -