Was this page helpful?
Your feedback about this content is important. Let us know what you think.
Additional feedback?
1500 characters remaining
Export (0) Print
Expand All

Registration and Propagation

The browser service relies on connectionless server broadcasts for host announcements which, by definition, are unreliable. When a server boots up, it immediately sends a host announcement datagram. Host announcement datagrams are then transmitted again after four and eight minutes. The announcement period then stabilizes, and a datagram is issued by default every 12 minutes.

Allowing for the loss of a few datagrams, it is reasonable to expect the server acting as the master browser to add the new server to its list within 12 minutes of the new server starting up.

note-icon Note

After the initial broadcast announcements and host announcements, new entries to the browse list of the domain master browser and new entries from the domain master browser to master browsers are transmitted by way of sessions. Sessions are connection-oriented and are, therefore, deterministic and more reliable.

Within another 12 minutes, the master browser connects to the domain master browser to obtain the domain-wide list, and at the same time, the domain master browser connects to the master browser and learns of the new server. Master browsers on remote subnets connect to the domain master browser at 12-minute intervals and soon learn of the new server. Within 12 minutes of the remote master browser learning of the new server, all of the backup browsers connect to their master browser and learn of the new server. Thus, in a multi-subnet environment, the maximum amount of time it takes for all clients within the domain to see the new server is 72 minutes. On a fully functional network where broadcasts and network use are well within safe parameters, this period might be approximately half as long.

Figure I.9 shows host announcement propagation.


Figure I.9 Host Announcement Propagation

Removing computers from the browse list can take longer. To allow for lost datagrams, the master browser does not remove a server from its list until three announcement periods have passed. If the server is not shut down gracefully, or if network connectivity is lost, the server remains in the master browsers list for up to 36 minutes. After that time, the domain master browser is notified to remove the server name from its list. Within another 12 minutes, a master browser on a remote subnet obtains the domain-wide list from the domain master browser, and within an additional 12 minutes, each backup browser on the remote subnet is notified to remove the server name from its list. Removing a computer from the browse list can take as long as 72 minutes to complete. If the server is shut down gracefully, the browser sends a single HostAnnouncement indicating that it is no longer acting as a server. Upon receipt of this datagram, the master browser immediately removes the server from its local list. On a healthy network, where broadcasts and network use are well within safe parameters, the removal of a server's name can take less than half as long.

A browser's server roles are not statically defined, as they are with WINS or DNS, but are instead dynamically defined with periodic elections. As a result, determining the flow of communication used by the servers to provide the browse list to a specific client can be rather complex. The distributed design of the browser service relies on servers staying active on the network and, thereby, maintaining their browser roles consistently over time.

If a master browser is gracefully shut down, it forces an election and a new master browser is established promptly. The quickest conversion occurs when a backup browser, which already has a fully populated list, wins the election.

If a server, acting as the master browser for a network subnet is not shut down gracefully, or if the ForceElection datagram was lost, there may be a delay of several minutes before browsing is active on that subnet again. If a client cannot find a master browser by issuing the GetBackupListRequest datagram, it forces an election. If a client does not request a browse list, it can take up to 12 minutes before a backup browser discovers that there is no master browser. When it does, it forces an election, and within another 12 minutes, browsing is again enabled.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
© 2015 Microsoft