Multi-WINS behavior.

[Christopher R. Hertel]

> > Note that a reload of smb.conf will reset the live list to the contents 
> > of 'wins server'.
> 
> Well, as I originaly said, I like the above more, because
> the orignal order will be retained (and you do not need to
> HUP smbd for that to happen)

It isn't hard to add a timeout value to dead nodes, so I can know when to 
try them again.  It's a good idea, I think.

> > If the servers are synced, then there is no need to prioritize them.
> 
> There is: They might be in different places, and it is
> better to ask one instead of the other.

I was thinking in terms of prioritizing their "authority".  If two 
servers both have the name "FROOB" listed, which one is correct?  If they 
are synced, then both are.

Still, the point about location is correct.

> Assuming, that most of the wins-access are lookups, this
> makes even more sense, because no replication is needed for
> this.

I think that failover and mutli-membership behavior are being confused
here. 

> But on the other side, I'm not that interested in the inner
> details, I just want to throw in my (more general) thoughts
> here.

The inner workings are important in that they may affect behavior.

> > 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?
> 
> Because the wins servers are _ordered_ in smb.conf and
> the admin wants the reply from the first "namespace"

Right.  That's what I meant by "hierarchy".

> > Given that NetBIOS names are the addresses in the NetBIOS virtual LAN, 
> > there are a lot of problems that could be caused.
> 
> Problems, that originaly didn't exist?
> That is: _new_ problems?

Yes.  Name space conflicts become more random and harder to manage.  
Names will appear and disappear as servers come and go.  Worse, name 
resolution will *change*.

> > Oooh, and I haven't considered 
> > the implications for Browsing yet.
> 
> Well. For normal clients, they're just using one namespace,
> anyway.

Right.  But our clients aren't normal if they can see multiple WINS 
namespaces.

> > A lot of that is up to the Admin, who
> > will have to ensure that there are no name collisions between WINS
> > servers.  Of course, if you're doing that, why not just sync them anyway? 
> 
> Because the admins of the wins-servers are too stupid or do
> not want to sync for other reasons?
> (Yes, that might happen)

Yes, it might.  In which case they'd probably mess up multi-membership as 
well.

> Other variant is: The wins servers are samba, which doesn't
> yet have replication.

A known problem.


My immediate goal is to get failover working.  That was the original 
request & patch.  Next for me is to get WINS replication in Samba.  If 
multi-membership is really important, I think we'll need to work out the 
browsing and domain issues first.  I'll leave room in the code for it, 
though.

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