The Browse Service has two types of clients:

Think of it in terms of the classified advertising section in your local newspaper. Classifieds are available to people who have something to sell as well as to people who are looking to buy. Both of these are clients of the newspaper.

In some of the available documentation, systems that wish to announce services via the Browse List are referred to as “Non-Browser Servers.” That’s really icky terminology, since those systems could be [Potential | Backup | Local Master] Browsers as well. We will refer to nodes that announce services as “Providers,” without trying to straighten out what kind of Browser nodes or SMB servers they may or may not be. To add a sense of symmetry, we will use the term “Consumers” to identify the other kind of Browse Service clients — those that want to find services on the network.

So, for our purposes:

We promised to introduce the neighbors one at a time. Let’s start with the Providers.

Providers

Providers announce themselves to the Local Master Browser by periodically broadcasting a message called a HostAnnouncement Browser Frame. The message is sent as an IP broadcast so any NBT node could listen in, but the NBT destination given in the message header is the workgroup<1D> name, so the LMB is obviously the intended recipient.

When a node first starts up, it generally announces itself once per minute. After it has been running for a while it will slow down, typically sending an announcement once every 12 minutes. Different implementations behave differently, of course, but the suggestion is that the Provider start with a delay of one minute and double the delay until it exceeds 12 minutes, at which point it should settle on 12 minute intervals.

If a Provider stops announcing itself, its entry in the Browse List will (eventually) time out. The time out formula generally given in the documentation is three times the last known announcement period. In testing, however, some systems reported the Periodicity value incorrectly so it is probably safer to assume an announcement period of 12 minutes and use a fixed timeout value of 3 × 12 = 36 minutes.

Providers can also remove themselves from the Browse List by sending a HostAnnouncement message with an empty list of services. This indicates to the LMB that the host is no longer providing any services. If possible, a Provider should send an empty HostAnnouncement Browser Frame when it shuts down.

Some Technologies Shouldn’t Mix Alert

When cable television companies first decided to get into the Internet Service Provider (ISP) business they ran into an unexpected problem. A lot of PC vendors were installing Windows preconfigured with SMB filesharing turned on and no passwords by default. When these PCs were connected to the cable Internet service, they would start announcing themselves to one another. People up and down the block found that they could both see and access each other’s systems, view files, copy software...

Now that’s a Network Neighborhood.

Consumers

It is important to be polite when dealing with your local government. The LMB is your neighbor, after all, and the time it spends handling the Browse List is volunteer time (unless it is also the appointed DMB). It may have other responsibilities as well — spouse, kids, day job as a word processor or fileserver... If everyone in the neighborhood is constantly asking for help, the LMB may wish that it had never been elected.

The polite thing for a Browse Service Consumer to do is to ask the LMB for a list of Backup Browsers. We will call this the “BB List” (short for Backup Browser List) to distinguish it from the Browse List. The Consumer should keep track of the BB List so that any time it needs an updated copy of the Browse List it can query one of the Browsers on that list. That’s how the workload is distributed in the Network Neighborhood.

Keeping in mind that Browse Service duties are cumulative, the LMB will probably include itself in the BB List. On small LANs there may not be any Backup Browsers hanging around, so the LMB may be the only Browser listed in the BB List.

The request for the BB List is sent as a broadcast NBT datagram. The request message, as indicated in Figure 20.1, is known as a GetBackupListRequest Browser Frame. If the Consumer does not receive a response to the initial request, it should try again a couple of times. If no reply is received at all, the client may call for a new election — once only — and then try again to get a BB list. It may be the case that there are no Potential Browsers on the LAN at all, resulting in no LMB and no local Browse List. Continually calling for new elections in this situation would be futile (and rude).

Node ZOKI is a Backup Browser, and node ROWENA is the LMB. A Browse Service client broadcasts a request for the Backup Browser List (BB List), and the LMB responds (unicast) with a list of active browsers.

Figure 20.1. Requesting the Backup Browser list

Let’s hope, however, that there is an LMB and that it does respond. The reply from an LMB is known as a GetBackupListResponse Browser Frame. It is not sent as a broadcast. Instead, the response is sent back to the requester in a unicast datagram (in NBT terminology, a DIRECT UNIQUE DATAGRAM).

...and that’s what it takes to find out where copies of the Browse List are kept.

At this point in the proceedings the Consumer has obtained the NBT name of a Browser (either a Backup Browser or the LMB) and is ready to send a query to obtain the Browse List (see Figure 20.2).

Earlier, the Consumer node learned that ZOKI had a copy of the Browse List. The Consumer uses the Remote Administration Protocol to request a copy of the Browse List.

In this example, nodes ZOKI and DOPS are Providers, advertising services via the Browse List.

Figure 20.2. Requesting the Browse List

This step is a little more complex than the previous ones. The Browse List might be very large, in which case (recalling the limitations of the NBT Datagram Service) an NBT datagram might not be big enough to hold it all. So instead of using the Datagram Service the Browse List query is sent using the Remote Administration Protocol (RAP) which rides on top of the SMB_COM_TRANSACTION message (aka SMBtrans). SMBtrans, in turn, allows for data transfers of up to 64K.

It’s time to meet your elected officials.

All Browser nodes register the workgroup<1E> NetBIOS name. The Local Master Browser, as you already know, identifies itself by registering two additional NetBIOS names: workgroup<1D> and MSBROWSE<01>. NetBIOS names represent communications end-points — services or applications that are using the NetBIOS API to listen for connections or messages. On the other side of these particular names there is software waiting to hear the chatter of the Browse Service.

The LMB has the following duties.

Maintaining the master copy of the workgroup Browse List for the local IP subnet

Announcing its workgroup to other LMBs representing other workgroups

Announcing itself to its own workgroup

Delegating responsibility to Backup Browsers

Coordinating with the Domain Master Browser

Responding to requests for a copy of the Browse List

Participating in Local Elections

A Potential Browser becomes a Backup Browser in one of three ways.

At the time that the Browse Service was created it may have been reasonable to be concerned about one computer bearing the brunt of all of the client requests, particularly on a LAN with a very large number of nodes. Today’s computers are capable of handling the load and their own work without breaking a sweat. It would take an effort (a purposeful Denial of Service attack, for instance) to cause the LMB any real trouble.

Browser roles are cumulative, as we keep saying, so the Domain Master Browser is also the Local Master Browser for its subnet and it must handle all of the duties of an LMB. One such duty is participation in local Browser Elections. Of course, since the DMB is the appointed workgroup president it is expected to win the election — which it will do because the election is rigged. More on that when we go into detail regarding the election process.

The DMB listens on the workgroup<1B> name for (unicast) MasterAnnouncement messages from Local Master Browsers on remote subnets. It keeps track of these announcements and, periodically, contacts the LMBs and asks for a new copy of their local Browse List. The DMB merges the local Browse Lists collected from the various LMBs (including its own) into a master Browse List for the entire workgroup. The LMBs, in turn, will periodically query the DMB and add the remote entries collected in the workgroup master list to their own local Browse Lists. That’s how local LANs get a complete copy of the combined workgroup Browse List.

The key to making this all work is the NBT Name Service, the NetBIOS Name Server (NBNS) in particular. The scattered LMBs use the NBNS (aka WINS server) to find the workgroup<1B> name, which is registered by the DMB. Without that, cross-subnet browsing would not work because the LMBs would be unable to announce themselves to the DMB, and would also be unable to request copies of the DMB’s master list.

Note that B mode NBT nodes do not talk to the NBNS and, therefore, cannot find a remote Domain Master Browser. That’s okay, though, because the scope of a B mode NBT LAN is limited to the local IP subnet anyway. Even if a B node could do cross-subnet browsing, it wouldn’t (shouldn’t) be able to connect to a server on a remote subnet.

In contrast, P nodes must transact all of their Browse Service business directly with the Domain Master Browser. The NBT Scope available to a P node is the set of names it can resolve via the NBNS. It doesn’t do broadcasts, so the only Browser node that it can find is the DMB because the DMB is the only Browser node with a name that can be properly resolved via the NBNS. M and H nodes have the best of both worlds. They can send broadcasts and use the NBNS to resolve names.

Now that you have a basic idea of how this stuff works, think about what might have happened if Microsoft had correctly implemented group name handling in their WINS implementation and had also provided a working NetBIOS Datagram Distribution Server (NBDD). If they had done that, the broadcast datagrams used by the Browse Service — the announcements and election requests and such — would have reached the entire extent of the virtual NetBIOS LAN even if it spanned multiple subnets, even across WAN links and such. For better or worse, that would have changed the design and workings of the Browse Service entirely.

Browser elections are fun to watch. They have more in common with the noise and chaos of a party convention than with an actual election. The process is something of a shouting match, and the winner is the last one left shouting at the end.

Starting an election is a lot like picking a fight. Some punk computer somewhere on the LAN sends out a challenge, called a RequestElection Browser Frame. The message lets all of the Potential Browsers on the LAN know how tough the sender thinks it is (see Figure 20.4). The Potential Browsers respond by broadcasting their own RequestElection messages, also declaring how tough they think they are. The Potential Browsers don’t really want to fight about it, though, so when they hear a RequestElection message from a node that is tougher than they are, they shut up. The specifics of the election criteria will be covered when the we study the browser frames in detail.

The Potential Browsers announce their strengths by sending a RequestElection message. The strongest candidate must repeat its announcement several times (typically four) to ensure that all challengers have acquiesced.

Figure 20.4. Browser elections

Just to complete the fighting analogy, each transmission of a RequestElection message during a browser election is called a “round.” There are typically four rounds because the eventual winner of the election will repeat its RequestElection message four times to ensure that all of its challengers have given up. Once the winner is confident in its victory it sends a LocalMasterAnnouncement Browser Frame, which has two purposes. First, it lets all of the Backup Browsers know where to find the LMB. Second, the LocalMasterAnnouncement message announces the end of the election. Any further RequestElection messages heard on the wire will signal a new Browser Election.

Elections can be forced by sending an empty RequestElection Browser Frame — that is, one that announces the sender as being a complete wimp. All of the Potential Browsers on the LAN will have better credentials, so they will try to respond. Elections may be called when a Consumer can no longer find the LMB, or when a new node joins the workgroup and thinks that it has what it takes to be the LMB. When a Domain Master Browser starts up, for instance, it will always call for elections (since it must take over the role of LMB).

The RequestElection message is another NBT broadcast datagram. It is meant to be sent to the workgroup<1E> name but it turns out that many clients will accept this message if it is sent to the MSBROWSE<01> name as well, so you can actually cause all of the workgroups on a single subnet to hold elections at the same time.