Multi-WINS behavior.

[Christopher R. Hertel]

:
> Have fun!  In particular, I wish you luck solving SGI's chicken-and-egg
> problem.

If you magically guess that there are toolks hidden in a partition of the 
CD that might be documented but since you can't get to the on-line 
documentation because you don't have a system it doesn't matter then you 
can guess which SASH image is correct for you and try to find a copy of 
fx that will let you partition the drive.

That is, it only took a few hours to find the right files on the CD and 
get them to work.

> Thinking some more, I believe a simpler strategy would be to maintain a 
> single list, but dead servers are flagged as such.  Whenever you need
> to do a lookup, just skip dead servers and try the live ones.
> Periodically you can try to revive the dead ones.

Yep.  That's pretty much where I was going with it, after I thought about 
it a bit.  The delay in reading my mail means you probably came up with 
it first.

> > If the servers are synced, then there is no need to prioritize them.
> 
> As Elrond noted, you might want to prioritize by network topology.

Right.  I was thinking of name space, though.

> So far from your message what I get is that the only known disadvantage
> to sending updates to every WINS server every time is the increased
> traffic (both yours and the possible syncs).  Is this right?  You are
> saying you want the complex solution just to avoid the excess traffic?

Sending to every WINS server is a bit complex, imho.  If I'm going to
implement that feature I'd like it to be very clear and very straight
forward. 

> That is a basic problem with NetBIOS names in general, as you well
> know.  *There* *is* *no* *hierarchy*. 

Different meaning of hierarchy.  I was thinking in terms of search
precedence. 

> There is only the One True
> Namespace, and if you want to advertize to multiple WINS servers, you
> are explicitly consenting to the problems caused by the possibility
> that there might in fact be multiple namespaces.

Even this isn't quite true.  Consider a subnet with both B and H nodes, 
and a WINS server somewhere else.  The B nodes are in a subset of the 
namespace seen by the H nodes.  If a B node tries to claim a name that 
belongs to a node in another subnet, the registration will succeed.

Now, if MS had followed the RFCs, there would be no H nodes.  M nodes
query the local LAN before they query the NBNS (WINS) server so local
names would take precedence.  H nodes query the NBNS server first, so... 

Now, what happens if we add multi-membership or, perhaps, a WINS Proxy 
pointing to yet another WINS server.  OUCH! OUCH! OUCH!  ...sorry, 
something inside my brain just had a spasm.

> In other words, you'll eventually have problems anyway. 

...which always justifies making them worse...  ;)

> Say you have
> two WINS servers with disjoint namespaces, WINS1 and WINS2.  There are
> two machines FOO, one registered with each server.  And you specify
> that in case of a conflict you want the name from WINS1.

How do you make that specification?

> OK, what if WINS1 goes down?  Then you get the wrong answer.  I can't
> think of any way to prevent this.

Right.

...except... except if WINS1A is synced to WINS1 and we support failover. 

> The only way around this is to accept the fact that NetBIOS names have
> no hierarchy, and actively prevent collisions, either by technical or
> social means.

There are no technical ways that I can think of to prevent the collisions 
other than syncing all of the WINS servers.

What I really don't understand is this:  If you *want* multiple name
spaces and you're *going* to do the work of preventing collisions anyway,
why not just sync the WINS servers.  Yes, yes, I understand that Samba
doesn't do this yet.  I really, really did ask if anyone wanted this a
while back and really really didn't get much of a 'hurrah' from the crowd. 

> > All of the Windows systems with which I've worked assume failover.
> > Note that I haven't worked with W/98.
> 
> Right, Microsoft accepts this cold, hard reality. (:

Don't follow...

> > > > Obviously, if the administrator has specified the multiple
> > > > servers in smb.conf, it means he considers the Samba server to be
> > > > part of the namespace of each wins server.  So why not make it
> > > > explicit and just register with everyone every time?
> > 
> > That's not obvious.  It may be that the administrator wanted failover.  
> 
> If you put a WINS server in smb.conf, you had best be prepared for your
> box registering itself with that server.  (If doing so would cause
> problems, you shouldn't list that WINS server.)  What difference if it
> does so all the time or just when the other servers are down?

If the servers are synced, then the difference is that registering with 
all of them could cause extra traffic (it might even cause a name 
conflict problem, but I doubt it--worth testing, though).

If the servers are not synced then registering with each is what you want. 

> I don't see how one can argue that you want to be able to use a
> particular WINS server but not register yourself with it.  

You would not register with it if it is the failover secondary and the 
primary is still up.

> What is to
> be gained by doing this, aside from the network traffic issue?  (And is 
> that a major consideration?  How much increased traffic is involved?)

No one has tried it, so there's no real data on what would happen.

> > ..and replication traffic.  If WINS-A replicates with WINS-B and
> > WINS-B replicates with WINS-C and you register with all of them, then
> > they will all be sending update messages to each other.  Urq.
> 
> If you register with WINS-A then with WINS-B, but the two are already
> synced, wouldn't WINS-B detect that you're giving it the same
> information it already has?  If so, it shouldn't cause an update back
> to WINS-A.  Or am I assuming too much from the servers?

Again, I don't know what actually happens.  In the worst case, it might 
cause a naming conflict.

> > The traffic probably won't be that bad, but geez what a mess.  Oooh,
> > and I haven't considered the implications for Browsing yet.
> 
> Me neither, I hate browsing.  It confuses me like you wouldn't believe.

Grin.  Well, we've got something else in common then.

> > Ah, but that *is* the problem!  If I implement failover without
> > multi-membership, then you can still point to two WINS servers but
> > the second one will only receive queries and registrations if the
> > first one fails.  Thus, multi-membership doesn't work.
> 
> Right.
> 
> > If I implement multi-membership without failover, then Samba winds up
> > registering multiple times in the same WINS namespace, and queries
> > that get a 'name not found' are repeated to sync'd WINS servers from
> > which they get the same answer.
> 
> Regrettable, to be sure.  Still better than current latency for
> negative lookups, though, wouldn't you say? (:

Yes, but I fixed that.  :)

> > The suggestion I made above specifies multiple WINS name spaces and
> > provides for failover within those.  This is a much better way to
> > handle the combination of the two features.
> 
> If you're willing to code the complexity, I can now see that it does
> have some advantages.  Only by providing an optimization, though, not
> increased capability (vs. the simpler suggestions by Elrond and me).

No, you actually need to code for both if you're going to do both.  You 
need to specify a set of namespaces and for each namespace a list of 1 or 
more WINS server.  That list is your failover list.  The namespace list 
is the ordered name-space search/registration list.

Chris -)-----

-- 
Christopher R. Hertel -)-----                   University of Minnesota
crh at nts.umn.edu              Networking and Telecommunications Services

    Ideals are like stars; you will not succeed in touching them
    with your hands...you choose them as your guides, and following
    them you will reach your destiny.  --Carl Schultz