On Sun, Feb 24, 2008 at 03:18:43PM +0100, Rado S wrote:
> =- James Cameron wrote on Sun 24.Feb'08 at 21:55:59 +1100 -=
> 
> > You've lost me. What is not about blocking disobedience? Why is
> > disobedience mentioned?
> 
> "there's no reason to block them if they don't use {solicitation}."
> 
> The reason for my inquiry is to get rid of permanently downed
> servers once identified as such, solicitors or not, and I'd like to
> know what reasons speak against it.
> 
> You've put it as if anyone wanted (or believed this about others) to
> block those not obedient to the request to switch to solicitation.
> That's not true.
> If there indeed were the intention to make all switch, I'd have
> expected those asking for it to support those candidates to
> accelerate the transition and then get rid of static lists.
> That was before I learned there were persistent problems requiring
> exceptions.
> 
> If solicitation were so uncritical, why were Paradise servers urged
> to implement it rather than just getting relisted as before?

I do not recall my reasons for urging this in April 1998, and they may
no longer be relevant, but there are some possible reasons that I can
think of now:

1.  information about Paradise servers would be as up to date as Bronco
servers, thus creating a level playing field, (Bronco servers would not
have had the advantage of accuracy on metaserver listing as they have
had for ten years now),

2.  once all servers have converted to solicitation we may be able to
deprecate the older mechanism (metaserver connecting to server),

3.  remove the need for the player list port on servers, especially
those in an environment where each port needs to be explicitly listed in
system or network security configuration,

> 
> > > > No, that's not how it works. The server does not send any
> > > > packet to the metaserver until it has players join.
> > > 
> > > Uh... why is _that_?
> > 
> > Defective design or implementation.
> > 
> > > How should an empty server get players in the first place then?
> > 
> > It can only get players if someone logs into it manually first.
> > This should change. Please care enough to change it rather than
> > keep a mail thread alive.
> 
> Well, you could contribute your part to it by not simply publicating
> what you know in the for you most minimalistic possible way, but
> consider what's helpful, given the direction I was asking.

I didn't understand the direction you were asking.  I still don't
understand why you don't just fix it and give me a patch.

>  A mere comment that "this works this way but it's not intended
> behaviour" would have saved both our times.

I thought you would have known this already from our previous
discussions on other subjects.

> 
> Given the past of requests and decisions about acceptance and
> denials I had reason to believe that only what is approved is let in
> and kept for some reason. Before breaking that with a change to _my_
> liking I want to know what there is more than I could think about
> why things are as they are.

It won't help though ... even if you just provide a patch to match your
understanding of what should happen, there may be some who would fight
you over it.

I'm more likely to accept a patch if it has a simple explanation of what
it fixes.  In this case, something like "with this patch, servers will
initially list on the metaserver without having to wait for a player to
connect to them first, eliminating a catch-22 situation."

> For the record if you still haven't noticed: I care for change.
> But I can't change all by myself, because of lack of time or
> knowledge. I can not afford reading all code lines to get the big
> picture and _guess_ intentions or reasons.

Intentions or reasons rarely matter to me.  I'm more interested in the
code, and the future.

> > Yet how can we implement a way to delist that cannot be easily
> > abused by attackers? Source IP address is trivially forged.
> 
> By listing only those soliciting continuously and responding when
> checked after a timeout.

That is almost what is currently implemented, except that servers are
not contacted after a timeout.

> > > I see you joined 2 mails, yet you cut off what's more
> > > interesting: whether my suggestion to fix the "drop dead
> > > servers" problem is adequate.
> > 
> > Yes, I cut it off, because it didn't apply, it wasn't in a format
> > recognised by patch(1), try again.
> > 
> > > My suggestion was to let metaserver update solicitors
> > > proactively when they haven't updated for a timelimit, then
> > > depending on the forced check let things update, potentially
> > > delisting the server, see "nuke_server" checking for
> > > solicitation servers to remove them when disconnected.
> > 
> > Sounds good, but I'd need to see a patch, thanks.
> 
> I gave it.
> A "patch(1)"-able format wouldn't give you any more information than
> I gave you already.

It would give the information I need to apply the patch.

> You act like an unflexible robot -> not helpful for change.
> Facts alone don't help, but reasoning behind it and consideration of
> context.
> If you don't want to give that, then save both our times.

I will take a patch if I understand it and agree with it.

> Facts of how things are can be figured out, but background on how
> things came to be are not always recorded next to the facts.
> 
> You like to keep it simple for yourself, but you overdo it at times,
> and then blame me for catching up with what you missed to add.
> Discussion is not a contest about the shortest answer, but a desire
> to proceed together.
> Nobody is perfect, everyone can improve.

Interesting, but not relevant.

-- 
James Cameron    mailto:quozl at us.netrek.org     http://quozl.netrek.org/