rfc3259.txt

RFC 的详细文档！

   3. The currently active timer for the next hello messages is
      cancelled and a new timer is started for hello_n.

   4. entities_p is set to entities.

8.1.5 Expiration of hello timers

   When the hello message timer expires, the protocol implementation
   MUST perform the following operations:

      The hello interval hello_e is computed as specified in Section
      8.1.1.

      1. IF hello_e + hello_p <= hello_now THEN a hello message is
         transmitted.  hello_p is set to hello_now, hello_e is
         calculated again as specified in Section 8.1.1 and hello_n is
         set to hello_e + hello_now.



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


      2. ELSE IF hello_e + hello_p > hello_now THEN hello_n is set to
         hello_e + hello_p.  A new timer for the next hello message is
         started to expire at hello_n.  No hello message is transmitted.

      entities_p is set to entities.

8.2  Calculating the Timeout for Mbus Entities

   Whenever an Mbus entity has not heard for a time span of
   c_hello_dead*(hello_d*c_hello_dither_max) milliseconds from another
   Mbus entity it may consider this entity to have failed (or have quit
   silently).  The number of the currently known entities MUST be
   updated accordingly.  See Section 8.1.4 for details.  Note that no
   need for any further action is necessarily implied from this
   observation.

   Section 8.1.1 specifies how to obtain hello_d.  Section 10 defines
   values for the constants c_hello_dead and c_hello_dither_max.

9.  Messages

   This section defines some basic application-independent messages that
   MUST be understood by all implementations; these messages are
   required for proper operation of the Mbus.  This specification does
   not contain application-specific messages. These are to be defined
   outside of the basic Mbus protocol specification in separate Mbus
   profiles.

9.1  mbus.hello

      Syntax:
      mbus.hello()

      Parameters: - none -

   mbus.hello messages MUST be sent unreliably to all Mbus entities.

   Each Mbus entity learns about other Mbus entities by observing their
   mbus.hello messages and tracking the sender address of each message
   and can thus calculate the current number of entities.

   mbus.hello messages MUST be sent periodically in dynamically
   calculated intervals as specified in Section 8.

   Upon startup the first mbus.hello message MUST be sent after a delay
   hello_delay, where hello_delay be a randomly chosen number between 0
   and c_hello_min (see Section 10).




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


9.2  mbus.bye

      Syntax:  mbus.bye()

      Parameters: - none -

   An Mbus entity that is about to terminate (or "detach" from the Mbus)
   SHOULD announce this by transmitting an mbus.bye message.  The
   mbus.bye message MUST be sent unreliably to all entities.

9.3  mbus.ping

      Syntax:  mbus.ping()

      Parameters: - none -

   mbus.ping can be used to solicit other entities to signal their
   existence by replying with an mbus.hello message.  Each protocol
   implementation MUST understand mbus.ping and reply with an mbus.hello
   message.  The reply hello message MUST be delayed for hello_delay
   milliseconds, where hello_delay be a randomly chosen number between 0
   and c_hello_min (see Section 10).  Several mbus.ping messages MAY be
   answered by a single mbus.hello: if one or more further mbus.ping
   messages are received while the entity is waiting hello_delay time
   units before transmitting the mbus.hello message, no extra mbus.hello
   message need be scheduled for those additional mbus.ping messages.

   As specified in Section 9.1 hello messages MUST be sent unreliably to
   all Mbus entities.  This is also the case for replies to ping
   messages.  An entity that replies to mbus.ping with mbus.hello SHOULD
   stop any outstanding timers for hello messages after sending the
   hello message and schedule a new timer event for the subsequent hello
   message.  (Note that using the variables and the algorithms of
   Section 8.1.1 this can be achieved by setting hello_p to hello_now.)

   mbus.ping allows a new entity to quickly check for other entities
   without having to wait for the regular individual hello messages.  By
   specifying a target address the new entity can restrict the
   solicitation for hello messages to a subset of entities it is
   interested in.











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


9.4  mbus.quit

      Syntax:
      mbus.quit()

      Parameters: - none -

   The mbus.quit message is used to request other entities to terminate
   themselves (and detach from the Mbus).  Whether this request is
   honoured by receiving entities or not is application specific and
   not defined in this document.

   The mbus.quit message can be multicast or sent reliably via unicast
   to a single Mbus entity or a group of entities.

9.5  mbus.waiting

      Syntax:
      mbus.waiting(condition)

      Parameters:

         symbol condition
         The condition parameter is used to indicate that the entity
         transmitting this message is waiting for a particular event to
         occur.

   An Mbus entity SHOULD be able to indicate that it is waiting for a
   certain event to happen (similar to a P() operation on a semaphore
   but without creating external state somewhere else).  In conjunction
   with this, an Mbus entity SHOULD be capable of indicating to another
   entity that this condition is now satisfied (similar to a semaphore's
   V() operation).

   The mbus.waiting message MAY be broadcast to all Mbus entities, MAY
   be multicast to an arbitrary subgroup, or MAY be unicast to a
   particular peer.  Transmission of the mbus.waiting message MUST be
   unreliable and hence MUST be repeated at an application-defined
   interval (until the condition is satisfied).

   If an application wants to indicate that it is waiting for several
   conditions to be met, several mbus.waiting messages are sent
   (possibly included in the same Mbus payload).  Note that mbus.hello
   and mbus.waiting messages may also be transmitted in a single Mbus
   payload.






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


9.6  mbus.go

      Syntax:
      mbus.go(condition)

      Parameters:

         symbol condition
         This parameter specifies which condition is met.

   The mbus.go message is sent by an Mbus entity to "unblock" another
   Mbus entity -- which has indicated that it is waiting for a certain
   condition to be met.  Only a single condition can be specified per
   mbus.go message.  If several conditions are satisfied simultaneously
   multiple mbus.go messages MAY be combined in a single Mbus payload.

   The mbus.go message MUST be sent reliably via unicast to the Mbus
   entity to unblock.

10.  Constants

   The following values for timers and counters mentioned in this
   document SHOULD be used by implementations:

      +-------------------+------------------------+--------------+
      |Timer / Counter    | Value                  | Unit         |
      +-------------------+------------------------+--------------+
      |c_hello_factor     | 200                    |     -        |
      |c_hello_min        | 1000                   | milliseconds |
      |c_hello_dither_min | 0.9                    |     -        |
      |c_hello_dither_max | 1.1                    |     -        |
      |c_hello_dead       | 5                      |     -        |
      +-------------------+------------------------+--------------+

         T_r=100ms

         N_r=3

         T_c=70ms

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










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


11.  Mbus Security

11.1  Security Model

   In order to prevent accidental or malicious disturbance of Mbus
   communications through messages originated by applications from other
   users, message authentication is deployed (Section 11.3).  For each
   message, a digest MUST be calculated based on the value of a shared
   secret key value.  Receivers of messages MUST check if the sender
   belongs to the same Mbus security domain by re-calculating the digest
   and comparing it to the received value.  The messages MUST only be
   processed further if both values are equal.  In order to allow
   different simultaneous Mbus sessions at a given scope and to
   compensate defective implementations of host local multicast, message
   authentication MUST be provided by conforming implementations.

   Privacy of Mbus message transport can be achieved by optionally using
   symmetric encryption methods (Section 11.2).  Each message MAY be
   encrypted using an additional shared secret key and a symmetric
   encryption algorithm.  Encryption is OPTIONAL for applications, i.e.,
   it is allowed to configure an Mbus domain not to use encryption.  But
   conforming implementations MUST provide the possibility to use
   message encryption (see below).

   Message authentication and encryption can be parameterized: the
   algorithms to apply, the keys to use, etc.  These and other
   parameters are defined in an Mbus configuration object that is
   accessible by all Mbus entities that participate in an Mbus session.
   In order to achieve interoperability conforming implementations
   SHOULD use the values provided by such an Mbus configuration.
   Section 12 defines the mandatory and optional parameters as well as
   storage procedures for different platforms.  Only in cases where none
   of the options mentioned in Section 12 is applicable alternative
   methods of configuring Mbus protocol entities MAY be deployed.

   The algorithms and procedures for applying encryption and
   authentication techniques are specified in the following sections.

11.2  Encryption

   Encryption of messages is OPTIONAL, that means, an Mbus MAY be
   configured not to use encryption.









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


   Implementations can choose between different encryption algorithms.
   Every conforming implementation MUST provide the AES [18] algorithm.
   In addition, the following algorithms SHOULD be supported: DES [16],
   3DES (triple DES) [16] and IDEA [20].

   For algorithms requiring en/decryption data to be padded to certain
   boundaries octets with a value of 0 SHOULD be used for padding
   characters.

   The length of the encryption keys is determined by the currently used
   encryption algorithm.