Multi-WINS behavior.

[Christopher R. Hertel]

I need some votes from folks regarding behavior of the WINS fail-over.

The way it's "supposed" to work (keeping in mind that this isn't in the 
RFCs) is that a client will use the primary WINS server until the primary 
fails.  When that happens, the client switches to the secondary.

The patch that was submitted queries the primary.  The primary may send 
an answer, it may send a Negative Query Response, or it may simply be 
dead by the side of the road attracting flies.  The behavior implemented 
in the patch is to try the secondary in either of the latter two cases.

The problem is, once again, a namespace issue.  (Hear me out...you, in the
back, put those torches away!  I'm just tryin' to get a little feedback.)

If the WINS servers are sync'ed:
- Then you would not check the secondary if you got a Negative Query 
  Response.  Since the two are synced, the secondary will only give you 
  the same answer.
- If you got no answer from the primary you'd assume that it's dead and
  start using the secondary instead.

This is fairly clean.  However, if the WINS servers are not synced:
- Then when you switch from primary to secondary you enter a new
  namespace.  Your machine isn't registered in the new namespace, 
  so your name or the name of some service you rely upon may be missing.
  Worse, it may have been taken by some other machine.

The above is what happens in a failover situation.  If the WINS servers 
are not synced, then failover doesn't work.  You've still lost your 
primary namespace.

...but... The other way to do this is to think of it as a way to join 
multiple name spaces.  Doing so seems perfectly sane to me.  Here's how 
it would work:
- The 'wins server' parameter would allow you to provide a list of WINS 
  servers.  When registering a name, Samba would send separate 
  registrations to each of the listed servers.  Queries would proceed in 
  the order in which the WINS servers were listed.  So, if you were 
  looking for a machine named "FILBERTNOODLE" you would query the WINS
  servers in turn until you got an answer.

The problem with this scenario is that, while it does provide access to 
multiple name spaces, it doesn't provide for failover.

I have a suggested solution, but it's going to be a pain in the 
tailfeathers to implement.

The 'wins server' parameter would take entries in the form:

  wins server = <server>[:<server>] { , <server>[:<server>] }

For example:

  wins server = 192.168.101.5, wins.office.com:wins2.office.com

The above basically says
- Use 192.168.101.5 to resolve names via WINS.
- If name resolution from 192.168.101.5 fails, then try the WINS server
  at office.com.
- Initially, wins.office.com is the second WINS server to try.  If it
  appears to be down, then use wins2.office.com instead (that is,
  failover). 



Is this making any sense?  It seems that we have two desires for this 
feature.  One is failover to a synced WINS server, the other is access to 
multiple WINS namespaces.  I can do both, but I really do need some 
(polite) discussion on the pros and cons.

Chris -)-----

PS.  I've actually gotten most of failover written up.  It's a bit
different than the patch that was submitted but that's because there were
requests for more than two WINS servers.  Also, I've made a distinction
between Negative Query Response and a timeout.  That fix should improve
speed even when only one WINS server is in use. 

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