rfc1001.txt

<VC++网络游戏建摸与实现>源代码

NetBIOS Working Group                                           [Page 6]

RFC 1001                                                      March 1987


3.  INTRODUCTION

   This RFC describes the ideas and general methods used to provide
   NetBIOS on a TCP and UDP foundation.  A companion RFC, "Protocol
   Standard For a NetBIOS Service on a TCP/UDP Transport: Detailed
   Specifications"[1] contains detailed descriptions of packet
   formats, protocols, and defined constants and variables.

   The NetBIOS service has become the dominant mechanism for
   personal computer networking.  NetBIOS provides a vendor
   independent interface for the IBM Personal Computer (PC) and
   compatible systems.

   NetBIOS defines a software interface not a protocol.  There is no
   "official" NetBIOS service standard.  In practice, however, the
   IBM PC-Network version is used as a reference.  That version is
   described in the IBM document 6322916, "Technical Reference PC
   Network"[2].

   Protocols supporting NetBIOS services have been constructed on
   diverse protocol and hardware foundations.  Even when the same
   foundation is used, different implementations may not be able to
   interoperate unless they use a common protocol.  To allow NetBIOS
   interoperation in the Internet, this RFC defines a standard
   protocol to support NetBIOS services using TCP and UDP.

   NetBIOS has generally been confined to personal computers to
   date.  However, since larger computers are often well suited to
   run certain NetBIOS applications, such as file servers, this
   specification has been designed to allow an implementation to be
   built on virtually any type of system where the TCP/IP protocol
   suite is available.

   This standard defines a set of protocols to support NetBIOS
   services.

   These protocols are more than a simple communications service
   involving two entities.  Rather, this note describes a
   distributed system in which many entities play a part even if
   they are not involved as an end-point of a particular NetBIOS
   connection.

   This standard neither constrains nor determines how those
   services are presented to application programs.

   Nevertheless, it is expected that on computers operating under
   the PC-DOS and MS-DOS operating systems that the existing NetBIOS
   interface will be preserved by implementors.

   NOTE: Various symbolic values are used in this document.  For
         their definitions, refer to the Detailed Specifications[1].



NetBIOS Working Group                                           [Page 7]

RFC 1001                                                      March 1987


4.  DESIGN PRINCIPLES

   In order to develop the specification the following design principles
   were adopted to guide the effort.  Most are typical to any protocol
   standardization effort; however, some have been assigned priorities
   that may be considered unusual.

4.1.  PRESERVE NetBIOS SERVICES

   In the absence of an "official" standard for NetBIOS services, the
   version found in the IBM PC Network Technical Reference[2] is used.

   NetBIOS is the foundation of a large body of existing applications.
   It is desirable to operate these applications on TCP networks and to
   extend them beyond personal computers into larger hosts.  To support
   these applications, NetBIOS on TCP must closely conform to the
   services offered by existing NetBIOS systems.

   IBM PC-Network NetBIOS contains some implementation specific
   characteristics.  This standard does not attempt to completely
   preserve these.  It is certain that some existing software requires
   these characteristics and will fail to operate correctly on a NetBIOS
   service based on this RFC.

4.2.  USE EXISTING STANDARDS

   Protocol development, especially with standardization, is a demanding
   process.  The development of new protocols must be minimized.

   It is considered essential that an existing standard which provides
   the necessary functionality with reasonable performance always be
   chosen in preference to developing a new protocol.

   When a standard protocol is used, it must be unmodified.

4.3.  MINIMIZE OPTIONS

   The standard for NetBIOS on TCP should contain few, if any, options.

   Where options are included, the options should be designed so that
   devices with different option selections should interoperate.

4.4.  TOLERATE ERRORS AND DISRUPTIONS

   NetBIOS networks typically operate in an uncontrolled environment.
   Computers come on-line at arbitrary times.  Computers usually go
   off-line without any notice to their peers.  The software is often
   operated by users who are unfamiliar with networks and who may
   randomly perturb configuration settings.

   Despite this chaos, NetBIOS networks work.  NetBIOS on TCP must also



NetBIOS Working Group                                           [Page 8]

RFC 1001                                                      March 1987


   be able to operate well in this environment.

   Robust operation does not necessarily mean that the network is proof
   against all disruptions.  A typical NetBIOS network may be disrupted
   by certain types of behavior, whether inadvertent or malicious.

4.5.  DO NOT REQUIRE CENTRAL MANAGEMENT

   NetBIOS on TCP should be able to operate, if desired, without
   centralized management beyond that typically required by a TCP based
   network.

4.6.  ALLOW INTERNET OPERATION

   The proposed standard recognizes the need for NetBIOS operation
   across a set of networks interconnected by network (IP) level relays
   (gateways.)

   However, the standard assumes that this form of operation will be
   less frequent than on the local MAC bridged-LAN.

4.7.  MINIMIZE BROADCAST ACTIVITY

   The standard pre-supposes that the only broadcast services are those
   supported by UDP.  Multicast capabilities are not assumed to be
   available in any form.

   Despite the availability of broadcast capabilities, the standard
   recognizes that some administrations may wish to avoid heavy
   broadcast activity.  For example, an administration may wish to avoid
   isolated non-participating hosts from the burden of receiving and
   discarding NetBIOS broadcasts.

4.8.  PERMIT IMPLEMENTATION ON EXISTING SYSTEMS

   The NetBIOS on TCP protocol should be implementable on common
   operating systems, such as Unix(tm) and VAX/VMS(tm), without massive
   effort.

   The NetBIOS protocols should not require services typically
   unavailable on presently existing TCP/UDP/IP implementations.

4.9.  REQUIRE ONLY THE MINIMUM NECESSARY TO OPERATE

   The protocol definition should specify only the minimal set of
   protocols required for interoperation.  However, additional protocol
   elements may be defined to enhance efficiency.  These latter elements
   may be generated at the option of the sender, although they must be
   accepted by all receivers.





NetBIOS Working Group                                           [Page 9]

RFC 1001                                                      March 1987


4.10.  MAXIMIZE EFFICIENCY

   To be useful, a protocol must conduct its business quickly.

4.11.  MINIMIZE NEW INVENTIONS

   When an existing protocol is not quite able to support a necessary
   function, but with a small amount of change, it could, that protocol
   should be used.  This is felt to be easier to achieve than
   development of new protocols; further, it is likely to have more
   general utility for the Internet.

5.  OVERVIEW OF NetBIOS

   This section describes the NetBIOS services.  It is for background
   information only.  The reader may chose to skip to the next section.

   NetBIOS was designed for use by groups of PCs, sharing a broadcast
   medium.  Both connection (Session) and connectionless (Datagram)
   services are provided, and broadcast and multicast are supported.
   Participants are identified by name.  Assignment of names is
   distributed and highly dynamic.

   NetBIOS applications employ NetBIOS mechanisms to locate resources,
   establish connections, send and receive data with an application
   peer, and terminate connections.  For purposes of discussion, these
   mechanisms will collectively be called the NetBIOS Service.

   This service can be implemented in many different ways.  One of the
   first implementations was for personal computers running the PC-DOS
   and MS-DOS operating systems.  It is possible to implement NetBIOS
   within other operating systems, or as processes which are,
   themselves, simply application programs as far as the host operating
   system is concerned.

   The NetBIOS specification, published by IBM as "Technical Reference
   PC Network"[2] defines the interface and services available to the
   NetBIOS user.  The protocols outlined by that document pertain only
   to the IBM PC Network and are not generally applicable to other
   networks.

5.1.  INTERFACE TO APPLICATION PROGRAMS

   NetBIOS on personal computers includes both a set of services and an
   exact program interface to those services.  NetBIOS on other computer
   systems may present the NetBIOS services to programs using other
   interfaces.  Except on personal computers, no clear standard for a
   NetBIOS software interface has emerged.






NetBIOS Working Group                                          [Page 10]

RFC 1001                                                      March 1987


5.2.  NAME SERVICE

   NetBIOS resources are referenced by name.  Lower-level address
   information is not available to NetBIOS applications.  An
   application, representing a resource, registers one or more names
   that it wishes to use.

   The name space is flat and uses sixteen alphanumeric characters.
   Names may not start with an asterisk (*).

   Registration is a bid for use of a name.  The bid may be for
   exclusive (unique) or shared (group) ownership.  Each application
   contends with the other applications in real time.  Implicit
   permission is granted to a station when it receives no objections.
   That is, a bid is made and the application waits for a period of
   time.  If no objections are received, the station assumes that it has
   permission.

   A unique name should be held by only one station at a time.  However,
   duplicates ("name conflicts") may arise due to errors.

   All instances of a group name are equivalent.

   An application referencing a name generally does not know (or care)
   whether the name is registered as a unique or a group name.

   An explicit name deletion function is specified, so that applications
   may remove a name.  Implicit name deletion occurs when a station
   ceases operation.  In the case of personal computers, implicit name
   deletion is a frequent occurrence.

   The Name Service primitives are:

      1)   Add Name

           The requesting application wants exclusive use of the name.

      2)   Add Group Name

           The requesting application is willing to share use of the
           name with other applications.

      3)   Delete Name

           The application no longer requires use of the name.  It is
           important to note that typical use of NetBIOS is among
           independently-operated personal computers.  A common way to
           stop using a PC is to turn it off; in this case, the
           graceful give-back mechanism, provided by the Delete Name
           function, is not used.  Because this occurs frequently, the
           network service must support this behavior.



NetBIOS Working Group                                          [Page 11]

RFC 1001                                                      March 1987


5.3.  SESSION SERVICE

   A session is a reliable message exchange, conducted between a pair of
   NetBIOS applications.  Sessions are full-duplex, sequenced, and
   reliable.  Data is organized into messages.  Each message may range
   in size from 0 to 131,071 bytes.  No expedited or urgent data
   capabilities are present.

   Multiple sessions may exist between any pair of calling and called
   names.

   The parties to a connection have access to the calling and called
   names.

   The NetBIOS specification does not define how a connection request to
   a shared (group) name resolves into a session.  The usual assumption
   is that a session may be established with any one owner of the called
   group name.

   An important service provided to NetBIOS applications is the
   detection of sessions failure.  The loss of a session is reported to
   an application via all of the outstanding service requests for that
   session.  For example, if the application has only a NetBIOS receive
   primitive pending and the session terminates, the pending receive
   will abort with a termination indication.

   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