rfc3259.txt

RFC 的详细文档！

Ott, et. al.                 Informational                     [Page 17]

RFC 3259          A Message Bus for Local Coordination        April 2002


      An address element a1 is contained in an address element list if
      the list contains an element that is equal to a1.  An address
      element is considered equal to another address element if it has
      the same values for both of the two address element fields (tag
      and value).

7.  Reliability

   While most messages are expected to be sent using unreliable
   transport, it may be necessary to deliver some messages reliably.
   Reliability can be selected on a per message basis by means of the
   MessageType field.  Reliable delivery is supported for messages with
   a single recipient only; i.e., to a fully qualified Mbus address.  An
   entity can thus only send reliable messages to known addresses, i.e.,
   it can only send reliable messages to entities that have announced
   their existence on the Mbus (e.g., by means of mbus.hello() messages
   as defined in Section 9.1).  A sending entity MUST NOT send a message
   reliably if the target address is not unique.  (See Section 6 for the
   specification of an algorithm to determine whether an address is
   unique.)  A receiving entity MUST only process and acknowledge a
   reliable message if the destination address exactly matches its own
   source address (the destination address MUST NOT be a subset of the
   source address).

   Disallowing reliable message delivery for messages sent to multiple
   destinations is motivated by simplicity of the implementation as well
   as the protocol.  The desired effect can be achieved at the
   application layer by sending individual reliable messages to each
   fully qualified destination address, if the membership information
   for the Mbus session is available.

   Each message is tagged with a message sequence number.  If the
   MessageType is "R", the sender expects an acknowledgment from the
   recipient within a short period of time.  If the acknowledgment is
   not received within this interval, the sender MUST retransmit the
   message (with the same message sequence number), increase the
   timeout, and restart the timer.  Messages MUST be retransmitted a
   small number of times (see below) before the transmission or the
   recipient are considered to have failed.  If the message is not
   delivered successfully, the sending application is notified.  In this
   case, it is up to the application to determine the specific actions
   (if any) to be taken.









Ott, et. al.                 Informational                     [Page 18]

RFC 3259          A Message Bus for Local Coordination        April 2002


   Reliable messages MUST be acknowledged by adding their SeqNum to the
   AckList field of a message sent to the originator of the reliable
   message.  This message MUST be sent to a fully qualified Mbus target
   address.  Multiple acknowledgments MAY be sent in a single message.
   Implementations MAY either piggy-back the AckList onto another
   message sent to the same destination, or MAY send a dedicated
   acknowledgment message, with no commands in the message payload part.

   The precise procedures are as follows:

   Sender: A sender A of a reliable message M to receiver B MUST
      transmit the message either via IP-multicast or via IP-unicast,
      keep a copy of M, initialize a retransmission counter N to '1',
      and start a retransmission timer T (initialized to T_r).  If an
      acknowledgment is received from B, timer T MUST be cancelled and
      the copy of M is discarded.  If T expires, the message M MUST be
      retransmitted, the counter N MUST be incremented by one, and the
      timer MUST be restarted (set to N*T_r).  If N exceeds the
      retransmission threshold N_r, the transmission is assumed to have
      failed, further retransmission attempts MUST NOT be undertaken,
      the copy of M MUST be discarded, and the sending application
      SHOULD be notified.

   Receiver: A receiver B of a reliable message from a sender A MUST
      acknowledge reception of the message within a time period T_c <
      T_r.  This MAY be done by means of a dedicated acknowledgment
      message or by piggy-backing the acknowledgment on another message
      addressed only to A.

   Receiver optimization: In a simple implementation, B may choose to
      immediately send a dedicated acknowledgment message.  However, for
      efficiency, it could add the SeqNum of the received message to a
      sender-specific list of acknowledgments; if the added SeqNum is
      the first acknowledgment in the list, B SHOULD start an
      acknowledgment timer TA (initialized to T_c).  When the timer
      expires, B SHOULD create a dedicated acknowledgment message and
      send it to A.  If B is to transmit another Mbus message addressed
      only to A, it should piggy-back the acknowledgments onto this
      message and cancel TA.  In either case, B should store a copy of
      the acknowledgment list as a single entry in the per-sender copy
      list, keep this entry for a period T_k, and empty the
      acknowledgment list.  In case any of the messages kept in an entry
      of the copy list is received again from A, the entire
      acknowledgment list stored in this entry is scheduled for (re-)
      transmission following the above rules.






Ott, et. al.                 Informational                     [Page 19]

RFC 3259          A Message Bus for Local Coordination        April 2002


   Constants and Algorithms: The following constants and algorithms
      SHOULD be used by implementations:

      T_r=100ms

      N_r=3

      T_c=70ms

      T_k=((N_r)*(N_r+1)/2)*T_r

8.  Awareness of other Entities

   Before Mbus entities can communicate with one another, they need to
   mutually find out about their existence.  After this bootstrap
   procedure that each Mbus entity goes through all other entities
   listening to the same Mbus know about the newcomer and the newcomer
   has learned about all the other entities.  Furthermore, entities need
   to be able to to notice the failure (or leaving) of other entities.

   Any Mbus entity MUST announce its presence (on the Mbus) after
   starting up.  This is to be done repeatedly throughout its lifetime
   to address the issues of startup sequence: Entities should always
   become aware of other entities independent of the order of starting.

   Each Mbus entity MUST maintain the number of Mbus session members and
   continuously update this number according to any observed changes.
   The mechanisms of how the existence and the leaving of other entities
   can be detected are dedicated Mbus messages for entity awareness:
   mbus.hello (Section 9.1) and mbus.bye (Section 9.2).  Each Mbus
   protocol implementation MUST periodically send mbus.hello messages
   that are used by other entities to monitor the existence of that
   entity.  If an entity has not received mbus.hello messages for a
   certain time (see Section 8.2) from an entity, the respective entity
   is considered to have left the Mbus and MUST be excluded from the set
   of currently known entities.  Upon the reception of a mbus.bye
   message the respective entity is considered to have left the Mbus as
   well and MUST be excluded from the set of currently known entities
   immediately.

   Each Mbus entity MUST send hello messages to the Mbus after startup.
   After transmission of the hello message, it MUST start a timer after
   the expiration of which the next hello message is to be transmitted.
   Transmission of hello messages MUST NOT be stopped unless the entity
   detaches from the Mbus.  The interval for sending hello messages is
   dependent on the current number of entities in an Mbus group and can
   thus change dynamically in order to avoid congestion due to many
   entities sending hello messages at a constant high rate.



Ott, et. al.                 Informational                     [Page 20]

RFC 3259          A Message Bus for Local Coordination        April 2002


   Section 8.1 specifies the calculation of hello message intervals that
   MUST be used by protocol implementations.  Using the values that are
   calculated for obtaining the current hello message timer, the timeout
   for received hello messages is calculated in Section 8.2.  Section 9
   specifies the command synopsis for the corresponding Mbus messages.

8.1  Hello Message Transmission Interval

   Since the number of entities in an Mbus session may vary, care must
   be taken to allow the Mbus protocol to automatically scale over a
   wide range of group sizes.  The average rate at which hello messages
   are received would increase linearly to the number of entities in a
   session if the sending interval was set to a fixed value.  Given an
   interval of 1 second this would mean that an entity taking part in an
   Mbus session with n entities would receive n hello messages per
   second.  Assuming all entities resided on one host, this would lead
   to n*n messages that have to be processed per second -- which is
   obviously not a viable solution for larger groups.  It is therefore
   necessary to deploy dynamically adapted hello message intervals,
   taking varying numbers of entities into account.  In the following,
   we specify an algorithm that MUST be used by implementors to
   calculate the interval for hello messages considering the observed
   number of Mbus entities.

   The algorithm features the following characteristics:

   o  The number of hello messages that are received by a single entity
      in a certain time unit remains approximately constant as the
      number of entities changes.

   o  The effective interval that is used by a specific Mbus entity is
      randomized in order to avoid unintentional synchronization of
      hello messages within an Mbus session.  The first hello message of
      an entity is also delayed by a certain random amount of time.

   o  A timer reconsideration mechanism is deployed in order to adapt
      the interval more appropriately in situations where a rapid change
      of the number of entities is observed.  This is useful when an
      entity joins an Mbus session and is still learning of the
      existence of other entities or when a larger number of entities
      leaves the Mbus at once.










Ott, et. al.                 Informational                     [Page 21]

RFC 3259          A Message Bus for Local Coordination        April 2002


8.1.1  Calculating the Interval for Hello Messages

   The following variable names are used in the calculation specified
   below (all time values in milliseconds):

   hello_p: The last time a hello message has been sent by a Mbus
      entity.

   hello_now: The current time

   hello_d: The deterministic calculated interval between hello
      messages.

   hello_e: The effective (randomized) interval between hello messages.

   hello_n: The time for the next scheduled transmission of a hello
      message.

   entities_p: The numbers of entities at the time hello_n has been last
      recomputed.

   entities: The number of currently known entities.

   The interval between hello messages MUST be calculated as follows:

   The number of currently known entities is multiplied by
   c_hello_factor, yielding the interval between hello messages in
   milliseconds.  This is the deterministic calculated interval, denoted
   hello_d.  The minimum value for hello_d is c_hello_min which yields

      hello_d = max(c_hello_min,c_hello_factor * entities * 1ms).

   Section 8 provides a specification of how to obtain the number of
   currently known entities.  Section 10 provides values for the
   constants c_hello_factor and c_hello_min.

   The effective interval hello_e that is to be used by individual
   entities is calculated by multiplying hello_d with a randomly chosen
   number between c_hello_dither_min and c_hello_dither_max as follows:

       hello_e = c_hello_dither_min +
                 RND * (c_hello_dither_max - c_hello_dither_min)

   with RND being a random function that yields an even distribution
   between 0 and 1.  See also Section 10.

   hello_n, the time for the next hello message in milliseconds is set
   to hello_e + hello_now.



Ott, et. al.                 Informational                     [Page 22]

RFC 3259          A Message Bus for Local Coordination        April 2002


8.1.2  Initialization of Values

   Upon joining an Mbus session a protocol implementation sets
   hello_p=0, hello_now=0 and entities=1, entities_p=1 (the Mbus entity
   itself) and then calculates the time for the next hello message as
   specified in Section 8.1.1.  The next hello message is scheduled for
   transmission at hello_n.

8.1.3  Adjusting the Hello Message Interval when the Number of Entities
       increases

   When the existence of a new entity is observed by a protocol
   implementation the number of currently known entities is updated.  No
   further action concerning the calculation of the hello message
   interval is required.  The reconsideration of the timer interval
   takes place when the current timer for the next hello message expires
   (see Section 8.1.5).

8.1.4  Adjusting the Hello Message Interval when the Number of Entities
       decreases

   Upon realizing that an entity has left the Mbus the number of
   currently known entities is updated and the following algorithm
   should be used to reconsider the timer interval for hello messages:

   1. The value for hello_n is updated by setting hello_n = hello_now +
      (entities/entities_p)*(hello_n - hello_now)

   2. The value for hello_p is updated by setting hello_p = hello_now -
      (entities/entities_p)*(hello_now - hello_p)