Multi-WINS behavior.

[Peter Samuelson]

[Chris Hertel <crh at nts.umn.edu>]
> My SGI went belly-up this morning following a normal reboot.  I had
> to run out and get another disk and tomorrow I get to re-install
> IRIX.  I'm not sure that the disk is completely bad (I can get to the
> volume header), it's just that XFS is panicing because it can't read
> the root block.

Have fun!  In particular, I wish you luck solving SGI's chicken-and-egg
problem.  The IRIX installation process involves booting from a CD
which copies a filesystem image into your swap space and bootstraps the
image, which proceeds with the install.  This doesn't work quite so
well if your disk doesn't come pre-partitioned with an IRIX swap space.
(Most drives don't, obviously.)  I don't know what SGI was thinking,
but my theory is that they want you to buy all your disks from them.

The only solution I've found is to put the replacement disk into a
second (still-running) SGI and partition it there (`man fx')....


> What I have coded so far is fairly simple.  There's a "live" list and
> a "dead" list.  When a WINS server does not respond at all, it is
> moved to the dead list and the next server in the live list is tried.
> This repeats until the live list is exhausted.  If this happens, then
> the particular name query or registration will fail.

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.

This could easily avoid the infinite loop you are worried about.

> If the servers are synced, then there is no need to prioritize them.

As Elrond noted, you might want to prioritize by network topology.

> I brought it up because there really is room for debate.  Failover
> and membership in multiple *separate* WINS spaces are two very
> different things. Failover assumes that all of the WINS servers are
> sync'd.  Multi-membership assumes the opposite.

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?

> For multi-membership to work, the client station must register in
> *each* of the WINS namespaces.  Also, there must be a hierarchy to
> the WINS namespaces so that duplicate names can be resolved in a
> known fashion.  If I'm searching for node "SERVER", and there is a
> node "SERVER" listed in two WINS spaces, how do I know which to
> choose?

That is a basic problem with NetBIOS names in general, as you well
know.  *There* *is* *no* *hierarchy*.  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.

In other words, you'll eventually have problems anyway.  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.

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

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.

> 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. (:

> > > 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?

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.  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?)

> ..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?

> 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.

> 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? (:

> 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).

Peter