Vying Games : Blog

Happy holidays, everyone!

As my gift to you, I've released YINSH.

YINSH is one of the games from the more popular games from the GIPF Project. Unfortunately, I don't have time to write more about YINSH because I have other presents to wrap. So, you'll just have to trust me that it's a cool game. Read the rulesheet for more about YINSH.

I'll be traveling today through Saturday, so please be patient if you find any bugs in this release and I'm slow to reply. I'll try to check in everyday, but there'll probably be a limit to things I can address / fix.

Best wishes to you and yours! : ))

If you're a fan of Ataxx, you'll be happy to know that Hexxagon has just been released. Hexxagon, in a nutshell, is Ataxx on a board of hexagons instead of squares. The most intriguing difference between the two is that Hexxagon can be played with 2 or 3 players. This makes it notable as the first released game that can be played with more than 2 people.

See the Hexxagon page on the wiki for more details about the rules, bots, etc.

If we get through the day without bugs, I'll open a 2-player Hexxagon round robin tourney tomorrow. Then next week sometime we'll try a small 3-player Hexxagon round robin.

Coming Soon: More Games

There are quite a few other games that are ready or nearly ready for release. I have to start clearing the backlog so next week we'll have another new game. I'm not sure which game as there are a number of good candidates. Everyone likes a good surprise, right?

So, the vying library has been open source for a while now. If you're not familiar with it, it's the basis for Vying Games -- all the code for the games themselves without any of the web server, database, bots and other extra stuff.

The code for vying is available at Github, and up until very recently I was the only person working on it. Which brings us to today's announcement:

I'm very happy to announce that Dieter Stein has contributed code for his game Attangle. Thanks Dieter!

Now, I have to get busy working on getting Attangle up on Vying Games. : ))

Just a quick note: this afternoon I released a new version of the server that includes a few timing related bug fixes. These were bugs that effected a very small handful of games, but were fairly severe.

Undo Timeout Bug

Thanks to Hypatia for reporting this bug! This bug was introduced in the previous release which tied the last move timestamp to the game's history. Unfortunately, undo and undo by request alter that history in such a way that could (and did in one case) trigger an incorrect timeout.

No Moves == No Timeout

Thanks to stonemender for reporting this one... Games without any moves were not timing out. This, again, was caused by the change to looking at the game's history for the last move timestamp.

Plenty of Timeouts on the Way

With this release, I feel much better about the timeout code. So, for the first time in a while, I'll be running the cron job that times out games tonight. This cron job has been disabled for quite a while, due to outstanding bugs. While disabled games would still timeout, just under fewer circumstances. For example, reviewing a game or a tourney's standings would timeout games as appropriate. But, if a player were to ignore a game it could remain in limbo indefinitely.

Most of the games that are due to timeout are games between anonymous players and bots, so I expect the bots to have much higher ratings tomorrow.

Doubled Tourney Games

Now a topic unrelated to timing. We've had two tourneys now that started twice, resulting in a doubling up of tourney games. Both times, I fixed the tourneys manually. After the first time I thought I'd fixed the bug. After this most recent occurrence, it's clear I didn't. : ((

This time I've completely disabled a large part of the code that starts tourneys. Before this release, a tourney would start immediately when it reached capacity (that is, the last player clicked join!. Tourneys that didn't reach capacity would be started at the top of the hour after the scheduled start time by a cron job.

The tourneys that started twice were both at capacity, so I've disabled that code. Now tourneys will only be started by cron job, which should eliminate the race condition that caused the bug.

I hope to have a better fix in the future.

Thanks!

Everyone's been very patient as I've worked through these (and other) bugs -- I appreciate it! Thanks!

This is kind of a technical post, so if you're not inclined you may want to skip it. The takeaway is this: changes were made to the server, now the site should be more responsive.

As you may know, this site is uses Ruby on Rails. The typical way of deploying Rails apps is on a cluster of Mongrel servers behind a reverse proxy. Mongrel is a Ruby web server that's thread-safe and has no problem handling requests concurrently, but Rails has been designed from the start as a single threaded application. So, Rails will only handle a single request at a time. As such, we actually need several Rails processes ready to handle requests, hence the Mongrel cluster.

The reverse proxy, basically gives your web browser the appearance that there is one vying.org when, in fact, there's a cluster of several Mongrels handling requests. Many web servers are capable of acting as reverse proxies. For a while I used Apache as a reverse proxy. Then I switched to nginx because it uses less resources. Now, I'm trying HAProxy. Apache and nginx are general web servers. They'll serve static files just as easily as play the part of reverse proxy. HAProxy is just a proxy. Nothing more. So, in this case, I've actually inserted HAProxy in between nginx and the Mongrel cluster.

Why HAProxy?

So, why go to the trouble of using two reverse proxies? It all comes down to load balancing. Since Rails will only handle one request at a time, if the proxy sends a request to a Mongrel instance that's already processing a slow request, the new request will be queued. If you make a quick request, and it gets queued behind a slow request (like say a bot that's taking a long time to move), then your request will also appear to be slow.

Ideally, the proxy would send requests only to idle Mongrel instances. If one is busy, it should not be given new requests. If all are busy, it'd be better to queue the request into the proxy server, and then send it to the first Mongrel to finish it's request.

This is where HAProxy comes in. It has a balancer that will do the above, whereas nginx doesn't at this time. (There's actually a patched version of nginx that provides a "fair" balancer, but I've heard that it isn't always exactly stable)

So, I deployed HAProxy this afternoon, and so far, it seems to be worth it. I'll have to run it for a while, to see how it holds up in the long term (and under a higher load), but so far so good.