rfc1001.txt

NBTSTAT 获取 MAC GROUP

   Session Service primitives are:

      1)   Call

           Initiate a session with a process that is listening under
           the specified name.  The calling entity must indicate both a
           calling name (properly registered to the caller) and a
           called name.

      2)   Listen

           Accept a session from a caller.  The listen primitive may be
           constrained to accept an incoming call from a named caller.
           Alternatively, a call may be accepted from any caller.

      3)   Hang Up

           Gracefully terminate a session.  All pending data is
           transferred before the session is terminated.

      4)   Send

           Transmit one message.  A time-out can occur.  A time-out of
           any session send forces the non-graceful termination of the
           session.



NetBIOS Working Group                                          [Page 12]

RFC 1001                                                      March 1987


           A "chain send" primitive is required by the PC NetBIOS
           software interface to allow a single message to be gathered
           from pieces in various buffers.  Chain Send is an interface
           detail and does not effect the protocol.

      5)   Receive

           Receive data.  A time-out can occur.  A time-out on a
           session receive only terminates the receive, not the
           session, although the data is lost.

           The receive primitive may be implemented with variants, such
           as "Receive Any", which is required by the PC NetBIOS
           software interface.  Receive Any is an interface detail and
           does not effect the protocol.

      6)   Session Status

           Obtain information about all of the requestor's sessions,
           under the specified name.  No network activity is involved.

5.4.  DATAGRAM SERVICE

   The Datagram service is an unreliable, non-sequenced, connectionless
   service.  Datagrams are sent under cover of a name properly
   registered to the sender.

   Datagrams may be sent to a specific name or may be explicitly
   broadcast.

   Datagrams sent to an exclusive name are received, if at all, by the
   holder of that name.  Datagrams sent to a group name are multicast to
   all holders of that name.  The sending application program cannot
   distinguish between group and unique names and thus must act as if
   all non-broadcast datagrams are multicast.

   As with the Session Service, the receiver of the datagram is told the
   sending and receiving names.

   Datagram Service primitives are:

      1)   Send Datagram

           Send an unreliable datagram to an application that is
           associated with the specified name.  The name may be unique
           or group; the sender is not aware of the difference.  If the
           name belongs to a group, then each member is to receive the
           datagram.






NetBIOS Working Group                                          [Page 13]

RFC 1001                                                      March 1987


      2)   Send Broadcast Datagram

           Send an unreliable datagram to any application with a
           Receive Broadcast Datagram posted.

      3)   Receive Datagram

           Receive a datagram sent by a specified originating name to
           the specified name.  If the originating name is an asterisk,
           then the datagram may have been originated under any name.

           Note: An arriving datagram will be delivered to all pending
           Receiving Datagrams that have source and destination
           specifications matching those of the datagram.  In other
           words, if a program (or group of programs) issue a series of
           identical Receive Datagrams, one datagram will cause the
           entire series to complete.

      4)   Receive Broadcast Datagram

           Receive a datagram sent as a broadcast.

           If there are multiple pending Receive Broadcast Datagram
           operations pending, all will be satisfied by the same
           received datagram.

5.5.  MISCELLANEOUS FUNCTIONS

   The following functions are present to control the operation of the
   hardware interface to the network.  These functions are generally
   implementation dependent.

      1)   Reset

           Initialize the local network adapter.

      2)   Cancel

           Abort a pending NetBIOS request.  The successful cancel of a
           Send (or Chain Send) operation will terminate the associated
           session.

      3)   Adapter Status

           Obtain information about the local network adapter or of a
           remote adapter.

      4)   Unlink

           For use with Remote Program Load (RPL).  Unlink redirects
           the PC boot disk device back to the local disk.  See the



NetBIOS Working Group                                          [Page 14]

RFC 1001                                                      March 1987


           NetBIOS specification for further details concerning RPL and
           the Unlink operation (see page 2-35 in [2]).

      5)   Remote Program Load

           Remote Program Load (RPL) is not a NetBIOS function.  It is
           a NetBIOS application defined by IBM in their NetBIOS
           specification (see pages 2-80 through 2-82 in [2]).

5.6.  NON-STANDARD EXTENSIONS

   The IBM Token Ring implementation of NetBIOS has added at least one
   new user capability:

      1)    Find Name

           This function determines whether a given name has been
           registered on the network.

6.  NetBIOS FACILITIES SUPPORTED BY THIS STANDARD

   The protocol specified by this standard permits an implementer to
   provide all of the NetBIOS services as described in the IBM
   "Technical Reference PC Network"[2].

   The following NetBIOS facilities are outside the scope of this
   specification.  These are local implementation matters and do not
   impact interoperability:

     -  RESET
     -  SESSION STATUS
     -  UNLINK
     -  RPL (Remote Program Load)

7.  REQUIRED SUPPORTING SERVICE INTERFACES AND DEFINITIONS

   The protocols described in this RFC require service interfaces to the
   following:

     -  TCP[3,4]
     -  UDP[5]

   Byte ordering, addressing conventions (including addresses to be
   used for broadcasts and multicasts) are defined by the most
   recent version of:

     -  Assigned Numbers[6]


   Additional definitions and constraints are in:




NetBIOS Working Group                                          [Page 15]

RFC 1001                                                      March 1987


     -  IP[7]
     -  Internet Subnets[8,9,10]


8.  RELATED PROTOCOLS AND SERVICES

   The design of the protocols described in this RFC allow for the
   future incorporation of the following protocols and services.
   However, before this may occur, certain extensions may be required to
   the protocols defined in this RFC or to those listed below.

     -  Domain Name Service[11,12,13,14]
     -  Internet Group Multicast[15,16]

9.  NetBIOS SCOPE

   A "NetBIOS Scope" is the population of computers across which a
   registered NetBIOS name is known.  NetBIOS broadcast and multicast
   datagram operations must reach the entire extent of the NetBIOS
   scope.

   An internet may support multiple, non-intersecting NetBIOS Scopes.

   Each NetBIOS scope has a "scope identifier".  This identifier is a
   character string meeting the requirements of the domain name system
   for domain names.

   NOTE: Each implementation of NetBIOS-over-TCP must provide
         mechanisms to manage the scope identifier(s) to be used.

   Control of scope identifiers implies a requirement for additional
   NetBIOS interface capabilities.  These may be provided through
   extensions of the user service interface or other means (such as node
   configuration parameters.)  The nature of these extensions is not
   part of this specification.

10.  NetBIOS END-NODES

   End-nodes support NetBIOS service interfaces and contain
   applications.

   Three types of end-nodes are part of this standard:

     -  Broadcast ("B") nodes
     -  Point-to-point ("P") nodes
     -  Mixed mode ("M") nodes

   An IP address may be associated with only one instance of one of the
   above types.

   Without having preloaded name-to-address tables, NetBIOS participants



NetBIOS Working Group                                          [Page 16]

RFC 1001                                                      March 1987


   are faced with the task of dynamically resolving references to one
   another.  This can be accomplished with broadcast or mediated point-
   to-point communications.

   B nodes use local network broadcasting to effect a rendezvous with
   one or more recipients.  P and M nodes use the NetBIOS Name Server
   (NBNS) and the NetBIOS Datagram Distribution Server (NBDD) for this
   same purpose.

   End-nodes may be combined in various topologies.  No matter how
   combined, the operation of the B, P, and M nodes is not altered.

   NOTE: It is recommended that the administration of a NetBIOS
         scope avoid using both M and B nodes within the same scope.
         A NetBIOS scope should contain only B nodes or only P and M
         nodes.

10.1.  BROADCAST (B) NODES

   Broadcast (or "B") nodes communicate using a mix of UDP datagrams
   (both broadcast and directed) and TCP connections.  B nodes may
   freely interoperate with one another within a broadcast area.  A
   broadcast area is a single MAC-bridged "B-LAN".  (See Appendix A for
   a discussion of using Internet Group Multicasting as a means to
   extend a broadcast area beyond a single B-LAN.)

10.2.  POINT-TO-POINT (P) NODES

   Point-to-point (or "P") nodes communicate using only directed UDP
   datagrams and TCP sessions.  P nodes neither generate nor listen for
   broadcast UDP packets.  P nodes do, however, offer NetBIOS level
   broadcast and multicast services using capabilities provided by the
   NBNS and NBDD.

   P nodes rely on NetBIOS name and datagram distribution servers.
   These servers may be local or remote; P nodes operate the same in
   either case.

10.3.  MIXED MODE (M) NODES

   Mixed mode nodes (or "M") nodes are P nodes which have been given
   certain B node characteristics.  M nodes use both broadcast and
   unicast.  Broadcast is used to improve response time using the
   assumption that most resources reside on the local broadcast medium
   rather than somewhere in an internet.

   M nodes rely upon NBNS and NBDD servers.  However, M nodes may
   continue limited operation should these servers be temporarily
   unavailable.





NetBIOS Working Group                                          [Page 17]

RFC 1001                                                      March 1987


11.  NetBIOS SUPPORT SERVERS

   Two types of support servers are part of this standard:

     -  NetBIOS name server ("NBNS") nodes
     -  Netbios datagram distribution ("NBDD") nodes

   NBNS and NBDD nodes are invisible to NetBIOS applications and are