Introducing OGRE

I have a project to show y’all. I’ve been working on it in my spare time for the last half year, and while its not yet complete enough to be considered a product, the underlying technology is solid.

OGRE is a platform neutral technology for taking a data set on a server and creating real-time replicated slaves on clients. It’s fast. Very fast. It’s also highly extensible so it’s likely that OGRE can be adapted to fit your project, not vice versa.

OGRE has a wiki full of documentation, including a white paper describing how the technology works, and an architectural overview describing the construction of the client and server libraries.

For the purposes of this introduction, I’d like to describe my vision of what OGRE could be. This vision is the reason I’ve been excited enough to spend 6 months of spare time working on this project. This is what I see OGRE being capable of if developed properly:

The dream

[the camera zooms in on your closed eyelids; the image shimmers and fades; this is a dream sequence…]

You have a client-server product. It’s a stock trading server written in Java; no wait – it’s a war simulator game in ruby; scratch that – it’s an oil tanker location tracking system in C#. Whatever: it’s a server in some language that, like most servers, maintains data in some persistent store, permits clients to access the data, and makes changes to the data when required.

Until now, your system has worked on a request-response basis like most other client-server applications. When a client wants to see the latest data, it requests the data and displays it to the user. If the information needs to be up to date, the client refreshes the screen every few seconds, re-requesting the data.

But one day you decide that your client is just too slow. The stock traders don’t want to know what the market was like ten seconds ago; or your gamers don’t want to know where the elf they’re trying to ambush was 10 seconds ago; or the oil tanker monitors don’t want to… well actually oil tankers are pretty slow so those users probably don’t care. But the bankers and gamers want to know now, dammit!

Increasing the rate at which the clients refresh their screens isn’t an option – your servers are already under enough load, and the clients’ network bandwidth isn’t infinite.

You’ve heard that OGRE solves this kind of problem, so you have a quick browse through the documentation. Ah ha! – you’re using Hibernate to access the database, and OGRE already has a Hibernate adapter so you don’t need to write your own. You drop 10 lines of code copied from the documentation into your application, compile and run it, and now your server is exposing a read-only copy of its data over the network.

Now to see if it works. You fire up Flash Builder (or perhaps Visual Studio if your client is in Silverlight, or Eclipse if it’s in Java), paste in another short code sample from the documentation, and then in around 20 lines you write the simplest UI you could possibly write to display the current state of the system. You launch the new UI, and it displays a copy of your stock prices (or war game or ship locations :o). As the data on the server changes, the new UI updates automagically, rendering new information within a few milliseconds of a change happening on the server.

Just for a laugh, you launch 1000 instances of the client. The server’s network and CPU stats hardly even register the difference.

The demonstration

[You wake suddenly, sitting bolt upright in bed. Was it really just a dream?]

OGRE isn’t there just yet, but the technology has been proved with a Java server and client. More languages are coming soon, probably with ActionScript first. Here’s a video of OGRE in action running the friendgraph demo included in the source distribution:

If you’d like to get involved in developing OGRE, especially if you have a project you’d like to try it on, then get in touch.