20.1 Browse Service Clientele

The Browse Service has two types of clients :

• systems that wish to announce services, and

• systems that wish to find services on the network.

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:

• A Provider is any node that wishes to announce (via the Browse List) that it has services available.

• A Consumer is any node that wishes to get hold of a copy of the Browse List so that it can find services.

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

20.1.1 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 x 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 I nternet S ervice P rovider (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 .

20.1.2 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 B ackup B rowser L ist) 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).

Figure 20.1. Requesting the Backup Browser list

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.

Let's hope, however, that there is an LMB and that it does respond. The reply from an LMB is known as a GetBackupList Response 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).

Figure 20.2. Requesting the Browse List

Earlier, the Consumer node learned that ZOKI had a copy of the Browse List. The Consumer uses the R emote A dministration P rotocol to request a copy of the Browse List.

In this example, nodes ZOKI and DOPS are Providers, advertising services via 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 R emote A dministration P rotocol (RAP) which rides on top of the SMB_COM_TRANSACTION message (aka SMBtrans). SMBtrans, in turn , allows for data transfers of up to 64K.