Multi-WINS behavior.

[Elrond]

On Tue, Jul 11, 2000 at 10:49:36PM -0500, Christopher R. Hertel wrote:
[...]
> > 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.
> 
> That's what one would do for 'failover'.

That's the version, I would like for failover, because it
also has a priority in it, in that it will retry the most
important server (hopefully nearest to you) at some later
time.

> > > * 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.
> 
> That, again, is what I was aiming for with failover.  The assumption, 
> though is that all of the WINS servers are in the list.
> 
> 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.
> 
> One modification to this is to always maintain a full 'live' list and 
> simply move 'dead' entries to the end.  That's probably what I'll wind up 
> doing.  The key is to avoid an infinite loop checking all WINS servers 
> repeatedly.
> 
> 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)

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

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

> I encourage everyone to read:
> 
> http://msdn.microsoft.com/library/backgrnd/html/msdn_winswp.htm#winswp_replication

I started to read it. Quite interesting. For example I
didn't know, that there's a direction in the replication.
Of course the inner workings have one, but I thought, this
was hidden from the user. So it is even possible to
misconfigure it...

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.


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

On the one side, you're right, of course. But look below
for more comments on that.


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

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

[...]
> > This all sounds quite good to me.
> 
> I have my doubts.  That's why I'm talking about it.

Yeah, okay.

> > That is:
> 
> > - Register with all specified wins-servers
> 
> Could generate a bit of replication traffic.  I really don't know what 
> will happen if this is done.

I don't know either.

> >    side-question: what happens, if it fails?
> 
> If the servers are synced the it won't matter, on the server side.  I 
> have no idea what the Samba client would or should do.

client -> server, only the server will try to register. ;)

> 
> >      If the server is down, retry later, but not too early,
> >        we don't want to flood the net.
> 
> Do we retry now?

No idea: rtfs ("read the fine source") ;-))

> >      If the name is already taken? No idea yet.
> 
> This can happen.  Of course, this is more likely with multi-membership.

Yes, and it is unclear, what to do.

Options include, but are not limited to:

* log a message to the logs (I would recommend this at
  least)
* ignore and go on
* try some _long_ time later
* mark this wins-server as "poisoned" and ignore it
  completely, even for lookups
  (how will smbclient/nmblookup would know of this?)
* more to think up.

I haven't thought much about any of these, so they're for
pleasure/ignorance/start-of-other-thoughts/whatever.


> > - 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)
> 
> Yes.
> 
> > I can see only one bad thing: Increaed network-traffic,
> > especialy with registrations.
> 
> ...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.  The traffic probably 
> won't be that bad, but geez what a mess.

Yeah, what I said, more network traffic.

> Oooh, and I haven't considered 
> the implications for Browsing yet.

Well. For normal clients, they're just using one namespace,
anyway.

So the question is, wether samba should try to create
workgroups also in every namespace (in addition to adding
just its name there) (see below for more on this)

(OT: Can I get samba to be in two workgroups at the same
time, that is for browsing? And so the same samba is also
lmb (and even dmb) for both workgroups?)


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

Yes.

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

Peter (assuming, I got him right) and me were mostly
suggesting this, because it provides some failover with
increased traffic, as you stated in the above paragraph.

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

Well, as I think more about it, it sounds more clean. It
allows admins to do, what they want and at the same time
allows them also to keep the traffic at a moderate level.

> > 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.)
> 
> Does my approach above make more sense now?

Yes. But I (Peter possibly too) have read, that you think,
it will be quite some work to implement and so I/we were
thinking about alternatives that make also sense.

If you're planning to write it that way, I'm not going to
stop you.

> I'm not against the
> multi-membership idea, though I have no idea what it will do to browse
> lists, or finding the DMB or PDC.

Yeah... Someone, who is more familiar with that, should
think about it and write something about it.
And when we have some conclusions, those need to be
implemented and documented in a useful manner...

Hmmm... We need to think up this before registering in
multiple namespaces, because samba might become the dmb in
one namespace and then try to register itself as the dmb in
_all_ namespaces, although it lost in the others...

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

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


[...]
> > Hmmm... That explains something.
> > Okay... dropped that also into TNG.
> 
> I'm going to check in a slightly better version of this fix.  Better
> debugging and it catches more return codes.  Look for it.

Going to look at it as soon, as possible... I'm still writing
mails... ;)

> Chris -)-----

    Elrond