diff options
| -rw-r--r-- | source3/nameannounce.doc | 70 | ||||
| -rw-r--r-- | source3/namebrowse.doc | 51 | ||||
| -rw-r--r-- | source3/namedbresp.doc | 22 | ||||
| -rw-r--r-- | source3/nameelect.doc | 14 |
4 files changed, 157 insertions, 0 deletions
diff --git a/source3/nameannounce.doc b/source3/nameannounce.doc index d550a8380d..41759526c6 100644 --- a/source3/nameannounce.doc +++ b/source3/nameannounce.doc @@ -27,6 +27,41 @@ a primary domain controller for its workgroup (either by directed packet or by broadcast if it cannot resolve the domain controller name using DNS), which results in the same action as listed above. +------------ +NOTE FROM TRIDGE: + +PDC in the above should really be DMB (domain master browser). They +might be separate entities. + +I also propose a simpler scheme :-) + +If a DMB is not configured with lp_domain_controller() (perhaps +renamed to lp_domain_master()?) then just don't do master +announcements. Remember that most peoples networks are very simple and +don't need DMB capabilities. Those that do need them will have more +complex network topologies and they really need to choose themselves +which box will act as the "hub" for netbios name resolution. Doing it +via name queries will just lead to lag and propogation delays, because +if two parts of the net choose different DMBs then the data will be +very slow to propoogate. + +If a DMB is configured then just sent the master announcemnt to that +box! Thats all that needs to be done. Just send a udp 138 packet and +forget it. If the recipient is indeed a DMB (as it should be if the +config file is correct) then it should initiate a browse list sync +with us at some later time, but that is take care of by smbd and nmbd +doesn't even need to know it happened. + +Additionally, if a DMB is configured we need to sync our workgroup +list and server list with them occasionally. Note that this is only +time a non-DMB should do a browse sync, and it should only do it with +a DMB. Essentially WAN based netbios is just a simple star. There is a +DMB in the centre, and the individual master browsers for each subnet +talk to it, but never talk to each other. If they start talking to +each other then the network load will go as the square of the number +of machines, which will result in meltdown :-) +------------- + /************************************************************************* announce_host() @@ -103,6 +138,19 @@ the master browser, or primary domain controller, should respond with an ANN_GetBackupListResp browse mailslot containing the list of backup servers. +-------------- +NOTE FROM TRIDGE: I don't see why nmbd should ever send one of +these. The only reason I can see for any part of Samba sending one of +these is if we implement it in smbclient. + +This packet is used to request a list of backup master browsers from +the master browser. It is used by clients (not servers!) to spread the +browse load over more than one server. The only server that needs to +know what the list of backups is is the master browser, and as it is +also responsible for generating this list it will never ask anyone +else for it. +-------------- + /************************************************************************* sync_server() @@ -135,3 +183,25 @@ if the announce request is sent to ^1^2__MSBROWSE__^2(0x1) then browsers should respond with ANN_DomainAnnounce packets. this is untested. +----------- +NOTE FROM TRIDGE: + +I had great trouble getting machines to actually respond to this +packet. Either we have the format wrong or MS chose not to implement +it. + +Not implementing it doesn't break anything, it just means a new master +browser won't get a complete server list as quickly. + +Also note that this packet should be used as little as possible as it +could easily cause meltdown if too many servers used it. Imagine a +dozen samba servers on a net all sending this packet! You will get 244 +responses all within 30 seconds. now imagine 50 samba servers .... + +So I think we should restrict ourselves to sending this packet only if +we are already the master browser for a workgroup. We could send a +single "announce request" when we become the master, just to prime our +server lists. From then on the normal announce cycles should take care +of keeping it uptodate. +----------- + diff --git a/source3/namebrowse.doc b/source3/namebrowse.doc index 889abdacae..44b76dd43f 100644 --- a/source3/namebrowse.doc +++ b/source3/namebrowse.doc @@ -17,6 +17,36 @@ master browser. samba does not deal with becoming a backup master browser properly at present. +------------- +NOTE FROM TRIDGE: + +Yes, samba can send these either in its capacity as a DMB or as a +MB. There are only two situations: + +- If samba is a DMB then it should sync with the "local only" bit set +with any master browser that has sent it a "master announce". + +- if samba is not a DMB then it can only sync with the DMB, and should +not set the "local only" bit. + +Note that samba should never sync with other non-DMB servers when it +is not a DMB. + +Try to do a sync under any other circumstances is dangerous without a +multi-threaded nmbd. I have a print server at home that knows some SMB +and NBT, but if you try to sync browse lists with it then it clogs up, +and also clogs up nmbd while it times out the connection. If we +follow the above two rules then we can't get into this sort of +trouble as: + +- if we are a DMB and a master browser sends us a "master announce" +then it is expecting to receive a NetServerEnum SMB connection soon, +and must be capabable of handling it. + +- if we are not a DMB then we will only sync with the DMB, which must +be capable of doing this stuff or things are really in a mess :-) +-------------- + /************************************************************************* do_browser_lists() @@ -40,6 +70,24 @@ NetServerEnum api call. samba will only initiate this process if it is a master browser for this workgroup. +----------- +NOTE FROM TRIDGE: + +I'd actually prefer to skip the name query completely if we can +resolve the DMBs name via gethostbyname(). For the name query to work +we either have to have WINS working, or we need to know the broadcast +address of the network that the DMB is on. This makes us too dependent +on too many thing being right. + +If the gethostbyname() fails then sure, go for a normal name query, +but if it works then we have saved ourselves a lot of trouble and +gained a lot of robustness. + +This is best handled by a generic "resolve netbios name" routine that +tries DNS first then resorts to WINS or bcast if that fails. It also +needs to cache the results. +------------- + /************************************************************************* add_browser_entry() @@ -67,3 +115,6 @@ this function's scope) and have been in the cache for a while. this function is responsible for adding a new entry into the list of servers to sync browse lists with at some point in the near future. + + + diff --git a/source3/namedbresp.doc b/source3/namedbresp.doc index 66f5a22124..4913d39e0e 100644 --- a/source3/namedbresp.doc +++ b/source3/namedbresp.doc @@ -46,3 +46,25 @@ expected response queue. the number of expected responses is decreased. this function is responsible for adding the response record created by make_response_queue_record() into the appropriate response record queue. + +----------------- +NOTE FROM TRIDGE: + +namedbresp.c is interesting because it implements a novel way of +getting most of the advantages of a multi-threaded nmbd daemon without +the portability problems. + +The NBT specs (rfc1001/1002) talk about the 16 bit IDs in the packets +as being used to ensure that packets are unique, and to stop packets +from being confused. It suggests incrementing the ID by 1 each time. + +Instead Luke uses these IDs to identify individual threads of control +in nmbd. So when nmbd sends out a NBT packet as part of some complex +processing, it adds to a linked list the information required to +continue the processing when the reply comes in (or it times +out). When a reply arrives this list can be searched to find the +matching query and the next step in the processing can be carried out. + +This is really good stuff, and allows for much more complex behaviour +than was possible with the old nmbd. +---------------- diff --git a/source3/nameelect.doc b/source3/nameelect.doc index c03f044541..4b50c4a184 100644 --- a/source3/nameelect.doc +++ b/source3/nameelect.doc @@ -21,6 +21,20 @@ wide area network). (a wide area network is created when one or more servers on a broadcast-isolated subnet point to the same WINS server). +-------- +NOTE FROM TRIDGE: + +I'd say "domain master browser" not "WINS server" here. WINS doesn't +have much to do with browsing, it is the WAN varient of name +resolution. The name resolution and browsing functions of a netbios +network are almost entirely separate. Both grew out of systems that +could only be used on local networks. + +To adapt them to WANs, WINS was added for name resolution, and "domain +master browsers" were added for browse lists. It would be perfectly +possible to have a WINS server that doesn't even listen to UDP port +138. +-------- /************************************************************************* check_elections() |