On Fri, Feb 22, 2008 at 08:06:38PM +0100, Rado S wrote: > =- James Cameron wrote on Fri 22.Feb'08 at 9:10:38 +1100 -= > > > On Thu, Feb 21, 2008 at 05:54:38PM +0100, Rado S wrote: > > > - network path problems: well, again, what's the gain for anyone > > > to see it listed as unreachable rather then not listed at all? > > > > I mean network path problems that prevent solicitation packets > > from the server to a metaserver, yet permit play. We have had such > > servers in the past, and we may yet again, which is why I > > mentioned it as a reason. > > Got it. > Is this a systematic problem for some conditions? I don't think it is important to go into details, but this has happened ... we have had people run servers in locations that prevent the solicitation packet from reaching the metaservers. > Addressing the cause is better than working around symptoms. The cause is not always in our control, so it is better to be flexible. > > Yes, we have frequently contacted server admins to encourage them > > to use solicitation, but as it isn't a critical feature there's no > > reason to block them if they don't use it. > > It's not about blocking "disobedience", but the lack of usefulness > (or even harm) of keeping a permanently dead server listed > statically. You've lost me. What is not about blocking disobedience? Why is disobedience mentioned? > > 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. > > > And how could they be joined before being listed on the metas? > > > (chicken-egg problem, unless you assume people keep local lists > > > and/or caches, but then this isn't an issue at all) > > > > Exactly ... > > To what, being a problem? > Or not an issue at all? I was agreeing with you. > > and that by the way is an argument for why a server that sends a > > solicitation should continue to be listed for some days, so that > > players will join it, thus generating further solicitation. > > Ok, now you lost me. > How does keeping an outdated entry on the list help the player? It provides history. (Remember, I'm answering factually, not from a policy perspective. I'm not saying that history is more important than keeping an outdated entry.) > Especially "empty" servers aren't attractive to join in the first > place. And then by the policy empty ones aren't shown after 6h > anyway. > > This sounds just wrong: hide before start, lie after its death, hide > again when idle too long. > Why is _this_ operation preferable over listing even empty servers > from the start so that they get a chance to attract players, and at > the same time stop being listed with wrong state as soon as they stop > updating? This operation is not preferable, I never said it was, I was only describing it. Fix it. > > > > 3. the metaserver has an undesired feature that prevents it > > > > from working unless there is at least one static server. > > > > > > This can't be overcome? > > > Or it isn't wanted to be overcome? > > > > This can be overcome. > > If you care enough to, please do so. > > Well, it makes only sense if it got used. > If the metaserver admins want to keep statically listed servers, > then that's useless. Again, note that I was describing implementation, not policy. > > On Thu, Feb 21, 2008 at 06:05:28PM +0100, Rado S wrote: > > > Apropos, the policy, which I quoted last time not to show > > > servers which are empty for 6h, why is this good? > > > When a server is not shown, how could it ever change its status when > > > nobody knows how to get there to fill it up? > > > When is "last_udapte" updated? > > > Can "age" ever become > 6h purposefully (unlike dead solicitation > > > servers as in my broken case [soon to be fixed])? > > > > You raise important design points. What do you propose as the > > solution? > > It would help thinking about if I knew what the purpose of this > policy is/ was. Solving a problem by breaking another is no progress. I was not describing policy. I imagine the current implementation is defective by design. > > To me the simplest extension is to add an identifying token to the > > solicitation packet, and permit the original server to delist > > itself when it shuts down. > > What about crashes, net-loss? > Result would be the same as in my case: phantom entries. Yes, I know. I would expect the token to be stored locally by the server. Loss of filesystem would cause phantom entries. Yet how can we implement a way to delist that cannot be easily abused by attackers? Source IP address is trivially forged. > > Another potential extension is for a server to send a solicitation > > every hour regardless of being empty, and code the metaserver to > > remove entries from list that exceed three hours age. > > 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. -- James Cameron mailto:quozl at us.netrek.org http://quozl.netrek.org/