glass@mica.berkeley.edu (Brett Glass) (03/14/89)
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 Glassglass@anableps.berkeley.edu (Brett Glass) (03/16/89)
The following is a list of references on the NetBIOS API which may prove useful to those interested in the mechanics of NetBIOS datagrams. In these works, the technical descriptions of the Receive Datagram command differ from the specifications set forth in RFCs 1001 and 1002 in that one incoming datagram does NOT satisfy all matching commands. This convention is followed by most (perhaps all) real-world implementations of NetBIOS. Schwaderer, W. David. "C Programmer's Guide to NetBIOS." Indianapolis, Indiana: Howard W. Sams, Inc. 1988. ISBN 0-672-22638-3. This book, written by an IBM employee, gives a detailed description of NetBIOS programming in C. On page 252, in the description of the Receive Datagram Command, the author states: "If an adapter has several Receive Datagram commands pending for the same name, the next Send Datagram command satisfies ONLY ONE [emphasis mine] of the Receive Datagram commands." "Technical Reference: IBM PC Network." First Edition (September 1984). Armonk, New York: IBM Corporation 1984. Part number 6322916. This manual is the authoritative reference on NetBIOS. It does not indicate that more than one Receive Datagram command should be satisfied by a single incoming datagram, but explicitly indicates that all Receive Broadcast Datagram commands are to be satisfied by a single broadcast datagram. "VMD\NET-ARC Product Referemnce Reference Manual." Vancouver, BC: Virtual Machine Technology, Inc. 1988. Document number VMD-NA-REF-1987-10 This is a reference manual for a non-IBM NetBIOS program, representative of many now on the market. On page 2-27, it states: "RECEIVE DATAGRAMs for the name are satisfied on a first in, first complete basis." --Brett Glass
karl@TRWIND.IND.TRW.COM (Karl Auerbach) (03/16/89)
Hi -- The paragraph that you quote from RFC1001 is from a part which is background material describing the typical PC-DOS service interface to Netbios. The RFC specifies the protocol, not the service interface. Even if the quoted paragraph is, in fact, inconsistant with the Sytek/IBM definition of the NCB service interface, there is no impact on the RFC1001/1002 protocol. --karl--
glass@anableps.berkeley.edu (Brett Glass) (03/17/89)
In article <8903160644.AA03229@trwind.ind.TRW.COM> karl@TRWIND.IND.TRW.COM (Karl Auerbach) writes: >Hi -- The paragraph that you quote from RFC1001 is from a part which >is background material describing the typical PC-DOS service interface >to Netbios. Please see my more recent message concerning RFC 1002. The implementation details of the datagram service protocol contained in that RFC embody the same error. Implementors who use the RFC as a guide when building a NetBIOS (which they are likely to do; the original IBM document is now out of print) may build this error into their code, causing crashes, hung systems, and scrambled databases. I know of two programs -- an SQL package and a network conferencing program -- for which this problem can be fatal. Both run perfectly on every NetBIOS-based network I've tested -- EXCEPT those which attempt to conform to the pseudocode description in RFC1002. Others are more tolerant but still malfunction. >The RFC specifies the protocol, not the service interface. >Even if the quoted paragraph is, in fact, inconsistant with the >Sytek/IBM definition of the NCB service interface, there is no impact >on the RFC1001/1002 protocol. The error is independent of the NCB interface; it is a problem in the underlying service protocol. <BG>