Skip to content

Archive for


Browsers as dumb terminals

A recent announcement by Gaiki about streaming video games over the web reminded me of a project I’d been toying around with for a few months with Chron X.

My implementation of it (See below for the gritty technical details) allows any desktop application to run directly in a web browser, without any special coding work to move it over. We use the web browser as a dumb terminal, sending it video and receiving keyboard and mouse events. The browser handles all of the rendering, the positioning.. It decides what to put where, using the browser to just display what it sends, like a TV would display a video.

As networks become faster, I suspect we’ll see an increasing number of companies releasing applications using this model-

  • Legacy applications are the easiest and most obvious usage- Companies already expose legacy applications via citrix, bringing their applications to the browser is the next natural evolution.
  • Many developers are substantially more familiar with desktop tools than they are with web technology, which decreases development time.
  • More importantly to many web-developers, however, is that it it allows per-pixel control of layout and complete control over the entire process. You don’t need to deal with incompatibilities between the way different browsers display the content. It’s all streamed, pixel by pixel from your centralized server.
  • Finally, for games, it alleviates the need to have powerful hardware for rendering 3d- If your servers can pre-render each frame and send it over the wire, even moderate power machines will be able to handle the highest settings.

I’m sure other people have done this better and with more talent.
It’s a fun new world, and it’ll be interesting to watch more and more services start to be rendered in the cloud.

Screenshot-Mozilla Firefox

The technical details of my particular implementation follow- Unless you’re interested in the nitty-gritty details of my implementation, feel free to consider this the end of the article 😉

As I had mentioned earlier, Chron X 1 requires that each user have a publicly routable IP address, similar to Diablo, Quake, or other games of it’s Era.

I had set up a system to provide an IP address on demand, but running Chron X 1 is still less convenient than it should be, since it runs full-screen, has to be installed on each machine, and (because of limitations in the tunnel) blocks all other programs from contacting the internet while it’s running. This is less than ideal, and a great deal of the motivation behind creating Chron X 2, which will run properly in a browser.

Until CX2 is ready, however, I put together a hack that might be useful for other people who want to expose legacy applications over the web.

My first step was to ensure that the game runs under WINE, since paying for Windows licenses for each user would be prohibitive. This required custom-patching WINE to use CreateScalableFontResourceW, which is needed for the legacy Chron X client, but not in the general WINE distribution. Luckily for me, Jeremy White had written most of the needed code, so I was able to patch it in to the most recent version, clean up a few edge cases, and get the game running.

The next step was to install Xen, which allows me to create virtual machines on the fly. I put together a quick and dirty php script which spawns Xen sessions on demand, so I could create them for users on login..
Unfortunately, booting a Xen server takes a good 30 seconds, which is longer than most people want to wait while logging into a web-service. For now, I’ve just set it to pre-create the accounts I need, but if I ever went forward with this hack I’d set it to keep a pool of pre-running servers in reserve, and then start up additional servers to re-fill the pool.

The next step is installing a VNC server. This is fairly routine- In my case I used tightvnc. I set a per-user password, and set it to autostart on the server.

I set each user’s .profile to immediately start the game and re-start it when the player’s quit.
while true;do wine /home/chronx/cx/ChronX.exe; sleep .1;done

I set up a Flash-VNC bridge in /var/www, and modified the php script to set a random VNC password and write it into the index.html.

The Game is playable in a web-browser. The speed isn’t nearly as fast as a native-client, but it’s usuable. It looked like the biggest problem was the Flash->VNC bridge. I installed xrdp, which is allows users to use Remote Desktop Connection to connect to VNC servers. This solution still allows people to connect through the browser, but enables them to alternatively use a native client that’s already build into windows.

The next step was authentication.. This was seemily the least-complicated part of the hack. I set up one central authentication server which authenticates usernames and passwords normally. (In our case this uses LDAP, but it could just as easily query a mysql database, etc). If the login succeeds it sets a cookie with a uniqueid that’s good for an hour. That server then redirects you to the correct server as specified in your profile.

I modified the index.html file above to do a check for the cookie and reject you if it doesn’t see it.

$cookie = $_COOKIE["CX15-Session"];
$result = get_web_page("http://authorization-server/auth.php?SESSIONID=" . $cookie);
if ($result != 1) { echo "Sorry, internal error. Are you logged in?"; die;}

All in all, I’m happy with this implementation, but the flash-bridge is still the weakest point. Java vnc viewers give substantially better performance, but take longer to download and users tend to dislike them.

It’s a fun new tool in the arsenal- Not everything needs to be rendered directly on the client, and in my case in particular, rendering on the server makes life a lot easier 😉