rfc1301.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,474 行 · 第 1/5 页

   |                  multicast connection                  |      |
   |                  identifier                            |      |
   ----------------------------------------------------------    -----

                           Figure 3. join packet

   The join[confirm] will also contain the multicast connection
   identifier.  This must be used to form the TSAP that will be the
   destination for all multicast messages for the transport. The source



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


   of the join[confirm] message will be the master's TSAP and must be
   recorded by the member for later use.

   The master must be in possession of all the transmit tokens when it
   sends a join[confirm]. Requiring the master to have the transmit
   tokens insures that the joining member will enter the web and observe
   only complete messages. It also permits a notification of the
   master's client of the join so that application state may be
   automatically sent to the newly joining member. The newly joined
   member may be on a network not previously represented in the web's
   membership, thus requiring a new multicast TSAP be added to the
   existing list. The entire list will be conveyed in the data field of
   all subsequent token[confirm] messages (described later).

3.2     Maintaining data consistency

   The transport is responsible for maintaining the consistency of the
   data submitted for delivery by producing clients. The actual client
   data, while representing the bulk of the information that flows
   through the web, is accompanied by significant amounts of protocol
   state information. In addition to the state information piggybacked
   with the client data, there is a minimum amount of protocol packets
   that are purely for use by the transport, invisible to the transport
   client.

3.2.1.  Transmit tokens

   Before any process may transmit client data or state it must first
   possess a transmit token. It may acquire the token by transmitting a
   token[request] to the master. Requests should be unicast to the
   master's TSAP and should be retransmitted at intervals approximately
   equal to the heartbeat. Since it is the central source for a transmit
   token, the master may apply some fairness algorithms to the passing
   of permission to transmit. At a minimum the requests should be queued
   in a first in, first out order. Duplicate requests from a single
   member should be ignored, keeping instead the first unhonored
   request. When appropriate, the master will send a member with a
   request pending a token[confirm].  The data field of the response
   contains all the multicast TSAPs that are represented in the current
   web at that point in time.

   If the master detects no data or heartbeat messages being transmitted
   into the web it will assume the token is lost, presumably because the
   member holding the token has failed or has become partitioned away
   from the master. In such cases, the master may attempt to confirm the
   state of the process (perhaps by sending isMember[request]). If the
   member does not respond it is removed from the active members of the
   web, the message is marked as rejected, the token is assumed by the



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


   master.

   Figure 4 shows a timing diagram of a token pass. Increasing time is
   towards the bottom of the figure. In this figure, process A has a
   token, and process B requests a token when there are no free tokens.

                           A    master    B
    "A" multicasts data    |             |  "B" requests
                           |\     |      |  transmit token
                           | \    |     /|
                           |  \   |    / |
                           |   \  |   /  |
    "A" multicasts data    |    \ |  /   |  "B" retransmits
    w/eom set              |\    \| /    |  token request
                           | \    \V    /|
                           |  \   |\   / |
                           |   \  | V /  |
                           |    \ |  /   |
                           |     \| /    |
                           |      \V     |
                           |      |\     |
                           |      | V    |
                           |      |\     |  Master assigns
                           |      | \    |  token to "B"
                           |      |  \   |
                           |      |   \  |
                           |      |    \ |
                           |      |     V|
                           |      |      |
                           |      |     /|  "B" multicasts
                           |      |    / |  data
                           |      |   /  |
                           |      |  /   |
                           |      | /    |
                           |      |/     |
                           |      /      |
                           |     /|      |
                           |    V |      |
                           |      |      |

                     Figure 4. Acquiring the token

   Token packets, like other control packets, do not consume sequence
   numbers. Hence, the master must be able to use another mechanism to
   determine whether multiple token[request] from a single member are
   actually requests for a separate token, or are a retransmission of a
   token[request].  To carry out this obligation, the master and the
   members must have an implicit understanding of each other's state.



Armstrong, Freier & Marzullo                                   [Page 18]

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          |      |
   ----------------------------------------------------------    -----
   |                                                        |      |
   |                                                        |      |
   |                   TSAPs of all networks                |
   |                   represented in the web               |    data
   |                   membership                           |
   |                                                        |      |
   |                                                        |      |
   ----------------------------------------------------------    -----

                          Figure 5. token packet

   Assume that the token, as viewed by the master, has three states:

   idle        The token is not currently assigned. Specifically the
               message number that it defines is not represented in the
               current message acceptance vector.

   pending     The token has been assigned by the master via a
               token[confirm] packet, but the master has not yet seen
               any data packets to indicate that the from the producing
               member received the notification.

   busy        The token has been assigned and the master has seen data
               packets carrying the assigned message number. The message
               comprised by those packets is still represented in the
               message acceptance vector.

   Furthermore, a token that is not idle also has associated with its



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


   state the TSAP of the process that owns (or owned) the token.

   Based on this state, the master will respond to any process that has
   a token in pending state with a reassignment of that token. This is
   based on the assumption that the original token[confirm] was not
   received by the requesting process. The only other possibility is
   that the process did receive the token and transmitted data packets
   using that token, but the master did not see them. But data messages
   are by design multi-packet messages, padded with empty packets if
   necessary. The possibility of the master missing all of the packets
   of a message is considered less than the possibility of the
   requesting process missing a single token[confirm] packet.

   The process requesting tokens must consider the actions of the master
   and what prompted them. In most cases the assumptions made by the
   master will be correct. However, there are two ambiguous situations.
   There is the situation that the master is most directly addressing,
   not knowing whether the requesting process has failed to observe the
   token[confirm] or the master has failed to see data packets
   transmitted by the producing process. There is also the possibility
   that the requesting process timed out too quickly and the
   retransmission of the token[request] passed the token[confirm] in the
   night. In any case the producing process may find itself in
   possession of a token for which it has no need. These can be
   dismissed by sending an empty[cancel] packet.

   Another possibility is that the requesting process has actually made
   use of the assigned token and is requesting another token. Unless the
   master has observed data using the token, the master will still
   consider the token pending. Therefore, a process that receives a
   duplicate token[confirm] should interpret it as a nak and retransmit
   any data packets previously sent using the token's message sequence
   number.

3.2.2.  Data transmission

   Data is provided by the transport client in the form of uninterpreted
   bytes. The bytes are encapsulated in packets immediately following
   the protocol's fixed overhead fields. The packet may have any number
   of data bytes between zero and the maximum number of bytes of a
   network protocol packet minus the network overhead and the fixed
   transport overhead.  Every packet that consumes a sequence number
   must contain either client data or client state transitions such as
   the end of message indicator or a subchannel transition.

   Packets are transmitted in bursts of packets called windows. The
   protocol guarantees that no more than the current value of window
   data packets will be transmitted by a single process during a



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


   heartbeat.  Every packet transmitted always contains the latest
   heartbeat, window and retention information. If full packets are
   unavailable [5], empty[dally] messages should be transmitted instead.
   The only packets that will be transmitted containing less than
   maximum capacity will be data[eom] or those containing client
   subchannel transitions.













































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