Here's a public version of something I just posted to our company intranet.
Update: I've been informed that the correct spelling of the sport in question is "Foosball," or "Table Soccer" if you really want to be fancy.
Ahh fooseball, what did we ever do at work before that wonderful real-life videogame arrived in our office kitchen?
FooseFlag - A Simple Plan
Frequent Fooseballers download and install the FooseFlag(tm), a tiny application that sits in your system tray, whose user interface in its entirety is a little flag icon which is drawn in either the up or down position. When the tired, overworked, burnt-out NITI employee needs a quick game to bring her back to the land of the productive, she simply clicks the flag into the up position, indicating her willingness to play a game of foose. When a total of four users on the LAN have raised their flags in the same way, the system pops up a dialog on everyone's screen informing them that enough of their coworkers are willing to play, and that they should now head to the table for a game.
Now, MOST of the time our typical NITI employee is "in the zone", happily hacking away and not interested in any interruptions whatsoever. Therefore she will keep her FooseFlag in the down position and never hear about a game if one should be organized (except maybe if it gets TOO rowdy!).
Notice how this scheme fixes the problems of the current system (which is: just ask around the office until enough people agree). Those who want to play can organize a game without leaving their desks, and those who don't want to play never have to bother declining a game.
The Details
Implementing the described system using a client server model would be easy. Clients start up, and when their user wants a game they make a connection to the server. When the server gets four connections, it informs each client of the identities of the other like-minded clients, and we're done. But this is boring and who really wants to worry about maintaining another daemon running on some machine somewhere? After some discussions with others, I've put together a decentralized scheme using UDP broadcasts. Here's how it works:
When a client wants a game, it starts periodically broadcasting its identity to the local subnet. This looks like:
jdcormie@eagle 1035826140
The number in the second field is this client's priority, which is just the current time when the user first raised her flag. Games are formed by choosing the four clients with the lowest (earliest) priority numbers.
Clients also listen for broadcasts from other clients. When we receieve a message from someone else, we add them to our list of "others" sorted by priority. If we haven't heard from a client in a while, we remove them from our list.
When we have four entries on our list of known clients, that is, we've heard from three other people that they want a game, we form a game id, which is just the concatenation of the usernames of the participants and start broadcasting that periodically. Now our messages look like:
jdcormie@eagle 1035826140 jdcormieandrewmcotesmellei
It seems like we should now inform our user that we have a game, but we don't! First we will wait for everyone else to agree with our idea of who will be in the game. When we start receiving messages of the second type, that is, including a game id, we compare the received game id against our idea of what the game id is. Once we receieve a gameid that matches ours from each of the people we think are going to take part in the game, then we notify the user, and the game is on. If we stop hearing from one of our participants before everyone agrees on the game id, we just fall back into the first mode, only broadcasting our identity and priority.
After we have notified our users, they presumably go off and occupy the table. For this reason, we keep broadcasting the gameid during this time, which should prevent other games from forming while the table is in use. When users return, and the table is free again, they click a reset button on their clients.
Notes
Users can always move their flag into the UP position, but once we start broadcasting our calculated gameid, we don't allow the user to take down the flag. In effect it's too late to withdraw your request for a game because our peers might be in the process of agreeing and notifying their users.
I think this design fully accounts for the possibility that many of our UDP messages will be dropped by the network. No single message is so important that it cannot be dropped.
We ignore the issue of time synchronization between clients because it doesn't really matter if the system is perfectly fair. There is the problem of someone with an incorrectly high priority (computer time set wrong) barging ahead of someone else, but 99.9% of the time in a network with good connectivity, there will never be more than 4 players in anyone's list, and so priority is not really an issue.
Status
The core FooseFlag class has been written and is checked into cvs in /home/cvs/fooseflag. Also there is a text client called 'fbd' The KDE system tray "flag" needs to be written.
1:15:17 PM 
|
