rfc2204.txt

中、英文RFC文档大全打包下载完全版 .

   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.

   1. Speaker  -- SFID ------------> Listener   Start File
               <------------ SFPA --            Answer YES











Nash                         Informational                     [Page 26]

RFC 2204             ODETTE File Transfer Protocol        September 1997


   2. If the Credit Value is set to 2

      Speaker  -- Data ------------> Listener   Start File
               -- Data ------------>
               <------------- CDT --            Set Credit
               -- Data ------------>
               -- EFID ------------>            End File

4.5  End File Phase

4.5.1  Protocol Sequence

   The Speaker notifies the Listener that it has finished sending a
   Virtual File by sending an End File (EFID) command.  The Listener
   replies with a positive or negative End File command and has the
   option to request a Change Direction command from the Speaker.

   1. Speaker  -- EFID ------------> Listener   End File
               <------------ EFPA --            Answer YES


   2. Speaker  -- EFID ------------> Listener   End File
               <------------ EFPA --            Answer YES + CD
               -- CD -------------->            Change Direction
      Listener <------------ EERP -- Speaker    End to End Response
               -------------- RTR ->            Ready to Receive