Re: NetBeui relationship to other protocols

[Kirill M Katsnelson <[e-mail]>]

Milton,

You're talking about Windows NT/Windows 95/Windows for Workgroups network,
aren't you? I will refer to them as to 'LM nodes', where LM stands for LAN Manager,
a Microsoft product that introduced network layer used now by Microsoft networks.

In general, NetBEUI is not needed to be installed. You may be happy with TCP/IP
only ntework. Although, NetBEUI is claimed to be fastest protocol for single
cable segment (a part of network that allows broadcasts to be heard by all nodes,
say, Ethernet or FDDI segment). NetBEUI does use 16-bytes addresses, and these
addresses traditionally consist of uppercase latin characters, so they are human-
readable. Since NetBEUI does not have a concept like TCP port or IPX socket number,
the last byte of 16-byte address usually reserved for this task. In Microsoft networks,
first 15 bytes of NetBEUI address are computer or domain name, appended with zero bytes
to 15-byte length. So NetBEUI name are not 'resolved' to addresses; they are
addresses themselves.

Atlhough you may not have NetBEUI installed, a computer or domain is identified
by its name anyways. This name IS a NetBEUI address, so NetBEUI addresses are
around here even if there's no NetBEUI.

NetBEUI is a session-oriented protocol. You may use NetBEUI over NetBEUI, and
NetBEUI over IP. The latter case allows the protocol to be routeable thus
allowing LM nodes to communicate over IP router. In this case, a problem of
resolving NetBEUI addresses into IP addresses arises.

In traditional environment (RFC1002), a node (named trying to establish a session
sends a broadcast with a name of its proposed party, then waits some predefined time
for that party to respond. This method does not allows to establish a connection in
IP network since broadcasts are not travel through routers. Node acting like that
is called 'b-node', where b stands for 'broadcast'. NetBEUI/NetBEUI allows only this
method of resolving names, and NetBEUI/IP also respects it.

To resolve this problem, special protocol exists. It is called WINS, Windows Internet
Name Service. Each node participating in such a resolution know IP address of a
WINS server. When a node comes up, it REGISTERS its name and IP address with WINS
server. When a node want to connect to another node, it ASKS WINS server for party's
IP address. Node that knows this method of resolving names is called 'p-node', for
'point-to-point'. This method is for NetBEUI/IP only. 

WINS for NetBEUI names/addresses can thus be compared with DNS for Internet names,
although it is dynamic.

As for the additional impact on performance, you see that establishing a session
requires one query of the WINS server. WINS servers allows also data replication
between servers, so you may wish to have two identical (in terms of contents)
WINS servers on both sides of the WAN; in this case, no queries travel across
WAN, although replications (changes in WINS database) do; these changes include
only information on nodes being registered and unregistered. So, if computers
on sides of the WAN are rarely turned off, this method is much more preferred
than running queries across WAN.

And, finally, all this concerns with Micorosft, or NetBEUI names of computers
and domains, and completely not connected with neither their Internet names
nor with their ability to use WinSock applications. So, if you have a computer
with LM name BOX.A and internet name boxa.subdom.dom, you have not to be able
to share its disks, or to logon to it, to be able to FTP to it. For 'Internetizing',
you need TCP/IP - and nothing more.

Hope this helps,

Kirill.

Some time ago, Milton Clark wrote...
>This is an open call for assistance. The Tribune corporation is in the process of implementing 
>corporate wide Internet access for all of its business units. I participate on both the NDS and 
>DNS standards committees. We have been unsuccessful in finding any working papers from Microsoft 
>regarding how domain names are shared,if at all, between NetBeui and IP, or any other protocol 
>for that matter. (NetBeui is our concern). We need to find out if NetBeui is needed as an install 
>protocol, and what the impact of this additional noise is to our WAN.
>
>I would appreciate any information on this subject.
>
>Sincerely,
>
>Milton Clark
>Everyday Learning Corp.
>[e-mail], [e-mail] (in effect as of 2/28/96)
>
>--
<---------------------------------------------------------------------->
< Kirill M Katsnelson,  Software Engineer,   Owner of Elipromm Priv Co > 
< EMAIL: [e-mail]           HOME PAGE: http://www.bhs.com/kkm/ >
< Elipromm's Canned Knowledge page: http://www.bhs.com/kkm/Canned.html >
<---------------------------------------------------------------------->