rfc1301.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

                      |      |
                      |      |
            -----     |      |    Packets n+w..n+2w-1 are released.


                    Figure 6. Normal data transmission

   Figure 6 shows a timing diagram of a process transmitting into a web
   (without any complicating naks). Increasing time is towards the
   bottom of the figure. The transmitting process is obligated to



Armstrong, Freier & Marzullo                                   [Page 22]

RFC 1301              Multicast Transport Protocol         February 1992


   retransmit requested packets for at least retention heartbeat
   intervals after their first transmission.

    0           7 8           15 16         23 24         31
   ----------------------------------------------------------    -----
   |  protocol    |    packet   |    type     |    client   |      |
   |  version     |    type     |    modifier |    channel  |      |
   ----------------------------------------------------------      |
   |                                                        |      |
   |              source connection identifier              |      |
   ----------------------------------------------------------      |
   |                                                        |      |
   |              destination connection identifier         |
   ---------------------------------------------------------- transport
   |                                                        |    header
   |              message acceptance criteria               |
   ----------------------------------------------------------      |
   |                                                        |      |
   |              heartbeat                                 |      |
   ----------------------------------------------------------      |
   |                            |                           |      |
   |        window              |        retention          |      |
   ----------------------------------------------------------    -----
   |                                                        |      |
   |                   uninterpreted data                   |
   |                                                        |    data
   |                                                        |
   |                                                        |      |
   ----------------------------------------------------------    -----

                           Figure 7. data packet

3.2.3.  Empty packets

   An empty packet is a control packet multicast into the web at regular
   intervals by a producer possessing a transmit token when no client
   data is available. Empty packets are sent to maintain synchronization
   and to advertise the maximum sequence number of the producer. It
   provides the opportunity for consuming processes to detect and
   request retransmission of missed data as well as identifying the
   owner of a transmit token.










Armstrong, Freier & Marzullo                                   [Page 23]

RFC 1301              Multicast Transport Protocol         February 1992


    0           7 8           15 16         23 24         31
   ----------------------------------------------------------    -----
   |  protocol    |    packet   |    type     |    client   |      |
   |  version     |    type     |    modifier |    channel  |      |
   ----------------------------------------------------------      |
   |                                                        |      |
   |              source connection identifier              |      |
   ----------------------------------------------------------      |
   |                                                        |      |
   |              destination connection identifier         |
   ---------------------------------------------------------- transport
   |                                                        |    header
   |              message acceptance criteria               |
   ----------------------------------------------------------      |
   |                                                        |      |
   |              heartbeat                                 |      |
   ----------------------------------------------------------      |
   |                            |                           |      |
   |        window              |        retention          |      |
   ----------------------------------------------------------    -----

                          Figure 8. empty packet

   There are two situations where the empty[dally] packet is used. The
   first is when there is insufficient data for a full packet presented
   by the client during a heartbeat. Partial packets should not be
   transmitted unless there is a client transition to be conveyed, yet
   something must be transmitted during a heartbeat or the master may
   think the process owning a transmit token has failed. Empty[dally] is
   used instead of a data packet until the client provides additional
   data to fill a packet or indicates a state transition such as an end
   of message or subchannel transition.

   The second situation where empty[dally] is used is after the
   transmission of short messages. Each message should consist of
   multiple packets in order to enhance the possibility that consumers
   will observe at least one packet of a message and therefore be able
   to identify the producer. The transport parameter retention has
   approximately the correct properties for that insurance. Therefore, a
   message must consist of at least retention packets. If the client
   data does not require that many packets, empty[dally] packets must be
   appended. A process that has no transmittable data and is in
   possession of a transmit token must send an empty[cancel].
   Transmissions of empty[cancel] packets pass the ownership of the
   transmit token back to the master. When the master observes the
   control packet, it will mark the referenced to message as rejected so
   that other consumers do not believe the message lost and attempt to
   recover.



Armstrong, Freier & Marzullo                                   [Page 24]

RFC 1301              Multicast Transport Protocol         February 1992


   During periods of no activity (i.e., after all messages have been
   either accepted or rejected and there are no outstanding transmit
   tokens) the master may enter hibernation mode by transmitting
   empty[hibernate] packets. In that mode the master will increase the
   value of the transport parameter heartbeat in order to reduce network
   traffic. Such packets are used to indicate that the packet's
   heartbeat field should not be used for resource computation by those
   processes that observe it.











































Armstrong, Freier & Marzullo                                   [Page 25]

RFC 1301              Multicast Transport Protocol         February 1992


3.2.4.  Missed data

   The most common method of detecting data loss will be the reception
   of a data or a heartbeat message that has a sequence number greater
   than expected from that producer. The second most common method will
   be a message fragment (missing the end of message) and seeing no more
   data or empty packets from the producer of the fragment for more than
   a single heartbeat. In any case the consumer process directs a
   negative acknowledgment (nak) to the producer of the incomplete
   message. The data field of the nak message contains a list of
   ascending sequence number pairs the consumer needs to recover the
   missed data.

    0           7 8           15 16         23 24         31
   ----------------------------------------------------------    -----
   |  protocol    |    packet   |    type     |    client   |      |
   |  version     |    type     |    modifier |    channel  |      |
   ----------------------------------------------------------      |
   |                                                        |      |
   |              source connection identifier              |      |
   ----------------------------------------------------------      |
   |                                                        |      |
   |              destination connection identifier         |
   ---------------------------------------------------------- transport
   |                                                        |    header
   |              message acceptance criteria               |
   ----------------------------------------------------------      |
   |                                                        |      |
   |              heartbeat                                 |      |
   ----------------------------------------------------------      |
   |                            |                           |      |
   |        window              |        retention          |      |
   ----------------------------------------------------------    -----
   |                            |                           |      |
   |  message sequence (low)    |  packet sequence (low)    |
   ----------------------------------------------------------    data
   |                            |                           |
   |  message sequence (high)   |  packet sequence (high)   |      |
   ----------------------------------------------------------    -----

                           Figure 9. nak packet

3.2.5.  Retrying operations

   Operations must be retried in order to assure that a single packet
   loss does not cause transport failure. In general the right numbers
   to do that with exist in the transport. The proper interval between
   retries is the transport's time constant or heartbeat. The proper



Armstrong, Freier & Marzullo                                   [Page 26]

RFC 1301              Multicast Transport Protocol         February 1992


   number of retries is retention.

   Operations that are retriable (and represented by their respective
   message types) are join, nak, token, isMember and quit. Another
   application for the heartbeat and retention is when transmitting
   empty messages. Empty[dally] messages are transmitted any time data
   is not available but the data[eom] has not yet been sent. Any process
   not observing data or empty for more than retention heartbeat
   intervals will assume to have failed or partitioned away and the
   transport will be abandoned.

3.2.6.  Retransmission

   If the producer receives a nak[request] from a consumer process
   requesting the retransmission of a packet that is no longer
   available, the producer must send a nak[deny] to the source of the
   request. If that puts the consumer in a failed state, the consumer
   will initiate the withdrawal from the web. If a producer receives a
   nak[request] from a consumer requesting the retransmission of one or
   more packets, those packets will be multicast to the entire web [6].
   All will contain the original client information (such as subchannel
   and end of message state) and message and packet sequence number.
   However, the retransmitted packets must contain updated protocol
   parameter information (heartbeat, window and retention).
   Retransmitted packets are subject to the same constraints regarding
   heartbeat and window as original transmissions. Therefore the
   producer's retransmissions consume a portion of the allocation window
   allowing less new data to be transmitted in a single heartbeat.
   Retransmitted packets have priority over (i.e., should be transmitted
   before) new data packets.





















Armstrong, Freier & Marzullo                                   [Page 27]

RFC 1301              Multicast Transport Protocol         February 1992


            -----     |       |     retransmission count = rx=0
              |       |\     |
              |       | \    |
              |