ogoglio

Ogoglio on Parallels

My main development machine is a MacBook Pro so to maintain support for Internet Explorer I rebooted my machine into XP, updated the development environment, built, and then tested.  This would take about 45 minutes so I often wouldn't do it before checking in new features of Ogoglio and inevitably I wouldn't take into account some quirk of Windows and IE support then would break.

This last week I decided to stomp out all of the remaining IE bugs in the Ogoglio viewer and I started by booting XP in Parallels Desktop and fixing all of the browser test pages.  Much to my surprise, all of the new browser tests pass, including the Java3D initialization, but when I tried to open the ogoglio viewer it failed.

To make a long story short, I poked around and found that we could make Java3D boot on machines with low-end graphics cards which can't antialias or double-buffer.  Now Parallels renders Ogoglio (badly) and I can debug WinIE against my OS X development kit.  It isn't pretty, but it beats rebooting.

Comet for Everyone

Though I have an active hand in platform building, my central role on the Ogoglio project is to keep my eye on our long term goals and to understand the culture and infrastructure in which we deliver on those goals.  In that role I have the occasional pleasure of pointing to someone's work and talking about cultural ramifications.

The other day Ian Smith posted a technical demonstration of Comet, which is a low level technology for communication between your web browser and an Ogoglio server.  What he didn't mention is why we're using Comet in the Ogoglio platform and what it buys us.

A little background: When you load your average web page there are a lot of connections made to the remote servers using a common language called HTTP.  If there's one thing the Internet can pass quickly and cheaply, it's HTTP.  More importantly, every IT department in every organization makes very sure that their networks and firewalls allow HTTP traffic.  Without HTTP there is no web.

The problem with using HTTP for Ogoglio spaces is that it wasn't originally built to send events like "Body started moving North" and "Door slammed" which need to move quickly so people don't see odd, jerky motion and which need to move in both directions between the client and server.  For this reason no MMO or social world uses HTTP for world events and instead they use hand-tuned systems.  If you've ever tried to play an MMO from inside a corporate network the chances are that it didn't work unless someone in the IT department was also a player and secretly opened the firewall to non-HTTP traffic, which they're loathe to do for security reasons.

Enter Comet.  Enough web developers needed our flavor of bi-directional, fast event communication that they've worked out a way to juggle the details of HTTP a bit to use them in a new way.  It's a bit like putting serious English on a pool ball, because Comet does things with HTTP which are a bit unexpected but which stay within the rules of the game.

Ogoglio spaces now use HTTP for all communication, which means that they're going to work where other spaces fail and they're going to be delivered without asking your IT department to make your network less secure.  This is directly in line with our goal of enabling diverse communities of people to collaborate in online 3D spaces because diversity doesn't stop at the firewall.

Comet Protocol

O Comet, Where Art Thou?

I have been working to move the ogoglio server and viewer to the comet protocol.  The advantages of comet seem pretty clear, it's a standard, asynchronous and pretty fast protocol built on top of (or perhaps underneath, depending on how you think about it) HTTP. When we I went googling to try to find some simple, complete comet programs with a client and server that did something, there were surprisingly few and basically none written solely in Java.

So, I've written one for the community with my own commentary about what I've learned about comet.  You can download the client-source and server-source, or if you just want to run the code, the og-ex (for the server) and the client-jar.

How to install it

If you are just running the war, you can just drop it into your tomcat (6.0.14) webapp directory and it will get installed into /og-ex/add on your tomcat server.  The client is run by using

java -cp client-jar com.ogoglio.example.AddClient http://localhost:8080/og-ex/add 1

You may need to modify the URL based on how you have your local tomcat configured.

If you want to build from source and you have a copy of maven 2, you  just go into the top level directory of each  project (the one with  the .pom file) and type

mvn clean install

This will result in the war file in the server project's target directory and a jar file in the client project's target directory--just like the ones you can download above.

If you are building without maven, you'll to go into the directory structure and compile the sources (3 files for the server, 2 for the client) by hand (ugh).  That done, you'll need to build the war file with the included web.xml file for the server.  It's probably best to download the war file above and mimic its directory layout when you do the war creation.  When you build the client, you'll either to create a jar file or point the -cp option of java at the directory where the client class files reside.  I suppose you could also do CLASSPATH environment variable shenanigans if you prefer.

What Does It Do?
The server in this example maintains a collection of 10 integers.  These are supplied by clients and the collection is updated when a client sends a new value so that the collection is always the 10 most recent values.  Further, when a client sends a value the server asynchronously (!) updates all other clients--but not the sender--with the set of values it currently holds.  For fun, when a client receives this update it dumps out the sum.

The client side program (com.ogoglio.example.AddClient) prints on the terminal a display like this:

$ java -cp target/add-client.jar com.ogoglio.example.AddClient http://localhost:8080/og-ex/add 2

[purple 7] SERVER ---------->Current sum is 0
[gray   1] SERVER ---------->Current sum is 0
[purple 7] SERVER <---------  35
[gray   1] SERVER ---------->0 + 0 + 0 + 0 + 0 + 0 + 0 + 0 + 0 + 35 [ sum is 35]

Let's explain what you are seeing here.  We gave the program a second parameter of 2, meaning that  we would like to  run two copies of the client. Each one runs on its own thread and we give them names like "purple 7" so it's easier to understand the output.  You can see that the server responds to the two connections with it's initial greeting, "Current sum is 0."  This is a normal HTTP-style request/response.  However, because we are using comet the two clients stay connected.  Every few seconds (chosen randomly) one of the clients sends a message with an integer to the server.  In this example purple 7 sends the server "35".  You then see that the server updates gray 1 with the new collection of values which is the initial set of 0's the server starts with, save for the last value which has been replaced with purple 7's 35.  This will continue until you kill the program.

Peering Inside With A Browser
If you want, you can retreive the current sum with a GET (e.g. by using Firefox) on the same URL.  That is why clients initially get the "sum" string above--that is so that we can immediately display that string in a browser.  The server then immediately terminates the comet session for clients that use GET, so the browser's user gets what she expects.

Further, you can add integers to the queue from the browser.  You do this by adding them to the url, like this:

http://localhost:8080/og-ex/add/9/11/13

This puts 9, 11, and 13 in the queue.  This happens before the sum is calculated so the browser sees the effect of this insertion.

I find it informative to run a single client (2nd parameter to the AddClient of 1) and use the browser with extra integers in the URL to play with things.  This small number of clients makes it easier to see whats happening.

Server Logs
The example server dumps many interesting things out to the server logs, usually catalina.out in your logs directory.  These are more to help a developer understand what things happen at what times inside the server processes various comet events. 

We have been playing around with custom avatars for guests.  Here you can see silhouette avatars mingling in one of the event halls we're putting together for Tomorrow Space:

Of course, we'll need to do something about the hovering names running together, but that's something for tomorrow.