📄 rfc2204.txt
字号:
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 1997
3.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(-)
---------------------------------------------------------------------
rec-count ---> same ---- ---- ---- ----
unit-count --> same ---- ---- ---- ----
---- ---- Speaker=Y ---> Speaker=N ---- ----
---- ---- Speaker=N ---> Speaker=Y ---- ----
---- ---- ---- ---- cause ---> same
---------------------------------------------------------------------
In a positive Close File response (F_CLOSE_FILE_RS(+)) the current
Speaker may either:
1. Set Speaker to "Yes" and become the Speaker. 2. Set Speaker
to "No" and remain the Listener.
The File Transfer service will ensure that the setting of the speaker
parameter is consistent with the capabilities of the peer user.
The turn is never exchanged in the case of a negative response or
confirmation.
Only the Speaker is allowed to issue F_XXX_FILE_RQ primitives.
3.3.4 Exchanging the Turn
3.3.4.1 Initial Turn (First Speaker)
The Initiator becomes the first Speaker at the end of the Session
Setup (F_CONNECT_CF received by Initiator and F_CONNECT_RS sent by
Responder).
3.3.4.2 Following Turns
Rules:
1. At each unsuccessful End of File the turn is not exchanged.
2. At each successful End of File the turn is exchanged if requested
by the Listener:
Nash Informational [Page 14]
RFC 2204 ODETTE File Transfer Protocol September 1997
- The current Listener receives F_CLOSE_FILE_IND
(Speaker = choice).
- If the Listener answers F_CLOSE_FILE_RS(Speaker = YES), it
becomes Speaker, the Speaker receives F_CLOSE_FILE_CF (Speaker =
NO) and becomes Listener.
- If the Listener answers F_CLOSE_FILE_RS(Speaker = NO), it
remains Listener, and the Speaker receives F_CLOSE_FILE_CF
(Speaker = YES) and remains Speaker.
3. The Speaker can issue a Change Direction request (F_CD_RQ) to
become the Listener. The Listener receives a Change Direction
indication (F_CD_IND) and becomes the Speaker.
4. In order to prevent loops of F_CD_RQ/IND, it is an error to send
F_CD_RQ immediately after having received a F_CD_IND.
3.3.5 End to End Response
This service is initiated by the current Speaker (if there is no file
transfer in progress) to send an End-to-End response from the final
destination to the originator of a file.
| |
F_EERP_RQ ---->|------------|----> F_EERP_IND
| |
Parameters
Request Indication
------------------------------------
filename -------> same
date -----------> same
time -----------> same
destination ----> same
originator -----> same
------------------------------------
Relationship with Turn:
- Only the Speaker may send an End to End Response request.
- Invoking the EERP service does not change the turn.
- If a F_CD_IND has been received just before F_EERP_RQ is issued,
this results in leaving the special condition created by the
reception of F_CD_IND; i.e. while it was possible to issue
F_RELEASE_RQ and not possible to issue F_CD_RQ just after the
Nash Informational [Page 15]
RFC 2204 ODETTE File Transfer Protocol September 1997
reception of F_CD_IND, after having issued F_EERP_RQ the normal
Speaker status is entered again (F_CD_RQ valid, but F_RELEASE_RQ
not valid).
3.4 Session Take Down
3.4.1 Normal Close
| |
F_RELEASE_RQ ---->|------------|----> F_RELEASE_IND
| |
Parameters
Request Indication
---------------------------------------------------------------------
reason = normal -------> ----
---------------------------------------------------------------------
The Release service can only be initiated by the Speaker.
The Speaker can only issue a Release request (F_RELEASE_RQ) just
after receiving an unsolicited Change Direction indication
(F_CD_IND). This ensures that the other partner doesn't want to send
any more files in this session.
Peer ODETTE-FTP entities action a normal session release by
specifying Reason = Normal in an End Session (ESID) command.
3.4.2 Abnormal close
| |
F_RELEASE_RQ ---->|------------|----> F_ABORT_IND
| |
Parameters
Request Indication
---------------------------------------------------------------------
reason = error value --> same (or equivalent)
AO (Abort Origin) = (L)ocal or (D)istant
---------------------------------------------------------------------
Abnormal session release can be initiated by either the Speaker or
the Listener and also by the user or provider.
Abnormal session release can occur at any time within the session.
Nash Informational [Page 16]
RFC 2204 ODETTE File Transfer Protocol September 1997
Peer ODETTE-FTP entities action an abnormal session release by
specifying Reason = Error-value in an End Session (ESID) command.
The abnormal session release deals with the following types of error:
1. The service provider will initiate an abnormal release in the
following cases:
1. Protocol error, 2. Failure of the Start Session (SSID)
negotiation, 3. Command not recognised, 4. Exchange buffer size
error, 5. Resources not available, 6. Other unspecified abort code
(with "REASON" = unspecified).
2. The User Monitor will initiate an abnormal release in the
following cases:
1. Local site emergency close down, 2. Resources not available, 3.
Other unspecified abort code (with "REASON" = unspecified).
Other error types may be handled by an abort of the connection.
3.4.3 Abort
| |
F_ABORT_RQ ---->|------------|----> F_ABORT_IND
| |
User Initiated Abort
| |
F_ABORT_IND <----|------------|----> F_ABORT_IND
| |
Provider Initiated Abort
Parameters
Request Indication
---------------------------------------------------------------------
-- R (Reason): specified or unspecified
-- AO (Abort Origin): (L)ocal or (D)istant
---------------------------------------------------------------------
The Abort service may be invoked by either entity at any time.
The service provider may initiate an abort in case of error
detection.
Nash Informational [Page 17]
RFC 2204 ODETTE File Transfer Protocol September 1997
3.4.4 Explanation of Session Take Down Services
User | OFTP | Network | OFTP | User
---------------|------|----------------------|------|---------------
| | | |
1. Normal Release
F_RELEASE_RQ | | ESID(R=normal) | | F_RELEASE_IND
*--------------|-> ==|======================|=> --|-------------->
(R=normal) | | | |
2. User Initiated Abnormal Release
F_RELEASE_RQ | | ESID(R=error) | | F_ABORT_IND
*--------------|-> ==|======================|=> -|-------------->
(R=error value)| | | | (R=error,AO=D)
User | OFTP | Network | OFTP | User
---------------|------|----------------------|------|---------------
| | | |
3. Provider Initiated Abnormal Release
F_ABORT_IND | | ESID(R=error) | | F_ABORT_IND
<--------------|-* *=|======================|=> --|-------------->
| | | |
4. User Initiated Connection Abort
F_ABORT_RQ | | N_DISC_RQ | | F_ABORT_IND
*--------------|-> --|--------->..----------|-> --|-------------->
| | N_DISC_IND | | (R=unsp.,AO=D)
5. Provider Initiated Connection Abort
F_ABORT_IND | | N_DISC_RQ | | F_ABORT_IND
<--------------|-* *-|--------->..----------|-> --|-------------->
(R=error,AO=L) | | N_DISC_IND | | (R=unsp.,AO=D)
Key: * Origin of command flow
F_ ---> File Transfer Service primitive
N_ ---> Network Service primitive
===> ODETTE-FTP (OFTP) protocol message
Nash Informational [Page 18]
RFC 2204 ODETTE File Transfer Protocol September 1997
3.5 Service State Automata
This state automata defines the service as viewed by the User
Monitor. Events causing a state transition are shown in lower case
and the resulting action in upper case where appropriate.
3.5.1 Idle State Diagram
o------------o
decision | | f_connect_ind
+-----------------| IDLE |-----------------+
| F_CONNECT_RQ | (0) | F_CONNECT_RS |
| o------------o |
V |
o-----------------o |
| | |
| I_WF_FCONNECTCF | |
| | |
o--------+--------o |
| |
| F_CONNECT_CF |
V V
o-----------------o o-----------------o
| | | |
| IDLE SPEAKER | | IDLE LISTENER |
| (1) | | (2) |
| See Speaker | | See Listener |
| State Diagram | | State Diagram |
| | | |
o-----------------o o-----------------o
Nash Informational [Page 19]
RFC 2204 ODETTE File Transfer Protocol September 1997
3.5.2 Speaker State Diagram
o-----------------o o-----------------o
| IDLE LISTENER | | IDLE |
| CD_RQ just sent | | see (0) |
| see (3), Listen | | Idle |
| State Diagram | | State Diagram |
o-----------------o o-----------------o
A A
| |
decision decision decision
F_CD_RQ +----------------+ F_RELEASE_RQ
| | F_EERP_RQ | |
o=================o | o-----------------o
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -