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/