| 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 The LMB listens on the workgroup <1D> name for HostAnnouncement messages from members of its own workgroup. It also listens on the MSBROWSE<01> name so that it can hear DomainAnnouncement Browser Frame messages from other LMBs serving other workgroups on the same LAN (see Figure 20.3). The information collected from these announcements is used to build the Browse List. Figure 20.3. Multiple workgroups on the same LAN Two workgroups, each with their own Local Master Browser, share the same IP subnet. Node ABE will collect the local Browse List for the LINCOLN workgroup, and will also listen for DomainAnnouncement messages from node JOHNQ .  Announcing its workgroup to other LMBs representing other workgroups The LMB broadcasts DomainAnnouncement messages to the MSBROWSE<01> name to announce itself (and its workgroup) to the LMBs of other workgroups. Announcing itself to its own workgroup The LMB periodically sends a LocalMasterAnnouncement Browser Frame to the workgroup <1E> name. The Backup Browsers use this announcement to keep track of the LMB so that they can update their copies of the Browse List. Delegating responsibility to Backup Browsers The LMB is expected to promote Potential Browsers to Backup Browsers as the need arises. This is done by sending a BecomeBackup Browser Frame to the selected Browser node. The LMB should also provide the BB List in response to a GetBackupListRequest . Coordinating with the Domain Master Browser The LMB should query the NBNS for the workgroup <1B> name (which is registered by the DMB). There are two exceptions to this rule: -
B-mode nodes will not query the NBNS because remote LANs are outside of their scope and B nodes shouldn't talk to strangers. -
If the LMB is also the workgroup DMB then it doesn't need to query the NBNS to find itself. Otherwise, the LMB will periodically announce its existence to the DMB by sending a MasterAnnouncement Browser Frame . Once the LMB and the DMB know about one another, they will periodically request a copy of each other's Browse Lists. That's how the lists get merged across subnets. The LMB should also remember which Browse List entries were received from nodes on the local LAN, and which came from the DMB. The LMB is authoritative with regard to local nodes, but it must rely upon the DMB for everything else. If there are ever any conflicts, the LMB will favor its own local constituents. Responding to requests for a copy of the Browse List The LMB may receive queries for a copy of the Browse List from local Backup Browsers, the Domain Master Browser, or from everyday Consumers who simply want to display the Network Neighborhood. Participating in Local Elections Like all Browser nodes, the LMB listens on the workgroup <1E> name so that it can participate in local Browser Elections. Quite the busy civil servant.  | 