On Mon, 4 Dec 2006 23:51:04 -0500
Zach <netrek at gmail.com> wrote:

> On 12/4/06, Joe Evango <jjadeinc at hotmail.com> wrote:
> > Only 9 on continuum and I am seeing a new pulsar server,
> > netrek2.pulsar-zone.net, and the godfather server being listed as preferred
> > servers on metaserver.us.netrek.org.  Did something change?  The old pulsar
> > server is still active but not being listed as a preferred server.
> Sigh once again netrek.pulsar-zone.net is reporting the bots in the
> player count on the metaserver. I just checked it is reporting 11 now
> and there are 5 humans and 6 bots!
> And now netrek2.pulsar-zone.net is also incorrectly reporting bots as
> humans. Please can something be done about this. Matthew Mondor said
> he'd fix this so it wouldn't happen again, yet here it has.

The problem is/was in the metaservers code all along;  before a recent
fix from James, the metaservers used to connect via TCP to the servers
whenever no UDP packet from it was received for a little while, and it
counted robots as players.  Now UDP-reporting capable servers should no
longer get connected to by the main metaserver.

As for netrek2.pulsar-zone.net, a new server was setup on another static
address+box so that UDP can now work.  It was initially called
netrek2.pulsar-zone.net and had corresponding DNS entry, and would have
remained as-is for as long as it takes for people to report that UDP now
functions properly (and the other server remained up).

I also was surprised that the metaserver showed it in the list despite
the restrictions and although I haven't read the metaserver code since a
few years, I can only assume that the restrictions are made on a
per-case basis (rather than for instance a global deny all rule followed
by exceptions).  This would imply that any new server would get listed
(and so was my new server).


It wasn't too long until confirmation that UDP was working was received.
I then deleted the netrek2.pulsar-zone.net record, shut down the old
server and renamed the new server solicit name back to
netrek.pulsar-zone.net (as well as fixed its DNS entry to point to the
new address).  This caused various problems on the metaservers:

1) second metaserver started connecting again via TCP to the new server
and reporting robots as players.

2) since netrek2.pulsar-zone.net was no longer existing, but previously
was, the metaservers entry for it remained for a while.  I didn't check
the code yet, but it appears that because of this dangling entry the
metaserver was also querying the new (cached) address for player list.
(and of course also counting robots as players).

3) Of course DNS propagation had to occur (despite the rather short
expiration time I set for my domain names).  After the move I thought I
should have kept the netrek2.pulsar-zone.net name all along after the
switch, and have CNAMEd the old name to the new one.  This however would
not have prevented the new server from being listed at all times without
fixes to the metaserver.

4) On the first metaserver, netrek2.pulsar-zone.net still persists since
the metaserver no longer attempts to connect to it (having flagged it as
one that updates through UDP), so it didn't change its state (i.e. 2
players 30+ hours ago).  I'm uncertain if the entry will need to be
removed manually or if it'll eventually expire out.

I am sorry for the temporary inconvenience the server switch caused, but
the changes are over.  Hopefully players get slightly lower latency now
that UDP works on the new server.

Some could argue that I should have re-read the new metaserver code to
find out its cons before doing this;  However I would rather have shut
the server down if it was that much trouble.  I in fact had decided to
shut it down when the new rules were applied to the first metaserver,
however due to multiple user requests I decided to bring it back up. 
It's a service, and if it gets too much trouble I won't have the time to
cope with it.


If I did have the time (and approbation), what I would personally do is
rewrite the metaserver code and protocol and adapt vanilla and clients
to use it.  Of course, this also assumes that everyone want to take the
trouble to upgrade :)

- Flags/fields would be added as necessary so that bots be marked as
such.  The server comment field would also be honored.  Additional
server states and flags could also be implemented.  The protocol would
be versionned for future updates and backwards compatibility.

- UDP updates would be replaced by server to metaserver update requests
using TCP only (potentially with DSA or HMAC-SHA-80 for authentication
and perhaps optionally AES-128 for content blocks + embedded checksums),
and metaservers would no longer connect to any server.  This would be
allowed to export in most countries today in open-source software with
the proper disclaimer.

- A server for which no updates are received within a configurable time
frame would immediately be de-listed until the next update, so would
servers exceeding the specified update rate, for a specified time

- Origin IP address of update requests could also be more relied upon
than it currently is with UDP updates (for which all kinds of exploits
are possible).  Currently one could easily spoof the origin address of
update packets and ruin the reputation of any server (I'm surprised this
never yet occurred, and am ashamed if I teach the obvious to potential
evil readers by mentioning it).

- It would be possible for new server admins to be granted the right to
list a server and be assigned a key to do so.  This would be
configurable so that a metaserver could instead decide to be totally
open as they traditionally were (actually, with RSA or DSA the server
admin would most probably provide its public key part to the metaserver
admin along with the request).

As this morning I decided to take the time to reply, I thought I might
as well add a bunch of ideas for others to potentially be inspired from :)


To also voice my opinion about what happened lately to the community
relating to the warped server and the recent main metaserver

I personally think that the high population on warped was mainly because
Bill is the most active client and server developer (if not the only one
nowadays).  The restrictions put on the main metaserver can however be
considered legitimate if it really helps bronco to survive, and if what
people want is still bronco, IMO.  It's James' metaserver afterall, and
anyone could start his own and release clients using it as main
metaserver.  It's actually a solution I recommended to Bill if he wants
sturgeon to continue to evolve.  His reply was that he wouldn't want to
segregate the netrek community like this, which is a very reasonable
point of view as well.

As for my server, if the metaserver comment field really worked, then I
think that my server could probably remain listed at all times and be
marked "practice borg server", as it's all it really is.  The twinky
Sundays (with super GA and SB ships) appear to be appreciated by a
number of people, but are still only bronco settings that did not
require code changes, and it's only one day per week, still with the
permanent robots enabled.

The server's motd redirects players to continuum for actual human
tournaments (although I'm unconvinced that players actually read motds,
especially that there was a note put there which would have answered to
most of zach's questions :)

Before the reborn of sturgeon, players were rare on
netrek.pulsar-zone.net although there were some at off-peak hours (when
there weren't enough people to play on continuum).  Even on sundays I
highly doubt that it was generally "stealing" bronco users.  And this
situation lasted a while with regular tournaments on continuum.  The
visit frequency however increased substantially after continuum was dead
for a while, a possible justification for a temporary restriction, but
which probably should be lifted once regular human tournaments resume on
continuum (James willing).

The fact that very few users know about using -h or changing their
metaserver settings made the server useless for a while (although there
now are a few visitors per day).  If a client upgrade allows to easily
have access to multiple metaservers, wouldn't it make the restrictions
system totally useless however?  Also, since my server's traffic was
mainly off-peak, I'm unsure about the efficiency of the current
restriction rule placed on it, since it now only gets listed when
continuum is full (when there is the least chances of someone wanting to
play against robots :).

Thanks and farewell,