rfc3259.txt

RFC 的详细文档！

5.3  Command Syntax

   The header is followed by zero, one, or more, commands to be
   delivered to the Mbus entities indicated by the DestAddr field.  Each
   command consists of a command name that is followed by a list of
   zero, or more parameters and is terminated by a newline.

      command ( parameter parameter ... )

   Syntactically, the command name MUST be a `symbol' as defined in the
   following table.  The parameters MAY be any data type drawn from the
   following table:

      val             = Integer / Float / String / List /
                        Symbol / Data

      Integer         = *1"-" 1*DIGIT

      Float           = *1"-" 1*DIGIT "." 1*DIGIT

      String          = DQUOTE *CHAR DQUOTE
                        ; see below for escape characters

      List            = "(" *WSP *1(val *(1*WSP val)) *WSP ")"

      Symbol          = ALPHA *(ALPHA / DIGIT / "_" / "-" /
                        ".")

      Data            = "<" *base64 ">"

   Boolean values are encoded as an integer, with the value of zero
   representing false, and non-zero representing true.






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


   String parameters in the payload MUST be enclosed in the double quote
   (") character.  Within strings, the escape character is the backslash
   (\), and the following escape sequences are defined:

      +----------------+-----------+
      |Escape Sequence |  Meaning  |
      +----------------+-----------+
      |      \\        |    \      |
      |      \"        |     "     |
      |      \n        | newline   |
      +----------------+-----------+

   List parameters do not have to be homogeneous lists, i.e., they can
   contain parameters of different types.

   Opaque data is represented as Base64-encoded (see RFC 1521 [7])
   character strings surrounded by "< " and "> "

   The ABNF syntax definition for Mbus commands is as follows:

      mbus_command = command_name arglist

      command_name = Symbol

      arglist      = List

   Command names SHOULD be constructed hierarchically to group
   conceptually related commands under a common hierarchy.  The
   delimiter between names in the hierarchy MUST be "."  (dot).
   Application profiles MUST NOT define commands starting with "mbus.".

   The Mbus addressing scheme defined in Section 4 allows specifying
   incomplete addresses by omitting certain elements of an address
   element list, enabling entities to send commands to a group of Mbus
   entities.  Therefore, all command names SHOULD be unambiguous in a
   way that it is possible to interpret or ignore them without
   considering the message's address.

   A set of commands within a certain hierarchy that MUST be understood
   by every entity is defined in Section 9.

6.  Transport

   All messages are transmitted as UDP messages, with two possible
   alternatives:






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


   1. Local multicast/broadcast:
      This transport class MUST be used for all messages that are not
      sent to a fully qualified target address.  It MAY also be used for
      messages that are sent to a fully qualified target address.  It
      MUST be provided by conforming implementations.  See Section 6.1
      for details.

   2. Directed unicast:
      This transport class MAY be used for messages that are sent to a
      fully qualified destination address.  It is OPTIONAL and does not
      have to be provided by conforming implementations.

   A fully qualified target address is an Mbus address of an existing
   Mbus entity in an Mbus session. An implementation can identify an
   Mbus address as fully qualified by maintaining a list of known
   entities within an Mbus session. Each known entity has its own
   unique, fully qualified Mbus address.

   Messages are transmitted in UDP datagrams, a maximum message size of
   64 KBytes MUST NOT be exceeded.  It is RECOMMENDED that applications
   using a non host-local scope do not exceed a message size of the link
   MTU.

   Note that "unicast", "multicast" and "broadcast" mean IP Unicast, IP
   Multicast and IP Broadcast respectively.  It is possible to send an
   Mbus message that is addressed to a single entity using IP Multicast.

   This specification deals with both Mbus over UDP/IPv4 and Mbus over
   UDP/IPv6.

6.1  Local Multicast/Broadcast

   In general, the Mbus uses multicast with a limited scope for message
   transport.  Two different Mbus multicast scopes are defined, either
   of which can be configured to be used with an Mbus session:

   1.  host-local

   2.  link-local

   Participants of an Mbus session have to know the multicast address in
   advance -- it cannot be negotiated during the session since it is
   already needed for initial communication between the Mbus entities
   during the bootstrapping phase.  It also cannot be allocated prior to
   an Mbus session because there would be no mechanism to announce the
   allocated address to all potential Mbus entities.  Therefore, the
   multicast address has to be assigned statically.  This document
   defines the use of statically assigned addresses and also provides a



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


   specification of how an Mbus session can be configured to use non-
   standard, unassigned addresses (see Section 12).

   The following sections specify the use of multicast addresses for
   IPv4 and IPv6.

6.1.1  Mbus multicast groups for IPv4

   For IPv4, a statically assigned, scope-relative multicast address as
   defined by RFC 2365 [11] is used.  The offset for the scope relative
   address for Mbus is 8 (MBUS, see
   http://www.iana.org/assignments/multicast-addresses [19]).

   Different scopes are defined by RFC 2365 [11].  The IPv4 Local Scope
   (239.255.0.0/16) is the minimal enclosing scope for administratively
   scoped multicast (as defined by RFC 2365 [11]) and not further
   divisible -- its exact extent is site dependent.

   For the IPv4 Local Scope, applying the rules of RFC 2365 [11] and
   using the assigned offset of 8, the Mbus multicast address is
   therefore 239.255.255.247.

   For IPv4, the different defined Mbus scopes (host-local and link-
   local) are to be realized as follows:

   host-local multicast: Unless configured otherwise, the assigned
      scope-relative Mbus address in the Local Scope (239.255.255.247 as
      of RFC 2365 [11]) MUST be used.  Mbus UDP datagrams SHOULD be sent
      with a TTL of 0.

   link-local multicast: Unless configured otherwise, the assigned
      scope-relative Mbus address in the Local Scope (239.255.255.247 as
      of RFC 2365 [11]) MUST be used.  Mbus UDP datagrams SHOULD be sent
      with a TTL of 1.

6.1.2  Mbus multicast groups for IPv6

   IPv6 has different address ranges for different multicast scopes and
   distinguishes node local and link local scopes, that are implemented
   as a set of address prefixes for the different address ranges (RFC
   2373 [3]).  The link-local prefix is FF02, the node-local prefix is
   FF01.  A permanently assigned multicast address will be used for Mbus
   multicast communication, i.e., an address that is independent of the
   scope value and that can be used for all scopes.  Implementations for
   IPv6 MUST use the scope-independent address and the appropriate
   prefix for the selected scope.  For host-local Mbus communication the
   IPv6 node-local scope prefix MUST be used, for link-local Mbus
   communication the IPv6 link-local scope prefix MUST be used.



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


   The permanent IPv6 multicast address for Mbus/Ipv6 is
   FF0X:0:0:0:0:0:0:300.

   FF0X:0:0:0:0:0:0:300 SHOULD be used for Mbus/IPv6 where the X in FF0X
   indicates that the scope is not fixed because this is an all scope
   address.  This means, for node-local scope, FF01:0:0:0:0:0:0:300
   SHOULD be used and for link-local scope FF02:0:0:0:0:0:0:300 SHOULD
   be used.  See RFC 2375 [4] for IPv6 multicast address assignments.

   If a single application system is distributed across several co-
   located hosts, link local scope SHOULD be used for multicasting Mbus
   messages that potentially have recipients on the other hosts.  The
   Mbus protocol is not intended (and hence deliberately not designed)
   for communication between hosts not on the same link.  See Section 12
   for specifications of Mbus configuration mechanisms.

6.1.3  Use of Broadcast

   In situations where multicast is not available, broadcast MAY be used
   instead.  In these cases an IP broadcast address for the connected
   network SHOULD be used for sending.  The node-local broadcast address
   for IPv6 is FF01:0:0:0:0:0:0:1, the link-local broadcast address for
   IPv6 is FF02:0:0:0:0:0:0:1.  For IPv4, the generic broadcast address
   (for link-local broadcast) is 255.255.255.255.  It is RECOMMENDED
   that IPv4-implementations use the generic broadcast address and a TTL
   of zero for host-local broadcast.

   Broadcast MUST NOT be used in situations where multicast is available
   and supported by all systems participating in an Mbus session.

   See Section 12 for configuring the use of broadcast.

6.1.4  Mbus UDP Port Number

   The registered Mbus UDP port number is 47000.

6.2  Directed Unicast

   Directed unicast (via UDP) to the port of a specific application is
   an alternative transport class to multicast.  Directed unicast is an
   OPTIONAL optimization and MAY be used by Mbus implementations for
   delivering messages addressed to a single application entity only --
   the address of which the Mbus implementation has learned from other
   message exchanges before.  Note that the DestAddr field of such
   messages MUST be filled in properly nevertheless.  Every Mbus entity
   SHOULD use a single unique endpoint address for sending messages to
   the Mbus multicast group or to individual receiving entities.  A




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


   unique endpoint address is a tuple consisting of the entity's IP
   address and a UDP source port number, where the port number is
   different from the standard Mbus port number.

   Messages MUST only be sent via unicast if the Mbus target address is
   unique and if the sending entity can verify that the receiving entity
   uses a unique endpoint address.  The latter can be verified by
   considering the last message received from that entity.

      Note that several Mbus entities, say within the same process, may
      share a common transport address; in this case, the contents of
      the destination address field is used to further dispatch the
      message.  Given the definition of "unique endpoint address" above,
      the use of a shared endpoint address and a dispatcher still allows
      other Mbus entities to send unicast messages to one of the
      entities that share the endpoint address.  So this can be
      considered an implementation detail.

   Messages with an empty target address list MUST always be sent to all
   Mbus entities (via multicast if available).

   The following algorithm can be used by sending entities to determine
   whether an Mbus address is unique considering the current set of Mbus
   entities:

         let ta=the target address;
         iterate through the set of all
         currently known Mbus addresses {
            let ti=the address in each iteration;
            count the addresses for which
            the predicate isSubsetOf(ta,ti) yields true;
         }

      If the count of matching addresses is exactly 1 the address is
      unique.  The following algorithm can be used for the predicate
      isSubsetOf, that checks whether the second message matches the
      first according to the rules specified in Section 4.  (A match
      means that a receiving entity that uses the second Mbus address
      must also process received messages with the first address as a
      target address.)

         isSubsetOf(addr a1,a2) yields true, iff
            every address element of a1 is contained
            in a2's address element list.