Edit clark_netbeui

Title:

Last edited: 5:34:25 pm on 14 December 2005 by salchicha.sico.local

<html>

<a href="../default.htm">TNRK Home</a><a href="../feedback.htm"> 
Feedback Form</a>

Networking 
<a href="netbasics.htm">Basics</a> 
<a href="osidefined.htm">OSI Model</a> 
<a href="ndis.htm">NDIS</a> 
<a href="cable.htm">Cabling</a> 
<a href="msclient.htm">DOS Client</a>

Protocols 
<a href="prot_ovr.htm">Overview</a> 
<a href="nwlink.htm">NWLink</a> 
<a href="netbeui.htm">NetBEUI</a> 
<a href="dlc_sna.htm">DLC</a>

<dl>
 <dt>TCP/IP 
 <a href="../tcpip/tcp_ip.htm">MS Services</a> 
 <a href="../tcpip/IPsupstand.htm">Standards</a> 
 <a href="../tcpip/internetworking.htm">Internetworking</a> 
 <a href="../tcpip/ms_architecture.htm">Architecture</a> 
 <a href="../tcpip/netbios_names.htm">NetBIOS</a> 
 <a href="../tcpip/lmhosts.htm">LMHOSTS</a> 
 <a href="../tcpip/routing.htm">Routing</a> 
 <a href="../tcpip/winsdns.htm">WINS/DNS</a> 
 <a href="../tcpip/tcpip_ports.htm">Port Reference</a> 
 
 Windows NT 
 <a href="../winnt4/NTPrinting/ntprint1.htm">Printing</a> 
 <a href="../winnt4/policies/policies1.htm">Policies</a> 
 <a href="../winnt4/profiles/profiles1.htm">Profiles</a> 
 <a href="../winnt4/RAS/default.htm">RAS Home</a> 
 <a href="../winnt4/Perfmon/Default.htm">Monitoring Performance</a></dt>
</dl>

</td><td valign="top" width="24"></td><td valign="top">

NetBEUI for Windows NT

Note: they use NDIS 3.0 here when they should be saying 4.0 as that is the version used
by NT 4.0, I tried to edit it out but I missed it in some places

The Windows&nbsp;NT-based implementation of NetBEUI, referred to as NBF throughout the
remainder of this chapter, does the following:

<ul>
 <li>Uses the Windows&nbsp;NT-based Transport Driver Interface (TDI) which provides an
 emulator for interpretation of NetBIOS network commands. </li>
 <li>Uses the Windows&nbsp;NT-based Network Device Interface Specification (NDIS) version 4.0
 with improved transport support and a full 32-bit asynchronous interface. </li>
 <li>Removes the NetBIOS session number limit. </li>
 <li>Uses memory dynamically to provide automatic memory tuning. </li>
 <li>Supports dial-up client communications with Remote Access Service (RAS) services. </li>
 <li>Provides connection-oriented and connectionless data transfer services.</li>
</ul>

Interoperability Using NBF

NBF provides compatibility with computers running under the earlier operating systems
of Microsoft LAN Manager and MS-Net, and IBM LAN Server. NBF can be used to connect LAN
workstation and server computers, and to connect remote and dial-up clients, including
laptop computers, to computers running the Windows&nbsp;NT-based RAS.

NBF can be used with programs that implement a variety of services based on the
following application programming interfaces (APIs):

<ul>
 <li>NetBIOS </li>
 <li>Named Pipes </li>
 <li>Mailslot </li>
 <li>Network DDE (dynamic data exchange) </li>
 <li>Remote Procedure Call (RPC) over NetBIOS </li>
 <li>RPC over Named Pipes</li>
</ul>

NBF is most efficient when used for computers connecting to small to medium-sized,
single-location networks. NBF is not a routable protocol like TCP/IP or IPX, although NBF
does support a form of routing known as Token Ring routing, available only on IBM Token
Ring networks. Additionally, NBF uses a single part-naming scheme that does not support
network segmentation used in most large networks.

Architecture of NBF

NBF is a transport driver that is composed of the following layers:

LLC802.2 Protocol

Corresponds to the Open Systems Interconnect (OSI) Logical Link Control (LLC) layer. It
performs code, address, and control frame flow, and provides connectionless data transfer.

NetBIOS Frame Protocol (NBFP)

Corresponds to the OSI Transport and Session layers. It performs session establishment,
multiplexing, and termination. It also performs message segmentation, delimiting,
assembly, and acknowledgment.

Figure 13.1 shows the components of NBF and their relation to the OSI model.

Figure 13.1 the OSI Model and the Architecture of NBF

Notice that the upper edge of NBF, the NBFP component, connects to the bottom edge of
the Windows&nbsp;NT-based Transport Driver interface (TDI). The lower edge of NBF, the LLC
component, connects to the Network Driver Interface (NDIS).

Note

In the preceding illustration, the Network layer between NBFP and LLC is intentionally
empty. In the OSI model, the Network layer lies between the Transport and LLC layers.
However, NetBEUI uses IBM Token Ring source routing to perform network layer functions.
Token Ring source routing conforms to a different standard, the IEEE 802.5 standard, and
logically corresponds to the OSI Physical layer, not the OSI Network layer.

NBF's Interface to the Upper OSI Layers&#151;The TDI Interface

Software programs that rely on NBFP for network communication require a transport
driver that exposes the NetBIOS interface. However, the Windows&nbsp;NT-based transport
drivers for NBF, IPX, and TCP/IP do not expose a NetBIOS interface; instead they expose
the more flexible Windows NT TDI, as illustrated in both Figure 13.1 and Figure 13.2.

The Windows NT TDI provides a NetBIOS emulator that maps NetBIOS commands to TDI
commands to support applications designed for use with NBFP. Note that Figure 13.2
illustrates how both NetBIOS-based and Windows Sockets-based applications use the TDI.

THERE WOULD BE A PICTURE HERE IF MICROSOFT WASN&#146;T ON CRACK AND PUT AN IMAGE OF THE
TDI AND TCP/IP CONNECTION.

Note

In the preceding figure, the term &quot;transport providers&quot; refers to the binding
of a specific transport driver, such as NBF, to a specific underlying NIC driver.
Computers in which multiple NIC cards are installed will have multiple bindings.

This is how the TDI supports NetBIOS-based applications: NetBIOS commands are formatted
as network control blocks (NCBs). When a program running on a Windows NT-based computer
creates an NCB, the Windows NT-based NetBIOS driver (Netbios.sys) first processes the
NetBIOS command. Netbios.sys processes the NCB by mapping it to the corresponding TDI
command or commands, and sends the TDI command to the Windows&nbsp;NT-based NetBEUI driver
(Nbf.sys). (TDI calls implement the same general semantics as NetBIOS NCBs, but are
optimized for a 32-bit kernel interface.)

In other words, unlike 16-bit Windows and MS-DOS transport clients which send NCBs
directly to a NetBEUI driver, the NetBIOS network applications running on a
Windows&nbsp;NT-based computer must direct the NCBs to a NetBIOS emulator. The NetBIOS
emulator creates TDI requests and sends the TDI requests to the NBF transport driver.

NBF's Interface to the Lower OSI Layers &#151; The NDIS Interface

The NBF transport driver processes the TDI requests as frames that are to be sent out
on the network in the Logical Link Control (LLC) layer. This lower edge, the LLC layer, is
the NBF layer that receives frames sent from a remote computer on the network.

NBF conforms to the IEEE 802.2 LLC protocol standard and performs the following
functions:

<ul>
 <li>Link establishment (connection-oriented data transfer) </li>
 <li>Maintenance and termination </li>
 <li>Frame sequencing and acknowledgment </li>
 <li>Frame flow control </li>
 <li>Connectionless data transfer</li>
</ul>

At the LLC layer, NBF binds, receives, and sends packets to the underlying NIC drivers
by using the NDIS 4.0 interface. (See the earlier note about the term &quot;transport
providers.&quot;)

Communication within the LLC layer is based on service access points, links, and link
stations. Each LLC client program identifies itself by registering a unique service access
point (SAP). A SAP is actually a mechanism by which the layer above can programmatically
access a particular service implemented by the layer below. A SAP can also be thought of
as the address of a software port as defined by the OSI model. There are well-known SAPs,
similar to the well-known ports of TCP/IP. Because NBF is a NetBIOS implementation, it
uses the well-known NetBIOS SAP (0xF0). This is illustrated in Figure 13.3, which shows
the relationship of the SAP to the LLC Layer.

Figure 13.3 The NBF LLC Layer and NDIS Interface to the Physical Layers

When a network client program uses LLC to send a frame on to the network, LLC specifies
the client SAP as well as the destination SAP in the header of the LLC frame. The header
of an LLC frame thus identifies the:

Source service access point (SSAP) the LLC client on the sending computer that created
the frame.

Destination service access point (DSAP)&#151;the LLC client on the receiving computer
that should receive the frame.

The SSAP, DSAP, and NIC address of the destination client are all that is needed for
unreliable connectionless data transfer, in which NBF transmits the message once or a
specified number of times and is responsible only for ensuring that the frame is properly
transmitted on the network medium. No acknowledgment from the destination client is
required.

Reliable connection-oriented data transfer service requires establishment of a link
between the sending and receiving LLC clients in which NBF is responsible for transferring
the frame from the source client to the destination client and which requires an
acknowledgment from the destination client that the frame is received. Using the sending
client SAP, the destination client SAP, and the NIC address of the remote computer
establish the link. Note that the NIC address of the receiving client can be specified as:

<ul>
 <li>An individual computer's NIC address where the LLC frame is received by a single LLC
 client that registered the destination SAP. </li>
 <li>A NetBIOS multicast address where the LLC frame is received by all LLC clients that have
 registered the multicast destination SAP.</li>
</ul>

NBF Removes the NetBIOS Session Limit

Early versions of NetBEUI used a 1- byte (8-character binary) number with a maximum
decimal value of 254 to identify NetBIOS sessions. Session numbers were assigned per
computer. That is, a computer using NetBEUI could support a maximum of 254 network
connections.

NBF is not constrained by the session limitation of earlier versions of NetBEUI. NBF
uses the TDI and a TDI 32-bit handle composed of the session number and the network
address of the remote computer. This allows a virtually limitless range of unique numbers
that can be used to uniquely identify sessions.

Using NBF, it is possible for a Windows&nbsp;NT Server with a single network adapter
card to support simultaneous sessions that exceed the previous NetBEUI session limit of
256. For example, a Windows&nbsp;NT Server running NBF with a single network adapter card
is able to support sessions with more than 1,000 clients.

The following figure illustrates the differences between NBF and other non-Windows
implementations of NetBEUI.

Figure 13.4 Comparison between NetBEUI and Windows NT NBF Session Limits

NBF Dynamically Allocates Memory

A Windows&nbsp;NT-based computer running NBF automatically allocates the memory
necessary to process the requests made by session clients. This means that NBF uses memory
only when needed. For example, on a Windows NT-based computer that does not have an active
network connection, the NBF protocol stack will use very little memory.

Because of this dynamic memory management, installing NBF on a Windows&nbsp;NT-based
computer is easily done. It does not require additional configuration for number of
sessions, packets, or buffers.

NBF Supports RAS Clients

Remote computers that need to connect to a computer running Windows NT Server with RAS
server use NBF. Because NBF dynamically allocates memory and is self-tuning, no
configuration is required on the computer running the RAS client service. However, the
WanNameQueryRetries parameter in the Registry can be changed to fine-tune RAS name query
performance by using the Registry Editor. (This parameter is the WAN equivalent of the
NameQueryRetries parameter.)

Connection-oriented and Connectionless Data Transfer

NBF supports both unreliable connectionless and reliable connection-oriented data
transfer. Unreliable connectionless data transfer is also called datagram, or Type&nbsp;1,
operation.

Unreliable connectionless communication is similar to sending a letter in the mail. No
response is generated by the receiver of the letter to tell the sender that the letter
made it to its destination.

Note

Connectionless communications can be either unreliable or reliable. NBF provides only
unreliable connectionless communications. Reliable connectionless communications is like a
registered letter whose sender is notified that the letter arrived.

In unreliable connectionless communicaton, the transport protocol driver transmits the
message once or a specified number of times, ensuring only that the message was properly
transmitted to the network medium. The message can only be a single frame. Acknowledgment
from the destination computer is not required.

Note

If reliable connectionless communication is required, NBF can be configured for certain
communication commands to send a number of frames that will allow time for the destination
computer to respond to the message. The number is based on retry Registry value entries,
such as NameQueryRetries. The time between sending each frame is determined by timeout
Registry entries, such as NameQueryTimeout.

Reliable connection-oriented communication is also called session, or Type&nbsp;2,
operation. Reliable connection-oriented communication provides reliable communications
between two computers in a way that is analogous to a phone call where two callers
connect, a conversation occurs, and then the connection is dropped when the conversation
ends. A reliable connection requires more overhead than connectionless communications do.

In reliable connection &#150; oriented communications, the transport protocol driver
assumes responsibility for transferring the entire message from source to destination, and
within an acceptable time period. Sequencing is provided; a message that is larger than
the maximum transmit frame size can be broken down into multiple frames, sent across the
network, and properly reassembled at the receiving computer.

Connectionless Traffic

Three types of NetBIOS commands generate connectionless traffic:

<ul>
 <li>Name claim and resolution </li>
 <li>Datagrams </li>
 <li>Miscellaneous commands</li>
</ul>

These commands are sent as Unnumbered Information (UI) frames at the LLC sublayer.

To understand how Windows&nbsp;NT Server and Windows&nbsp;NT Workstation use retry and
timeout values, consider what happens when the Windows&nbsp;NT-based computer running NBF
registers its NetBIOS computer name. The Windows&nbsp;NT-based computer sends a multicast
message containing an ADD_NAME_QUERY frame on to the network. Other computers on the
network running NBF can retrieve and process the ADD_NAME_QUERY message. The multicast
frames are sent a total of AddNameQueryRetries times at time intervals
of&nbsp;AddNameQueryTimeout. This allows computers on the network enough time to
inform&nbsp;the sending computer whether the name is already registered as a unique
computer name or as a group name on the network.

Note

All Registry values discussed in this chapter are found under the following Registry
path:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Nbf

Connection-oriented Traffic

The net use command is an example of a connection-oriented communication, as
illustrated in Figure 13.5.

Figure 13.5 Connection-oriented Network Traffic

When a user types net use at the command line to connect to a shared resource, NBF must
first locate the server by sending UI-frames, and then initialize the link. This is
handled by the redirector when it makes a connection to the NBF drivers by using the TDI
interface. NBF begins the sequence by generating a NetBIOS Find Name frame. Once the
server is found, a session is set up with Class-II frames which contain timing parameters
following the 802.2 protocol standard (802.2 governs the overall flow of data).

The client computer sends a Set Asynchronous Balance Mode Extended (SABME) frame, and
the server returns an Unnumbered Acknowledgment (UA) frame. Then the client sends a
Receive Ready (RR) frame, notifying the server that it is ready to receive Informational
(I) frames whose sequence number is currently 0. The server acknowledges this frame.

Once the LLC-level session is established, additional NetBEUI-level information is
exchanged. The client sends a Session Initialize frame, and then the server responds with
a Session Confirm frame. At this point, the NetBEUI-level session is ready to handle
application-level frames (Server Message Blocks, or SMBs).

Reliable transfer is achieved with link-oriented frames by numbering the I-frames. This
allows the receiving computer to determine whether the frames were lost and in what order
they were received.

NBF improves performance for connection-oriented traffic through two techniques: use of
adaptive sliding windows and use of link timers. The next two sections describe these
techniques.

Adaptive Sliding Window Protocol

NBF uses an adaptive sliding window algorithm to improve performance while reducing
network congestion and providing flow control. A sliding window algorithm allows the
Windows&nbsp;NT-based computer using NBF to dynamically tune the number of LLC frames sent
before an acknowledgment is requested. Figure 13.6 shows frames traveling through a
two-way pipe.

Figure 13.6 Adaptive Sliding Window

If the sending computer could send only one frame on to the network and then had to
wait for an acknowledgment (ACK), the sending computer would be underused. The frames
would travel forward, and then ACKs for the received frames would have to travel back to
the sending computer before it could send another frame. The number of frames that the
sender is allowed to send before it must wait for an ACK is referred to as the send
window.

The number of frames that a receiving computer is allowed to receive before sending an
ACK to the sending computer is referred to as a receive window. In general, NBF has no
receive window, unless it detects that the remote sending computer is running a version of
IBM NetBEUI which does not support polling; in this case, NBF uses a receive window based
on the value of MaximumIncomingFrames in the Registry.

The default value for MaximumIncomingFrames is 2 and this value does not dynamically
change. It must be manually changed by using the Registry Editor. For additional
information about the receive window, refer to &quot;Using Windows NT NetBEUI in IBM LAN
Server Networks&quot; in the section &quot;Troubleshooting NetBEUI&quot; later in this
chapter.

The adaptive sliding window protocol tries to determine the best sizes for the send
window based on current network conditions. Ideally, the windows should be big enough so
that maximum throughput can be realized. However, if the window gets too big, the
receiving computer could get overloaded and drop frames.

Dropped frames cause significant network traffic because more frames have to be
retransmitted. Dropped frames might be a problem on slow links or when frames have to pass
over multiple hops to find the destination computer. Dropped frames coupled with large
send windows generate multiple retransmissions. This traffic overhead might make an
already congested network worse. Limiting the send window size can improve performance by
reducing network traffic.

Link Timers

NBF uses three timers to help regulate network traffic: the response timer (T1), the
acknowledgment timer (T2), and the inactivity timer (Ti). These timers are controlled by
the values of the Registry parameters DefaultT1Timeout, DefaultT2Timeout, and
DefaultTiTimeout, respectively.

The response timer is used to determine how long the sender should wait before it
assumes that the I-frame is lost. After T1 milliseconds, NBF sends an RR frame and doubles
the value for T1. If the RR frame is not acknowledged after the number of retries defined
by the value of LLCRetries, the link is dropped.

Where the return traffic does not allow the receiver to send an I-frame within a
legitimate time period, the acknowledgment timer begins, and then the ACK is sent. The
value for this timer is set by the T2 variable, with a default value of 150 milliseconds.
If the sender has to wait until the T2 timer starts in order to receive

a response, the link might be underused while the sender waits for the ACK. This rare
situation can occur over slow links. On the other hand, if the timer value is too low, the
timer starts and sends unnecessary ACKs, generating excess traffic. NBF is optimized so
that the last frame that the sender wants to send is sent with the POLL bit turned on.
This forces the receiver to send an ACK immediately.

The inactivity timer, Ti, is used to detect whether the link has gone down. The default
value for Ti is 30 seconds. If Ti milliseconds pass without activity on the link, NBF
sends an I-frame for polling. This is then ACKed, and the link is maintained.

Note

Remember that T2 is less than or equal to T1, which is less than or equal to&nbsp;Ti.

The T1 parameter is tuned dynamically on a per-link basis, based on link conditions and
throughput. The value of the T1 parameter as specified in the Registry is used as the
starting value for how long the process should wait for a response. This registry
parameter can be changed. For example, if you know that the computer connects to the
network on a slow link, the T1 registry parameter value can be increased. However, even if
this parameter is not changed, NBF can detect the slow link quickly and automatically tune
the T1 registry parameter value.

T2 and Ti are not adapted dynamically.

NBF Sessions

Each process that uses Windows&nbsp;NT-based NetBIOS can communicate with up to 254
different computers. Earlier implementations of NetBIOS supported only 254 sessions for
the entire computer, including the workstation and server components.

The implementation of NetBIOS under Windows&nbsp;NT requires that an application do a
few more things than have traditionally been required in other NetBIOS implementations,
but the capacity for maintaining up to 254 sessions from within each process by using
Windows&nbsp;NT-based NetBIOS is well worth the price.

Note that the 254-session limit does not apply to the default workstation or server
components of Windows NT. The workstation and server services avoid the session limit
problem completely by writing directly to the TDI, which is a 32-bit handle-based
interface, instead of writing directly to the NetBIOS interface.

NBF also has a unique method of handling resources to create a virtually infinite
(local computer memory permitting) number of connections, as described in the next
section.

&nbsp;

Session Limits

The 254-session limit is based on a key variable in the NetBIOS architecture called the
Local Session Number (LSN). This is a 1-byte number (0 to 255) with several numbers
reserved for system use. When two computers establish a session via NBF, there is an
exchange of LSNs.

The LSNs on the two computers might be different. They do not have to match, but a
computer always uses the same LSN for a given session. This number is assigned when a
program issues a call for a Network Control Block (CALL NCB). The number is actually
shared between the two computers in the initial frame sent from the calling computer to
the listening computer. Figure 13.7 shows this session-creation frame exchange.

Figure 13.7 Multicast of NameQuery

The initial frame is a NameQuery frame. In earlier implementations of NBF, this frame
was broadcast onto the network. All computers read the frame and check to see if they have
the name in their name space and if there is a LISTEN NCB pending on the name. If there is
a LISTEN NCB pending, the computer assigns a new LSN for itself. It adds the LSN to the
response frame, satisfying the LISTEN NCB which now contains just the LSN used on that
computer. Even though each computer knows the LSN of the other, the information is not
used. The more important information for the two communicating partners is the network
addresses that are part of the frames. As the frames are exchanged, each partner picks up
the address of the other in the source address component of the frame received. The NBF
protocol keeps the network address of the remote partner so that subsequent frames can be
addressed directly.

Note

This process applies only to NBF connections. NetBIOS connections established by using
NetBIOS over TCP/IP (NetBT) are handled differently.

Windows&nbsp;NT has to use the same NameQuery frame to establish connections with
remote computers via NBF; otherwise, it would not be able to talk to existing workstations
and servers. The NameQuery frame transmitted must contain the 1-byte-wide LSN to be used.

For example, suppose a computer running Windows&nbsp;NT Server and NBF assigns a
session number of 1 to identify the session between itself and Computer A and also assigns
the number 1 for the simultaneous session with Computer B. The computer running
Windows&nbsp;NT Server can identify the different sessions because it uses the computer
network address as part of the TDI handle to further identify each session. When the
computer running Windows&nbsp;NT Server sends a session frame to either Computer A or
Computer B, it uses the network address to direct the frame across the network. Therefore,
Computer A does not receive the frames addressed to Computer B, and vice versa. However,
if the computer running Windows&nbsp;NT Server and NBF establishes another session with
Computer A, it must use a session number other than 1 to uniquely identify the second
session.

A Windows&nbsp;NT Server computer running NBF can do this only when it is able to
determine beforehand which adapter the session connection is going to be made to. Consider
the following three scenarios:

1. A client connecting to a Windows NT computer running NBF.

When a client connects to a computer running NBF, NBF can inspect the incoming frame to
determine the remote adapter's address and assign a session number for that adapter.

2. NBF connecting to a remote client with a unique NetBIOS name.

When NBF is connecting to a remote client, it first sends a FINDNAME frame. A response
from the remote client means that the name is a unique name. NBF can then look at the
remote adapter address in the response and assign a session number for that adapter
because it knows that only that remote client owns this name.

3. NBF connecting to a remote client with a group NetBIOS name.

If the FINDNAME response indicates that the connection is being made to a group name,
NBF has no way of knowing which adapter belonging to the group will respond when it tries
to connect, and so it has to assign a session number on a global basis, just as NetBEUI
did for all connections.

These scenarios show that NBF has no limit on sessions, unless it is establishing
connections to group names, in which case the old NetBEUI limit still applies. To be
accurate, if you have n group name connections, then you can have 254-n connections to any
given remote client. If n is 0, then you can have a full 254 connections to a remote. If n
is 253, you can still have 1 connection to each remote, but if n is 254, then no
connections can be made until one of the existing ones is disconnected.

Breaking the 254-session Limit

NBF breaks the 254-session barrier by using a combination of two matrices, one
maintained by NBF and one maintained by NetBIOS.

The matrix maintained by NBF is two-dimensional, as shown in Figure 13.8.

Figure 13.8 NBF and Its LSN Matrix

Along the side of this matrix are the LSN numbers 1 to 254. Across the top are the
network addresses for the different computers that it has sessions with. In the cell
defined by the intersection of the LSN and network address is the TDI handle, which
relates back to the process that established the connection (either the CALL or LISTEN).

Note

The matrix concept and its contents are for illustration purposes only. The physical
storage algorithm and exact contents are beyond the scope of this chapter.

The NameQuery frame from Windows&nbsp;NT contains the LSN number associated with the
TDI handle that satisfies either the NCB CALL or the LISTEN. In the case of a CALL, it is
not broadcast but is addressed directly to the remote computer.

The remaining question is how NBF gets the network address of the remote computer to
add to its matrix to be used when doing the CALL. (It's easy on the LISTEN side because
the address is in the NameQuery frame received.)

Figure 13.9 illustrates the NCB CALL and NCB LISTEN frames.

Figure 13.9 NameQuery Frames in NBF

The numbered items in Figure 13.9 represent the following:

1. The first frame (1) is the FindName frame of the NameQuery. However, an LSN of 0 is
special; it indicates that it is a FindName frame. The FindName frame is broadcast on the
network; when a remote computer responds to the frame, NBF on the local computer receives
the network address of the remote computer.

2. The second frame (2) of the NameQuery is then sent directly to the remote computer
by using the network address and a LSN value that indicates it is a CALL command. The
remote client returns a successful FindName frame, even if no LISTEN NCB is posted against
the name.

3. If no LISTEN NCB is posted against the name, frame (3) is sent.

4. The same frame is responded to by frame (4).

NBF must also address another problem&#151;the LSN from the NBF matrix cannot be the
one returned to the process issuing the CALL or LISTEN commands. NBF may have established
connections with multiple remote computers with LSN=5, for example. Windows&nbsp;NT must
return to each process an LSN number that uniquely defines its session.

As stated earlier, NBF uses the TDI handle to know which LSN and network address to
send frames to, and each process has its own set of LSNs available to it. Therefore, there
must be a component between the originating process and the TDI interface of NBF that
translates a process ID and an LSN into a TDI handle. The component in the middle is
Netbios.sys.

Figure 13.10 illustrates the Netbios.sys matrix, which is 254 LSNs per LAN adapter
number per process. (In Windows&nbsp;NT, the LANA number identifies a unique binding of a
protocol driver and one network adapter (NIC) driver.) In reality, each process can have
up to 254 sessions per LANA number, not just a total of 254 sessions.

Figure 13.10 Netbios.sys Matrix

Netbios.sys builds a second matrix that has LSNs down the side, process IDs along the
top, and TDI handles in the cells. It is the LSN from this table that is passed back to
the originating process.

To further understand how Netbios.sys uses this matrix, suppose a process needs to
establish a session with a remote computer. Before the process can issue the CALL NCB, it
must issue a RESET NCB. This command signals Netbios.sys to allocate space in its TDI
handle table, among other things. Once the RESET is satisfied, the process issues a CALL
NCB to make a connection with a specific remote computer. This NCB is directed down to the
Netbios.sys device driver. The driver opens a new TDI handle to NBF and sends the command
to NBF.

NBF issues the first NAME_QUERY with LSN=0 to find the remote computer. When the remote
computer responds, the network address is extracted from the frame, and a column in the
NBF table is created. The second NAME_QUERY with an LSN is sent directly to the remote
computer. When that frame is returned successfully, NBF returns from the TDI call to the
Netbios.sys driver with a successful status code.

Netbios.sys then fills in the LSN from its table into the NCB and sends it back to the
calling process.

Limited Network Routing Using NBF

Multi-location networks, such as a wide area network (WAN), require routing
capabilities, while single-location, small- to medium-sized local area networks (LANs)
generally do not require the overhead of a routing protocol.

NBF is not a routable protocol. It uses a single-part naming scheme which cannot be
used to differentiate between computers belonging to multiple interconnected networks. NBF
can provide a simple form of routing known as Token Ring source routing, and it can only
be implemented on Token Ring networks.

Token Ring source routing occurs when NBF broadcasts a name query frame on a local
token ring; if it doesn't receive a response in a set period of time, it enables source
routing fields in the name query ring frame that force source routing bridges to receive
and process the frame. The source routing bridges add additional routing information to
the frame and send it to all other rings to which the bridge is connected. When the name
query frame reaches the desired computer, that computer sends its computer name in the
return message frame, using the routing information from the query to send the message
directly to the originating computer. The originating computer caches the routing
information and uses the cache to address subsequent frames.

Troubleshooting NetBEUI

This section discusses problems that you might encounter on a Windows&nbsp;NT-based
computer on which the NetBEUI protocol is installed and running.

Note

NBF is the underlying implementation of the NetBEUI protocol installed on a computer
running Windows NT Server or Windows NT Workstation. Most users are more familiar with the
term NetBEUI. When troubleshooting, it is more common to use the term NetBEUI, rather than
NBF.

Tuning NetBEUI Using Registry Parameters

When NetBEUI is installed on a Windows&nbsp;NT-based computer, it is installed with
default configurations. Because NBF is largely self-tuning, no configuration is required
when installing NetBEUI on a Windows&nbsp;NT&#150;based computer.

If desired, however, you can change the default values for NetBEUI registry parameters.
The NetBEUI startup parameters are found under the following subkey:

HKEY_LOCAL_MACHINE\SYSTEM\Services\NBF\Parameters

Warning Using Registry Editor incorrectly can cause serious, system-wide problems that
may require you to reinstall Windows&nbsp;NT to correct them. Microsoft cannot guarantee
that any problems resulting from the incorrect use of Registry Editor can be solved. Use
this tool at your own risk.

Changing a NetBEUI Binding

You can manually change the NetBEUI bindings. The changes you can make are:

<ul>
 <li>Enable a binding </li>
 <li>Disable a binding </li>
 <li>Move the order (priority) of the bindings up or down</li>
</ul>

To change a NetBEUI binding

1. Click Start, point to Settings, and click Control Panel.

2. Double-click Network.

3. Click the Bindings tab.

4. In Show Bindings for, click all protocols.

5. Double-click NetBEUI Protocol to display a list of bindings.

6. Select the binding you want to change and then click the appropriate action button.

7. Click OK.

Source Routing Not Supported in FDDI Network

Source routing is only supported for Token Ring networks. A network using a fiber data
distributed interface (FDDI) for network communications cannot use NBF for source routing.
To correct this problem, use transparent source routing or transparent bridging.

No Session Alive Frames

NBF does not use NetBIOS session alive frames to determine if the remote client is up.
Instead, it sends LLC poll frames, which serve the same purpose. NBF will respond
correctly to session alive frames, so this should cause no interoperability problems with
other implementations of NetBEUI.

Using Windows NT NetBEUI in IBM LAN Server Networks

In general, NBF has no receive window, unless it detects that the remote sending
computer is running a version of IBM NetBEUI which does not use network polling&#151;for
example, IBM LAN Server. NBF initiates a link with a remote computer in the same manner as
IBM NetBEUI; however, NBF looks for a poll bit in received frames. If a frame is received
that does not have the poll bit set, the Windows&nbsp;NT-based computer will wait until T2
expires before sending a frame ACK.

Note

When the poll bit is set in a received frame, NBF ignores the receive window and
immediately sends an ACK.

For example, an IBM LAN Server computer is a non-polling system that may have a send
window set to 1. If this the case, the registry parameter MaxIncomingFrames should be
decreased from its default of 2 to 1. If not, the non-Windows&nbsp;NT-based computer will
wait for an ACK from the Windows&nbsp;NT-based computer, which in this case will be sent
only when the T2 time limit expires.

NBF uses a receive window based on the value of MaximumIncomingFrames in the Registry.
The default value for MaximumIncomingFrames is 2, and this value does not dynamically
change. It must be manually changed by changing the parameter default value in the
Registry.

Note

When a Windows&nbsp;NT-based computer is using the MaxIncomingFrames receive window, it
may not always send an acknowledgment frame after receiving exactly MaxIncomingFrames
packets. This is because NBF will also wait until it receives an NDIS
ProtocolReceiveComplete before sending the ACK. However, when the Windows&nbsp;NT-based
computer receives POLL frames, it will ACK immediately (typically on return from
NdisTransferData (synchronous communications) or within ProtocolTransferDataComplete
(asynchronous communications).

NetBEUI Browser Does Not See TCP/IP Clients

Browsing on a computer running under Windows NT is based on a per protocol basis. In
other words, there is a master browser for each protocol. Computers running only the
NetBEUI protocol register with the master browser computer running the NetBEUI protocol.
Computers running only NetBEUI get the master browser list from the master browser running
NetBEUI. Because computers running only the TCP/IP protocol register with a master browser
running TCP/IP, these computers will not be on the master browser list from a computer
running only NetBEUI. 
</td></tr></table></body>

<SCRIPT language="Javascript">
<!--

// FILE ARCHIVED ON 19991005013019 AND RETRIEVED FROM THE
// INTERNET ARCHIVE ON 20051214083128.
// JAVASCRIPT APPENDED BY WAYBACK MACHINE, COPYRIGHT INTERNET ARCHIVE.
// ALL OTHER CONTENT MAY ALSO BE PROTECTED BY COPYRIGHT (17 U.S.C.
// SECTION 108(a)(3)).

var sWayBackCGI = "http://web.archive.org/web/19991005013019/";

function xLateUrl(aCollection, sProp) {
 var i = 0;
 for(i = 0; i < aCollection.length; i++)
 if (aCollection[i][sProp].indexOf("mailto:") == -1 &&
 aCollection[i][sProp].indexOf("javascript:") == -1)
 aCollection[i][sProp] = sWayBackCGI + aCollection[i][sProp];
 }

if (document.links)  xLateUrl(document.links, "href");
   if (document.images) xLateUrl(document.images, "src");
   if (document.embeds) xLateUrl(document.embeds, "src");

if (document.body && document.body.background)
      document.body.background = sWayBackCGI + document.body.background;

//-->

</SCRIPT>
</html>

- lock this page
- enter new password
- reenter same password

Send e-mail alerts to these addresses upon next save: