Multi-WINS behavior.
Christopher R. Hertel
crh at nts.umn.edu
Mon Jul 10 01:46:20 GMT 2000
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
More information about the samba-technical
mailing list