The solution to browser sins
Windows NT does a lot of shouting, and that has to stop. The browser produces too much network chatter. For those just joining us, I've spent the past couple of months looking at Active Directory's benefits. I've been identifying the current system's deadly sins, and showing how Active Directory corrects them. This month, I'll explain how NT 5.0's Active Directory gives the browser a makeover.
The Browser service provides a central location to list available network resources. You've seen the browser in action when you open up Network Neighborhood in Windows 95 or NT 4.0, or when you click Drive/Connect Drive from Windows for Workgroups (WFW) or NT 3.x's File Manager. The browser is a list of available servers in your workgroup or domain—I'll define server in the simplest sense as something that can share data, which can mean anything from an NT Server to a WFW machine—and the resources on those servers such as shares and printers. For example, when I open up my Network Neighborhood, I see all the servers in my Research workgroup. If one of those servers is MYBOOKS, and I double-click that server, I'll see all the shares available on that server.
Sins of the Browser
This feature of Microsoft networks, a window on the network that's dynamic, is neat. Network Neighborhood shows you the servers that are up and running. To see what's not neat about it, however, let's look at how the browser works. (For more information about the performance problems browsers cause, see George Spalding, "Too Many Servers Spoil Network Performance," August 1997.) The browser is complex, so I'll have to oversimplify in some cases. My first two simplifications will be to assume that you're running only one network protocol and that you're not using the Windows Internet Name Service (WINS).
| "Windows NT does a lot of shouting, and that has to stop." |
In each workgroup on each network segment, one server is elected (through a process I'll explain in a minute) as browse master. The browse master keeps a list of known servers on that segment, the browse list, and presents it to clients requesting connections to network resources. When you open up Network Neighborhood, your computer asks the browse master for the list of servers in the workgroup. Your computer then shows you that list of servers. If you double-click a server to drill down to the list of shares offered, the Network Neighborhood on your computer does not ask the browse master for that list of shares; rather, it communicates directly with the server in question, requesting that list of shares from the server.
But this process leaves several questions unanswered. First, how did your computer find the browse master? Second, how does the browse master know what servers are out there? And third, how was the browse master elected to that post?
When you start up your computer, it needs to find the browse master for its segment. So it calls the browse master by a NetBIOS name composed of the workgroup name and a hex value <1D>. (For an explanation of NetBIOS names, see "Knowing the Angles of NetBIOS Suffixes," February 1997.) For example, my workstation is in a workgroup named Research. When I start the workstation, the network client software finds the browse master on my segment for the Research workgroup. It shouts, "Hey, is anyone here named RESEARCH<1D>?" The browse master—let's call it BRAINIAC—responds to my workstation, saying, "Yes, I'm RESEARCH<1D>." My workstation doesn't immediately ask for the browse list. The browse master is busy, and it might not respond to requests as quickly as I'd like. So the browse master deputizes one or two other machines to be backup browsers. Supposedly, if you have more than 15 workstations on the segment, the second backup is anointed, but I've never checked.
Suppose I have one backup browser named LUTHOR. My workstation now knows that the browse master is BRAINIAC, and the first thing my workstation asks BRAINIAC is, "What are the names of all of the computers that I can get a browse list from?"
BRAINIAC responds, "You can get a browse list from either me or LUTHOR." My workstation decides to look to LUTHOR for its browse information. I don't know why, but workstations usually choose a backup browser. Anyway, my workstation then connects to the IPC$ share on LUTHOR and requests the list of servers in the workgroup on this segment. LUTHOR obliges my workstation with this information.
Now, how do BRAINIAC and LUTHOR know all this information about your network? When a server comes up, it looks for the local browse master. It broadcasts to locate the <1D> machine. Ugh, more broadcasts! The browse master, BRAINIAC, responds, and the server announces itself to BRAINIAC. Then, for good measure, the server re-announces itself every 12 minutes to the browse master, causing more network traffic. (It might do extra announcements if the machine's status changes.) Every 15 minutes, BRAINIAC updates LUTHOR on the latest browse information. (The manuals say that the second announcement is 1 minute later, the third 2 minutes later, the fourth 4 minutes later, the fifth 8 minutes later, and all subsequent announcements at 12-minute intervals. However, a look at the Network Monitor disproves this information.) This regular broadcasting leads to an odd situation wherein you open up the Network Neighborhood but your computer isn't there because the client part of your network software is getting its browse list from the backup browser. Because LUTHOR might be up to 15 minutes behind BRAINIAC, LUTHOR might not yet have you on its list, even though BRAINIAC does.
The browser involves another set of broadcasts: browser elections. BRAINIAC and LUTHOR were chosen to be the browse master and backup browser by their peers, the other servers on the segment. In a browser election, a server powers up and broadcasts to find the browse master. If no machine responds or if the machine that responds is running a lower-octane operating system (for example, if an NT Server powers up and discovers a WFW browse master) the newly-started machine sends out an election packet. The election packet says, "I think I'm the best qualified machine to be the browse master. Here are my qualifications," and includes a list of information about the computer, such as the operating system it runs, whether it's a WINS client, whether it has a value set in its Registry to request election preference, whether it's a Primary Domain Controller (PDC), and how long the machine has been up. Other servers on the segment compare their characteristics to those in the election packet and, if they realize that their qualifications are superior to those of the candidate, they broadcast election packets of their own. When the election blizzard settles down, the last candidate wins. And to top off this traffic, every 15 minutes the browse master broadcasts a workgroup announcement, announcing the existence of a workgroup named Research to all.
How does Active Directory improve on this situation? The answer is a mixed blessing, with a lot of improvement but one downside.
The Active Directory Solution
The current Security Accounts Manager (SAM) database contains only the names of users and NT machines in a domain. But son of SAM, Active Directory, contains lots of information about machines, including what shares those machines have. Whereas NT 3.x and 4.0 build that database of shares (i.e., the browser) dynamically, Active Directory gets its information when a server publishes information to the Active Directory. Active Directory would find out that server MYBOOKS has a share called DATA when MYBOOKS tells that information to a local Active Directory server. With NT 5.0, however, you will no longer think in terms of shares with names like \\servername\sharename. All shares will have names like \\domainname\sharename through the Distributed File System (Dfs). You'll be able to move shares around like home directories from server to server without modifying software on the client.
Your client software won't do any broadcasts to find a local browse master, because you won't have any browse masters. You'll have Active Directory servers, and your computer doesn't need to broadcast to find them. It will look them up in Domain Name System (DNS). Servers won't re-announce themselves to the Active Directory controllers every few minutes, so you'll have less network traffic. And browser elections will be a thing of the past, meaning that NT 5.0 networks will be less chatty. (Well, that's the theory, anyway; I imagine that the current browsing system will continue to live in tandem with Active Directory as long as we have WFW, Win95, and NT 3.x and 4.0 machines on the network.)
I mentioned that the Active Directory solution has a downside. Currently, the browse list is dynamic and is constantly being rebuilt on the fly. The published information in Active Directory is more static, so some items in the Active Directory will be visible—they'll be in the directory—but not available. That is, their servers might be down. To stay more up-to-the-minute, Active Directory would need to periodically do some ping or Simple Network Management Protocol (SNMP)-type pulse-taking. Microsoft tells me that it's not planning to do any pulse-taking, and for good reason: Pulse-taking just creates more network chatter.
With Active Directory, you'll have no more browser, elections, and concomitant broadcasts. I'll pick up next month with more of NT's deadly sins and the Active Directory solution.
