rfc1001.txt

NBTSTAT 获取 MAC GROUP

   responses.



NetBIOS Working Group                                          [Page 23]

RFC 1001                                                      March 1987


   In no case, however, is more than one response generated for a
   received request.  While a response is pending the responding entity
   may send one or more wait acknowledgements.

13.1.1.  RETRANSMISSION OF REQUESTS

   UDP is an unreliable delivery mechanism where packets can be lost,
   received out of transmit sequence, duplicated and delivery can be
   significantly delayed.  Since the NetBIOS protocols make heavy use of
   UDP, they have compensated for its unreliability with extra
   mechanisms.

   Each NetBIOS packet contains all the necessary information to process
   it.  None of the protocols use multiple UDP packets to convey a
   single request or response.  If more information is required than
   will fit in a single UDP packet, for example, when a P-type node
   wants all the owners of a group name from a NetBIOS server, a TCP
   connection is used.  Consequently, the NetBIOS protocols will not
   fail because of out of sequence delivery of UDP packets.

   To overcome the loss of a request or response packet, each request
   operation will retransmit the request if a response is not received
   within a specified time limit.

   Protocol operations sensitive to successive response packets, such as
   name conflict detection, are protected from duplicated packets
   because they ignore successive packets with the same NetBIOS
   information.  Since no state on the responder's node is associated
   with a request, the responder just sends the appropriate response
   whenever a request packet arrives.  Consequently, duplicate or
   delayed request packets have no impact.

   For all requests, if a response packet is delayed too long another
   request packet will be transmitted.  A second response packet being
   sent in response to the second request packet is equivalent to a
   duplicate packet.  Therefore, the protocols will ignore the second
   packet received.  If the delivery of a response is delayed until
   after the request operation has been completed, successfully or not,
   the response packet is ignored.

13.1.2.  REQUESTS WITHOUT RESPONSES: DEMANDS

   Some request types do not have matching responses.  These requests
   are known as "demands".  In general a "demand" is an imperative
   request; the receiving node is expected to obey.  However, because
   demands are unconfirmed, they are used only in situations where, at
   most, limited damage would occur if the demand packet should be lost.

   Demand packets are not retransmitted.





NetBIOS Working Group                                          [Page 24]

RFC 1001                                                      March 1987


13.2.  TRANSACTIONS

   Interactions between a pair of entities are grouped into
   "transactions".  These transactions comprise one or more
   request/response pairs.

13.2.1.  TRANSACTION ID

   Since multiple simultaneous transactions may be in progress between a
   pair of entities a "transaction id" is used.

   The originator of a transaction selects an ID unique to the
   originator.  The transaction id is reflected back and forth in each
   interaction within the transaction.  The transaction partners must
   match responses and requests by comparison of the transaction ID and
   the IP address of the transaction partner.  If no matching request
   can be found the response must be discarded.

   A new transaction ID should be used for each transaction.  A simple
   16 bit transaction counter ought to be an adequate id generator.  It
   is probably not necessary to search the space of outstanding
   transaction ID to filter duplicates: it is extremely unlikely that
   any transaction will have a lifetime that is more than a small
   fraction of the typical counter cycle period.  Use of the IP
   addresses in conjunction with the transaction ID further reduces the
   possibility of damage should transaction IDs be prematurely re-used.

13.3.  TCP AND UDP FOUNDATIONS

   This version of the NetBIOS-over-TCP protocols uses UDP for many
   interactions.  In the future this RFC may be extended to permit such
   interactions to occur over TCP connections (perhaps to increase
   efficiency when multiple interactions occur within a short time or
   when NetBIOS datagram traffic reveals that an application is using
   NetBIOS datagrams to support connection- oriented service.)

14.  REPRESENTATION OF NETBIOS NAMES

   NetBIOS names as seen across the client interface to NetBIOS are
   exactly 16 bytes long.  Within the NetBIOS-over-TCP protocols, a
   longer representation is used.

   There are two levels of encoding.  The first level maps a NetBIOS
   name into a domain system name.  The second level maps the domain
   system name into the "compressed" representation required for
   interaction with the domain name system.

   Except in one packet, the second level representation is the only
   NetBIOS name representation used in NetBIOS-over-TCP packet formats.
   The exception is the RDATA field of a NODE STATUS RESPONSE packet.




NetBIOS Working Group                                          [Page 25]

RFC 1001                                                      March 1987


14.1.  FIRST LEVEL ENCODING

   The first level representation consists of two parts:

     -  NetBIOS name
     -  NetBIOS scope identifier

   The 16 byte NetBIOS name is mapped into a 32 byte wide field using a
   reversible, half-ASCII, biased encoding.  Each half-octet of the
   NetBIOS name is encoded into one byte of the 32 byte field.  The
   first half octet is encoded into the first byte, the second half-
   octet into the second byte, etc.

   Each 4-bit, half-octet of the NetBIOS name is treated as an 8-bit,
   right-adjusted, zero-filled binary number.  This number is added to
   value of the ASCII character 'A' (hexidecimal 41).  The resulting 8-
   bit number is stored in the appropriate byte.  The following diagram
   demonstrates this procedure:


                         0 1 2 3 4 5 6 7
                        +-+-+-+-+-+-+-+-+
                        |a b c d|w x y z|          ORIGINAL BYTE
                        +-+-+-+-+-+-+-+-+
                            |       |
                   +--------+       +--------+
                   |                         |     SPLIT THE NIBBLES
                   v                         v
            0 1 2 3 4 5 6 7           0 1 2 3 4 5 6 7
           +-+-+-+-+-+-+-+-+         +-+-+-+-+-+-+-+-+
           |0 0 0 0 a b c d|         |0 0 0 0 w x y z|
           +-+-+-+-+-+-+-+-+         +-+-+-+-+-+-+-+-+
                   |                         |
                   +                         +     ADD 'A'
                   |                         |
            0 1 2 3 4 5 6 7           0 1 2 3 4 5 6 7
           +-+-+-+-+-+-+-+-+         +-+-+-+-+-+-+-+-+
           |0 1 0 0 0 0 0 1|         |0 1 0 0 0 0 0 1|
           +-+-+-+-+-+-+-+-+         +-+-+-+-+-+-+-+-+

   This encoding results in a NetBIOS name being represented as a
   sequence of 32 ASCII, upper-case characters from the set
   {A,B,C...N,O,P}.

   The NetBIOS scope identifier is a valid domain name (without a
   leading dot).

   An ASCII dot (2E hexidecimal) and the scope identifier are appended
   to the encoded form of the NetBIOS name, the result forming a valid
   domain name.




NetBIOS Working Group                                          [Page 26]

RFC 1001                                                      March 1987


   For example, the NetBIOS name "The NetBIOS name" in the NetBIOS scope
   "SCOPE.ID.COM" would be represented at level one by the ASCII
   character string:

        FEGHGFCAEOGFHEECEJEPFDCAHEGBGNGF.SCOPE.ID.COM

14.2.  SECOND LEVEL ENCODING

   The first level encoding must be reduced to second level encoding.
   This is performed according to the rules defined in on page 31 of RFC
   883[12] in the section on "Domain name representation and
   compression".  Also see the section titled "Name Formats" in the
   Detailed Specifications[1].

15.  NetBIOS NAME SERVICE

   Before a name may be used, the name must be registered by a node.
   Once acquired, the name must be defended against inconsistent
   registration by other nodes.  Before building a NetBIOS session or
   sending a NetBIOS datagram, the one or more holders of the name must
   be located.

   The NetBIOS name service is the collection of procedures through
   which nodes acquire, defend, and locate the holders of NetBIOS names.

   The name service procedures are different depending whether the end-
   node is of type B, P, or M.

15.1.  OVERVIEW OF NetBIOS NAME SERVICE

15.1.1.  NAME REGISTRATION (CLAIM)

   Each NetBIOS node can own more than one name.  Names are acquired
   dynamically through the registration (name claim) procedures.

   Every node has a permanent unique name.  This name, like any other
   name, must be explicitly registered by all end-node types.

   A name can be unique (exclusive) or group (non-exclusive).  A unique
   name may be owned by a single node; a group name may be owned by any
   number of nodes.  A name ceases to exist when it is not owned by at
   least one node.  There is no intrinsic quality of a name which
   determines its characteristics: these are established at the time of
   registration.

   Each node maintains state information for each name it has
   registered.  This information includes:

     -  Whether the name is a group or unique name
     -  Whether the name is "in conflict"
     -  Whether the name is in the process of being deleted



NetBIOS Working Group                                          [Page 27]

RFC 1001                                                      March 1987


   B nodes perform name registration by broadcasting claim requests,
   soliciting a defense from any node already holding the name.

   P nodes perform name registration through the agency of the NBNS.

   M nodes register names through an initial broadcast, like B nodes,
   then, in the absence of an objection, by following the same
   procedures as a P node.  In other words, the broadcast action may
   terminate the attempt, but is not sufficient to confirm the
   registration.

15.1.2.  NAME QUERY (DISCOVERY)

   Name query (also known as "resolution" or "discovery") is the
   procedure by which the IP address(es) associated with a NetBIOS name
   are discovered.  Name query is required during the following
   operations:

   During session establishment, calling and called names must be
   specified.  The calling name must exist on the node that posts the
   CALL.  The called name must exist on a node that has previously
   posted a LISTEN.  Either name may be a unique or group name.

   When a directed datagram is sent, a source and destination name must
   be specified.  If the destination name is a group name, a datagram is
   sent to all the members of that group.

   Different end-node types perform name resolution using different
   techniques, but using the same packet formats:

     -  B nodes solicit name information by broadcasting a request.

     -  P nodes ask the NBNS.

     -  M nodes broadcast a request.  If that does not provide the
        desired information, an inquiry is sent to the NBNS.

15.1.3.  NAME RELEASE

   NetBIOS names may be released explicitly or silently by an end- node.
   Silent release typically occurs when an end-node fails or is turned-
   off.  Most of the mechanisms described below are present to detect
   silent name release.

15.1.3.1.  EXPLICIT RELEASE

   B nodes explicitly release a name by broadcasting a notice.

   P nodes send a notification to their NBNS.

   M nodes both broadcast a notice and inform their supporting NBNS.



NetBIOS Working Group                                          [Page 28]

RFC 1001                                                      March 1987


15.1.3.2.  NAME LIFETIME AND REFRESH

   Names held by an NBNS are given a lifetime during name registration.
   The NBNS will consider a name to have been silently released if the
   end-node fails to send a name refresh message to the NBNS before the
   lifetime expires.  A refresh restarts the lifetime clock.

   NOTE: The implementor should be aware of the tradeoff between
         accuracy of the database and the internet overhead that the
         refresh mechanism introduces.  The lifetime period should
         be tuned accordingly.


   For group names, each end-node must send refresh messages.  A node
   that fails to do so will be considered to have silently released the
   name and dropped from the group.

   The lifetime period is established through a simple negotiation
   mechanism during name registration:  In the name registration
   request, the end-node proposes a lifetime value or requests an
   infinite lifetime.  The NBNS places an actual lifetime value into the
   name registration response.  The NBNS is always allowed to respond
   with an infinite actual period.  If the end node proposed an infinite
   lifetime, the NBNS may respond with any definite period.  If the end
   node proposed a definite period, the NBNS may respond with any
   definite period greater than or equal to that proposed.

   This negotiation of refresh times gives the NBNS means to disable or
   enable refresh activity.  The end-nodes may set a minimum refresh
   cycle period.

   NBNS implementations wh