=- 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? If it's only a temporary issue, then either it's short and doesn't matter anyhow or it takes long to notice and people should take care of it in general. Addressing the cause is better than working around symptoms. > 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. > 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_? How should an empty server get players in the first place then? > > 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? > 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? 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? > > > 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. > 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. > 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. > 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. 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. -- © Rado S. -- You must provide YOUR effort for your goal! EVERY effort counts: at least to show your attitude. You're responsible for ALL you do: you get what you give.