Tracking the ethereal

Attack Objectives. I’ve had a number of requests to expose which towns are currently under an objective – both from Ramp for CS&R and from people interested in pulling that data from Wiretap.

Unfortunately, this data is not exposed to the database by the server responsible for tracking AO assignments (the strat host).

The only thing keeping me from simply throwing in a column or a table for AOs is closure: ensuring that a server-outage doesn’t leave an open-looking AO entry in a table.

Solutions I have aplenty:

  • Keep the ‘closed’ field on all open AOs set to 150 seconds in the future and update the field every 60s. Con: heavy handed database pounding.
  • Wrap the server process with a script that automatically closes all active AOs in the database. Con: The server may be down due to a database outage.
  • Force the server to close all outstanding AOs on restart. Con: Long periods of incorrect data when the server is down for maintenance/patches.

But I don’t really have time right now to sit down and think through the various use-cases I have and work out the best strategy given our architecture. If we were using Postgres or Oracle at the moment, I know what I’d do.

But we’re using MySQL 4.1 and the technologies like views and PL/SQL aren’t mature enough in any version of MySQL for me to be comfortable about moving to them. We’ve been experimenting with Trac in-house, which uses Postgres. Mmm. Boy did it feel good to be type be in pgsql typing commands. I’ll argue the case for MySQL for WWII Online on technical grounds, but that doesn’t mean I don’t feel unclean for then being a MySQL user :)

7 Comments

“long periods of incorrect data” …

can you have a field that pulls server status at the same time? Allowing you to show the information is doubtful, and simply having the server bootup process clear all AO’s?

potential issue: Is the server clearing AO’s or is the database’s tracking of the AO’s being pulled? if its the latter, and you can show server online/off-line status, doubtful information exposes itself(?).

n.b. the poster lives in blissful ignorance of code*.* (splat.dot.splat) :)

I’m with Joker here.

As long as AOs are closed on normal shutdown and startup the only case that’s going to leave them in a incorrect state is when something goes wrong. And again, as long as there’s semi accurate server status information it really isn’t something you should have to plan for on your end.

Besides, so what if the AO information is incorrect for 5 minutes after a crash. I don’t think most people are really going to mind that much :)

Strat is a cow (Center Of World). If strat crashes, or borks, it tends to mean significantly longer downtimes. Actually, a strat crash usually means a host patch.

Another option is for me to make another process we have – the database relay – responsible for AOs. It doesn’t crash, but it also would be restarted within 500ms of a crash and a running strat host reconnected with 175ms of it going online again.

Be relatively easy to make it responsible for it.

What about giving Wiretap a view of the server state? If it knows the servers are down, it returns some sort of “no server available” message? That would deal with the long periods of wrong data for when the hosts are down but the DB isn’t, or during maintenance.

I *think* KFSONE is trying to circle *around* the bad server state completely. Thereby allowing the DB and the AO’s to survive with accurate information…for as long as the Strat server is down.

This sounds like a good way to preserve AO information for the Strat host reboot (presumably after patch as suggested by KFS) but this also presumes I was correct in surmising what he was talking about in the first place. :P Nicht wahr?

You could probably have each host update its ‘up’-status into the database every 60 seconds or so, and filter out AOs opened by hosts that are not up when querying the database. Perhaps something like this was already on your mind when you mentioned views, though?

Actually, there is already a cluster-status table where each host writes a record indicating its still alive. I’m always torn on those between whether to write a “last seen” timestamp or a “valid until” timestamp :) If we had a real DB, I’d have it obscured behind a NTKIF :)

Leave a Reply

Name and email address are required. Your email address will not be published.

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

You may use these HTML tags and attributes:

<a href="" title="" rel=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <pre> <q cite=""> <s> <strike> <strong> 

%d bloggers like this: