Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!agate!mica.berkeley.edu!glass
From: glass@mica.berkeley.edu (Brett Glass)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: NetBIOS Datagrams: Potential Incompatibility in RFC 1001
Message-ID: <21589@agate.BERKELEY.EDU>
Date: 14 Mar 89 04:51:34 GMT
Sender: usenet@agate.BERKELEY.EDU
Reply-To: glass@mica.berkeley.edu (Brett Glass)
Organization: University of California, Berkeley
Lines: 72

The following is a copy of a message I've sent to Avnish
Aggarwal of the NetBIOS Working Group. It concerns a potential
incompatibility between RFC 1001 and real-life implementations
of NetBIOS.

--------

Avnish:

I've been doing extensive work with NetBIOS, and have been
reading RFCs 1001 and 1002 to see what work has been done to
allow NetBIOS to operate under TCP/IP. So far, what I've seen
looks good. However, I noticed a small but vital detail in RFC
1001 which doesn't conform to the behavior of current
implementations; I think it warrants a change to ensure software
compatibility.

In the section on Datagram Services, RFC 1001 says:

      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.

The last paragraph of this section is inconsistent with most
real-life implementations of NetBIOS. I've worked with many
implementations of NetBIOS, and have not seen one in which a
single datagram causes all pending Receive Datagram commands to
complete.

There is a good reason for this. Suppose an application is
expecting to handle incoming datagrams addressed to a specific
unique (or group) name. If there is no Receive Datagram command
pending at the time the datagram is received, the datagram is
lost. In order to make sure that none are missed, many
applications issue several Receive Datagram commands. This way,
there is always a command ready to be satisfied -- even during the
short period of time when a datagram is being processed.

Many applications rely on this practice, including one I
published as a sample in the January BYTE (Understanding
NetBIOS). The application I presented there runs under every
NetBIOS implementation I've tested (with the exception of the
Novell NetBIOS emulator, which does not handle datagrams properly
at all). I've never received word that my program failed to work
on a NetBIOS-based network.

The implementors of programs that use datagrams rely on the
specification in the IBM PC Network Technical Reference (IBM part
number 6322505). This document does not state that more than one
Receive Datagram command should be satisfied by a single
datagram. It does state (Page 2-73) that all Receive BROADCAST
Datagram commands are satisfied by a single broadcast datagram;
this is one of the reasons that broadcast datagrams are seldom
used.

I'd like to see the "official" standard changed to conform to the
actual implementations sold by IBM and others -- to ensure that
software works as expected on all platforms. If there's a
specific forum where such things are addressed, I'd like you to
forward this message to it; I think it's important to the
compatibility of software based on this emerging standard.

--Brett Glass