Network Working Group
`Request for Comments: 1001 March, 1987
`
` PROTOCOL STANDARD FOR A NetBIOS SERVICE
` ON A TCP/UDP TRANSPORT:
` CONCEPTS AND METHODS
`
`
`
`
`
` ABSTRACT
`
`This RFC defines a proposed standard protocol to support NetBIOS
`services in a TCP/IP environment. Both local network and internet
`operation are supported. Various node types are defined to accommodate
`local and internet topologies and to allow operation with or without the
`use of IP broadcast.
`
`This RFC describes the NetBIOS-over-TCP protocols in a general manner,
`emphasizing the underlying ideas and techniques. Detailed
`specifications are found in a companion RFC, "Protocol Standard For a
`NetBIOS Service on a TCP/UDP Transport: Detailed Specifications".
`
`
`
`NetBIOS Working Group [Page 1]
`
`
`
`Samsung - Exhibit 1028 - Page 1
`
`

`
`RFC 1001 March 1987
`
` SUMMARY OF CONTENTS
`
`
`
`
`
`1. STATUS OF THIS MEMO 6
`2. ACKNOWLEDGEMENTS 6
`3. INTRODUCTION 7
`4. DESIGN PRINCIPLES 7
`5. OVERVIEW OF NetBIOS 10
`6. NetBIOS FACILITIES SUPPORTED BY THIS STANDARD 15
`7. REQUIRED SUPPORTING SERVICE INTERFACES AND DEFINITIONS 15
`8. RELATED PROTOCOLS AND SERVICES 16
`9. NetBIOS SCOPE 16
`10. NetBIOS END-NODES 16
`11. NetBIOS SUPPORT SERVERS 18
`12. TOPOLOGIES 20
`13. GENERAL METHODS 23
`14. REPRESENTATION OF NETBIOS NAMES 25
`15. NetBIOS NAME SERVICE 27
`16. NetBIOS SESSION SERVICE 48
`17. NETBIOS DATAGRAM SERVICE 55
`18. NODE CONFIGURATION PARAMETERS 58
`19. MINIMAL CONFORMANCE 59
`REFERENCES 60
`APPENDIX A - INTEGRATION WITH INTERNET GROUP MULTICASTING 61
`APPENDIX B - IMPLEMENTATION CONSIDERATIONS 62
`
`
`
`NetBIOS Working Group [Page 2]
`
`
`
`Samsung - Exhibit 1028 - Page 2
`
`

`
`RFC 1001 March 1987
`
` TABLE OF CONTENTS
`
`
`
`
`
`1. STATUS OF THIS MEMO 6
`
`2. ACKNOWLEDGEMENTS 6
`
`3. INTRODUCTION 7
`
`4. DESIGN PRINCIPLES 8
` 4.1 PRESERVE NetBIOS SERVICES 8
` 4.2 USE EXISTING STANDARDS 8
` 4.3 MINIMIZE OPTIONS 8
` 4.4 TOLERATE ERRORS AND DISRUPTIONS 8
` 4.5 DO NOT REQUIRE CENTRAL MANAGEMENT 9
` 4.6 ALLOW INTERNET OPERATION 9
` 4.7 MINIMIZE BROADCAST ACTIVITY 9
` 4.8 PERMIT IMPLEMENTATION ON EXISTING SYSTEMS 9
` 4.9 REQUIRE ONLY THE MINIMUM NECESSARY TO OPERATE 9
` 4.10 MAXIMIZE EFFICIENCY 10
` 4.11 MINIMIZE NEW INVENTIONS 10
`
`5. OVERVIEW OF NetBIOS 10
` 5.1 INTERFACE TO APPLICATION PROGRAMS 10
` 5.2 NAME SERVICE 11
` 5.3 SESSION SERVICE 12
` 5.4 DATAGRAM SERVICE 13
` 5.5 MISCELLANEOUS FUNCTIONS 14
` 5.6 NON-STANDARD EXTENSIONS 15
`
`6. NetBIOS FACILITIES SUPPORTED BY THIS STANDARD 15
`
`7. REQUIRED SUPPORTING SERVICE INTERFACES AND DEFINITIONS 15
`
`8. RELATED PROTOCOLS AND SERVICES 16
`
`9. NetBIOS SCOPE 16
`
`10. NetBIOS END-NODES 16
` 10.1 BROADCAST (B) NODES 16
` 10.2 POINT-TO-POINT (P) NODES 16
` 10.3 MIXED MODE (M) NODES 16
`
`11. NetBIOS SUPPORT SERVERS 18
` 11.1 NetBIOS NAME SERVER (NBNS) NODES 18
` 11.1.1 RELATIONSHIP OF THE NBNS TO THE DOMAIN NAME SYSTEM 19
` 11.2 NetBIOS DATAGRAM DISTRIBUTION SERVER (NBDD) NODES 19
` 11.3 RELATIONSHIP OF NBNS AND NBDD NODES 20
` 11.4 RELATIONSHIP OF NetBIOS SUPPORT SERVERS AND B NODES 20
`12. TOPOLOGIES 20
` 12.1 LOCAL 20
`
`
`
`NetBIOS Working Group [Page 3]
`
`
`
`Samsung - Exhibit 1028 - Page 3
`
`

`
`RFC 1001 March 1987
`
` 12.1.1 B NODES ONLY 21
` 12.1.2 P NODES ONLY 21
` 12.1.3 MIXED B AND P NODES 21
` 12.2 INTERNET 22
` 12.2.1 P NODES ONLY 22
` 12.2.2 MIXED M AND P NODES 23
`
`13. GENERAL METHODS 23
` 13.1 REQUEST/RESPONSE INTERACTION STYLE 23
` 13.1.1 RETRANSMISSION OF REQUESTS 24
` 13.1.2 REQUESTS WITHOUT RESPONSES: DEMANDS 24
` 13.2 TRANSACTIONS 25
` 13.2.1 TRANSACTION ID 25
` 13.3 TCP AND UDP FOUNDATIONS 25
`
`14. REPRESENTATION OF NETBIOS NAMES 25
` 14.1 FIRST LEVEL ENCODING 26
` 14.2 SECOND LEVEL ENCODING 27
`
`15. NetBIOS NAME SERVICE 27
` 15.1 OVERVIEW OF NetBIOS NAME SERVICE 27
` 15.1.1 NAME REGISTRATION (CLAIM) 27
` 15.1.2 NAME QUERY (DISCOVERY) 28
` 15.1.3 NAME RELEASE 28
` 15.1.3.1 EXPLICIT RELEASE 28
` 15.1.3.2 NAME LIFETIME AND REFRESH 29
` 15.1.3.3 NAME CHALLENGE 29
` 15.1.3.4 GROUP NAME FADE-OUT 29
` 15.1.3.5 NAME CONFLICT 30
` 15.1.4 ADAPTER STATUS 31
` 15.1.5 END-NODE NBNS INTERACTION 31
` 15.1.5.1 UDP, TCP, AND TRUNCATION 31
` 15.1.5.2 NBNS WACK 32
` 15.1.5.3 NBNS REDIRECTION 32
` 15.1.6 SECURED VERSUS NON-SECURED NBNS 32
` 15.1.7 CONSISTENCY OF THE NBNS DATA BASE 32
` 15.1.8 NAME CACHING 34
` 15.2 NAME REGISTRATION TRANSACTIONS 34
` 15.2.1 NAME REGISTRATION BY B NODES 34
` 15.2.2 NAME REGISTRATION BY P NODES 35
` 15.2.2.1 NEW NAME, OR NEW GROUP MEMBER 35
` 15.2.2.2 EXISTING NAME AND OWNER IS STILL ACTIVE 36
` 15.2.2.3 EXISTING NAME AND OWNER IS INACTIVE 37
` 15.2.3 NAME REGISTRATION BY M NODES 38
` 15.3 NAME QUERY TRANSACTIONS 39
` 15.3.1 QUERY BY B NODES 39
` 15.3.2 QUERY BY P NODES 40
` 15.3.3 QUERY BY M NODES 43
` 15.3.4 ACQUIRE GROUP MEMBERSHIP LIST 43
` 15.4 NAME RELEASE TRANSACTIONS 44
` 15.4.1 RELEASE BY B NODES 44
`
`
`
`
`
`NetBIOS Working Group [Page 4]
`
`
`
`Samsung - Exhibit 1028 - Page 4
`
`

`
`RFC 1001 March 1987
`
` 15.4.2 RELEASE BY P NODES 44
` 15.4.3 RELEASE BY M NODES 44
` 15.5 NAME MAINTENANCE TRANSACTIONS 45
` 15.5.1 NAME REFRESH 45
` 15.5.2 NAME CHALLENGE 46
` 15.5.3 CLEAR NAME CONFLICT 47
` 15.6 ADAPTER STATUS TRANSACTIONS 47
`
`16. NetBIOS SESSION SERVICE 48
` 16.1 OVERVIEW OF NetBIOS SESSION SERVICE 49
` 16.1.1 SESSION ESTABLISHMENT PHASE OVERVIEW 49
` 16.1.1.1 RETRYING AFTER BEING RETARGETTED 50
` 16.1.1.2 SESSION ESTABLISHMENT TO A GROUP NAME 51
` 16.1.2 STEADY STATE PHASE OVERVIEW 51
` 16.1.3 SESSION TERMINATION PHASE OVERVIEW 51
` 16.2 SESSION ESTABLISHMENT PHASE 52
` 16.3 SESSION DATA TRANSFER PHASE 54
` 16.3.1 DATA ENCAPSULATION 54
` 16.3.2 SESSION KEEP-ALIVES 54
`
`17. NETBIOS DATAGRAM SERVICE 55
` 17.1 OVERVIEW OF NetBIOS DATAGRAM SERVICE 55
` 17.1.1 UNICAST, MULTICAST, AND BROADCAST 55
` 17.1.2 FRAGMENTATION OF NetBIOS DATAGRAMS 55
` 17.2 NetBIOS DATAGRAMS BY B NODES 57
` 17.3 NetBIOS DATAGRAMS BY P AND M NODES 58
`
`18. NODE CONFIGURATION PARAMETERS 58
`
`19. MINIMAL CONFORMANCE 59
`
`REFERENCES 60
`
`APPENDIX A 61
`
`INTEGRATION WITH INTERNET GROUP MULTICASTING 61
` A-1. ADDITIONAL PROTOCOL REQUIRED IN B AND M NODES 61
` A-2. CONSTRAINTS 61
`
`APPENDIX B 62
`
`IMPLEMENTATION CONSIDERATIONS 62
` B-1. IMPLEMENTATION MODELS 62
` B-1.1 MODEL INDEPENDENT CONSIDERATIONS 63
` B-1.2 SERVICE OPERATION FOR EACH MODEL 63
` B-2. CASUAL AND RESTRICTED NetBIOS APPLICATIONS 64
` B-3. TCP VERSUS SESSION KEEP-ALIVES 66
` B-4. RETARGET ALGORITHMS 67
` B-5. NBDD SERVICE 68
` B-6. APPLICATION CONSIDERATIONS 68
` B-6.1 USE OF NetBIOS DATAGRAMS 68
`
`
`
`
`
`NetBIOS Working Group [Page 5]
`
`
`
`Samsung - Exhibit 1028 - Page 5
`
`

`
`RFC 1001 March 1987
`
`
`
` PROTOCOL STANDARD FOR A NetBIOS SERVICE
` ON A TCP/UDP TRANSPORT:
` CONCEPTS AND METHODS
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`1. STATUS OF THIS MEMO
` This RFC specifies a proposed standard for the Internet
` community. Since this topic is new to the Internet community,
` discussions and suggestions are specifically requested.
` Please send written comments to:
` Karl Auerbach
` Epilogue Technology Corporation
` P.O. Box 5432
` Redwood City, CA 94063
` Please send online comments to:
` Avnish Aggarwal
` Internet: mtxinu!excelan!avnish@ucbvax.berkeley.edu
` Usenet: ucbvax!mtxinu!excelan!avnish
` Distribution of this document is unlimited.
`
`2. ACKNOWLEDGEMENTS
` This RFC has been developed under the auspices of the Internet
` Activities Board, especially the End-to-End Services Task Force.
` The following individuals have contributed to the development of
` this RFC:
` Avnish Aggarwal Arvind Agrawal Lorenzo Aguilar
` Geoffrey Arnold Karl Auerbach K. Ramesh Babu
` Keith Ball Amatzia Ben-Artzi Vint Cerf
` Richard Cherry David Crocker Steve Deering
` Greg Ennis Steve Holmgren Jay Israel
` David Kaufman Lee LaBarre James Lau
` Dan Lynch Gaylord Miyata David Stevens
` Steve Thomas Ishan Wu
` The system proposed by this RFC does not reflect any existing
` Netbios-over-TCP implementation. However, the design
` incorporates considerable knowledge obtained from prior
` implementations. Special thanks goes to the following
` organizations which have provided this invaluable information:
` CMC/Syros Excelan Sytek Ungermann-Bass
`
`
`
`
`
`
`
`NetBIOS Working Group [Page 6]
`
`
`
`Samsung - Exhibit 1028 - 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]
`
`
`
`Samsung - Exhibit 1028 - 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]
`
`
`
`Samsung - Exhibit 1028 - 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]
`
`
`
`Samsung - Exhibit 1028 - 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]
`
`
`
`Samsung - Exhibit 1028 - 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]
`
`
`
`Samsung - Exhibit 1028 - 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
` 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]
`
`
`
`Samsung - Exhibit 1028 - 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]
`
`
`
`Samsung - Exhibit 1028 - 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