Samba Part 5
Under NBT, NetBIOS sessions are created on top of TCP sessions. Here's what happens when node FRED tries to establish a NetBIOS session with node ETHEL:
FRED uses the Name Service to find the IP address of node ETHEL.
FRED establishes a TCP connection to TCP port 139 on node ETHEL.
FRED sends an NBT SESSION SERVICE REQUEST packet via the TCP connection. The request contains the NetBIOS name of the source node (FRED) and the NetBIOS name of the target node (ETHEL).
The SESSION SERVICE REQUEST can be rejected if ETHEL isn't home (that is, the software that registered ETHEL is not actually listening or the name was never registered at all). If the request is accepted, the two systems may send NetBIOS session packets via the TCP tunnel until the connection is closed.
The Session Service is the simplest of the three NBT services. It does not need to worry about distributing messages to all owners of a group name since it is inherently a point-to-point service. It is, however, the transport for SMB filesharing, so it is of particular interest to us.
The Sum of the Parts
The purpose of NBT is to provide an emulated PC-Network LAN. It does not matter if the participating nodes are scattered across the Internet. If they share the same NetBIOS name space, they are on the same virtual wire. It is the Name Service that is responsible for creating and maintaining the name space, so the Name Service defines the virtual LAN.
The NetBIOS API is the gateway to that virtual LAN, but non-Windows systems generally avoid using that interface. Instead, they typically craft the NBT packets and handle TCP and UDP transfers directly. This, unfortunately, can give the impression that SMB and its associated services are all IP-based, which really isn't the case. Remember that the NetBIOS API has been implemented on top of lots of other protocols too.