Author: eigenbom

The cema crew, eightbitified -> http://eightbit.me/

After four years of paradise-hell, my PhD candidature is coming to an end. My thesis submission deadline is March 25th, less than 3 weeks from now. At which point, I’ll hand into the MRGS office four copies of my ~150 page document, describing how to generate funny looking blobs (see below) by simulating physical and biological processes. A single tetrahedron-shaped tear may emerge from my eye.

Guess who?

[flickr]set:72157625584482489[/flickr]

About 4-5 months ago,  I started thinking a lot about 3d printing and wanted to find an activity that Steph and I could do together. We found an activity that combined Steph’s flair for design, style and experience of jewellery with my experience with 3d graphics, modelling, and the like. We decided to try to make a ring.

Just a quick addition to my series of posts on the websocket  in haxe series (Part 1, Part 2) …

A significant issue with haxe remoting is that the allowed message size is constrained. This means that when passing parameters that exceed 4kb or so, you’ll get a nasty “message too big” error.

Based on code written by Anthony Loizeau(see this post), my haxe websocket library now supports arbitrarily large messages. It does this by splitting up the haxe serialisation string into pieces, sending them piece by piece through the socket, and then stitching them together on the other end.

Read this post for Part 1…

I have just updated the haxe websocket code significantly. I have made a websocket compatible ThreadServer and ThreadRemotingServer, and included some different examples of using these classes.

The code for this post is here.

In a previous post I explained how to create a socket connection from javascript to a server using Haxe. Unfortunately, this technique requried using flash as a proxy between javascript and the server. As I am working on a game for Mozilla’s game on competition I needed to find a flash free way. This is where websockets comes in. Websockets are a new standard way to open a continuous connection with a server. There are many articles explaining this technology and so I won’t try to. This article is about my adventure with setting up a WebSocket server using Haxe.

Update: I have added a tutorial to the Haxe site on how to use sockets with Javascript. You can find it here

After wrestling with Haxe and trying to get Javascript to communicate (via sockets) with a server, I finally figured it out. Haxe provides cool stuff for doing this, however it seems most of the documentation and tutorials for implementing realtime socket-based communication are for the Flash target and not for the JS target. What’s worse is that the socket support in JS is via a Flash proxy, this is a problem if you aren’t familiar with flash programming.

This post is about implementing a simple chat program using Haxe, where the front-end is in Javascript (+flash socket), and the back-end is running Neko. You can grab the example code here: haxejssockets

Looking around the web, there are some examples (here, here) of using Haxe, ThreadRemotingServer, and XMLSocket. However, I could not find one that used a javascript front-end (they all used flash.) In the Haxe standard library is an interesting object called js.XMLSocket, which allows you to use an intermediary flash socket to communicate with a server. It wasn’t obvious HOW to use this, though I eventually figured it out. See the code for details. What follows are the major problems I came across.

Usage of js.XmlSocket(…)

I wasn’t sure how to compile and supply the flash-based socket wrapper. See compile.hxml and JSClient for help on how to do this.

ExternalConnection is not initialized in Flash

This one stumped me for a while, and it turns out I was trying to connect the js/flash bridge before the flash socket was available. My solution to this was to add a delay to the js socket connection code. A better solution (if possible) would be to detect when the flash object loads and then try the socket connection, or to just catch the exception and repeatedly try to connect.

XML Policy file

Not being a flash programmer myself, I didn’t realise that flash requires a “policy file” which lets it know if it can open a socket connection to a server. But after some googling, I came across a haxe implementation of a policy file server (included in this example.) The policy file itself is cross-domain.xml and is fairly self-explanatory. The policy file server should listen on port 863.

Running “neko server.n” will run both the primary server and the policy file server.

Browsing the haxe ThreadRemotingServer API, I saw a reference to “policy file”, I assume this means that the HaXe crew have built in the policy file functionality into ThreadRemotingServer, but I was unable to get it  to work.

Conclusions

It is unfortunate that in Javascript land we have to use a flash object as a proxy for socket-based communications. Of course when websockets are ubiquitous we can use those. Preferably a technology like socket.io would be awesome to incorporate into Neko. Alternatively, work on a node.js target for server-side haxe would also be sweet. I’m not a web programming guy, so doing these things are probably out of my league, and after all, I’m just interested in making games, not middleware.

The code can also be browsed online at: http://hg.bp.io/public/misc/HaxeJSRemoting/