Applications over Freenet: a Decentralized, Anonymous Gaming API?

In this article, I'll tell you how to write a simple, generic gaming API on top of Freenet using the shiniest new Freenet APIs and design patterns. Why write games over Freenet? Well, you can play without a central server, without having to worry about attackers falsifying moves and without knowing who you're playing against! Some people question the usefulness of these features. The real reason is it's more fun to implement than a relational database, and I'm not exactly getting paid for this. But wait, is Freenet real time? Is it fast enough to play a satisfying game of anonymous Quake on top of it? No, it's about as fast as e-mail or a heavily loaded web server, depending on the weather. Remember the part about us being crazy and not getting paid.

There are lots of ways to interface with your node; I won't cover them all here. Anyone who can use the Java Servlet API and one of the client APIs can write a new interface that runs inside the node. The Freenet HTTP Proxy (FProxy) is written this way, for instance. The interface I prefer for talking to my node is XML-RPC. There are XML-RPC libraries in at least 21 languages and some other things that may or may not be languages; I couldn't tell.

There are four different APIs exposed via XML-RPC in the Freenet reference implementation. The Util API supplies utility methods for determining the version of your node and other sundry items that don't concern us. The Simple API provides a one-line method call to insert and request files but is not designed to handle big files. The Chunked API allows for chunked retrieval of large files. The Streaming API allows for efficient streaming retrieval of data. I'm going to cover only the Simple API, as it is completely sufficient for our purposes.

Even though XML-RPC client can be written in 21 languages, I like Java best, so all of the examples will be in Java. If you're writing your code in Java, the power of interfaces means you don't have to think about XML-RPC at all. If you want to call the API directly (for instance, if you're writing code for a plugin that will run inside the node), then you instantiate a LocalSimpleClient. If you want to call the API via XML-RPC (for a standalone client), you then instantiate a RemoteSimpleClient. Either way, the rest of your code looks the same.

Using a LocalSimpleClient involves some parameter setting that isn't very interesting, and useful only if you're developing a node plugin, so I'll just cover RemoteSimpleClient. You instantiate a RemoteSimpleClient with a URL pointing it to the XML-RPC server. If your XML-RPC server is running on the default port as of the 0.3.8.1 Freenet release, your code should look like this:

SimpleClient client = new
RemoteSimpleClient("http://localhost:6690");

Freenet is essentially a distributed hard drive with various optimizations and security features. As such, the Simple API looks like a Hashtable with a mysterious extra parameter, HTL. This parameter is the "Hops to Live" or, in other words, how many nodes you want to search before you give up. This number can be tricky to guess. The larger it is, the longer you have to wait for it to timeout if a file isn't in the network. However, the smaller it is, the greater the chance is that you won't find a file when it is indeed in the network. I recommend you set it high (say 100) and learn Zen-like patience.

Apart from guessing an HTL parameter, requesting and inserting files using the Simple API is simple and obvious by looking at the interface, but it's not anything you couldn't do from the command line. For a more exciting project, we must implement our gaming API.

A gaming API needs to: 1) track who wants to play, who is playing and who is watching, etc.; 2) match prospective players to start games; 3) route moves to players of a game; 4) provide an engine to check for validity of moves, states and score players; 5) provide a database of wins, losses and scores; and 6) a provide rating/ranking engine.

I'm supposed to be writing about Freenet more than gaming engines, so I'll only cover the first three needs at the moment. Number four should be done by a dedicated and modular piece of software so that different game engines can be plugged into the generic architecture. Items four through six contain issues of reputation and trusted relationships that should keep any self-respecting P2P programmer up at night pondering cheating, lying and control of information resources.