Multi-WINS behavior.

[Elrond]

On Tue, Jul 11, 2000 at 10:54:17PM +1000, Peter Samuelson wrote:
[...]
> * After a wins server is pronounced dead, it is not queried again for
>   (say) five minutes.  Easy enough, put an `isdead' boolean and a
>   `lasttried' time_t in the `struct winsserver' or whatever.

That sounds like a nice version, see below for more
comments.

> -or-
> 
> * Round-robin: rotate your in-core list of wins servers, putting the
>   dead server on the end of the queue.  It won't be primary server
>   again until all the other servers crash at least once.
> 
> I would consider either approach acceptible.  The latter does have
> implications for namespaces, in that it becomes impossible to
> prioritize the wins servers (i.e. specify whose answer you would prefer
> to get) but would have the advantage of a simpler implementation.

prioritizing doesn't work here any more, as you already
wrote, this version would make sense for the "complex
solution" below.


[...]
> The only disadvantage of doing this is a bit of network traffic every
> time you need to send an update.  How often is this?  My impression is
> that the added traffic would be modest.
> 
> > ..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.
> 
> Me too.
> 
> In fact, I don't even think there's that much room for debate.
> 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?

This all sounds quite good to me.

That is:

- Register with all specified wins-servers
   side-question: what happens, if it fails?
     If the server is down, retry later, but not too early,
       we don't want to flood the net.
     If the name is already taken? No idea yet.
- For queries, use them all in _order_:
  - If we get a negative response, try the next one.
  - if we get no response, mark the machine as dead for a
    while and try it later (as noted above by Peter)
  - of course, skip servers, marked as dead
  - (unless their deadtime is over)

I can see only one bad thing: Increaed network-traffic,
especialy with registrations.

> >   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).
> 
> To me this is needlessly complex (and as you said "a pain in the
> tailfeathers to implement").  My humble opinion is that nobody needs
> this amount of flexibility.
[...]
> No need to pick & choose which feature you want.  I can't see a
> situation where it would make sense to have one but not the other.

Yes, I also think, that this amount of flexibility isn't
realy necessary. I just can't see something, were this is
better than the approach above (except for network-traffic,
granted that.)


> > 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.
> 
> Cool!  You're saying the current code basically drops the NQR on the
> floor and continues to wait for timeout?  If so, it explains why failed
> lookups to WINS seem to take just as long as failed lookups to
> broadcast, something that has mildly bothered me for awhile now (mildly
> meaning not enough to make me actually investigate the code or the
> protocol).


Hmmm... That explains something.
Okay... dropped that also into TNG.


    Elrond