protocol vs build target

Something I’ve stumbled on today, with respect to the class. I suspect the protocol used by the Socket changes depending on the build target. So for HTML5, it’s using WebSockets, but for all others, I’m not sure what it’s using, perhaps a standard TCP socket?

I have a basic WebSocket server running in Node.js for testing. It’s able to receive my app’s data so long as I build to HTML5.

If I build to Neko, HashLink, Windows (C++), Flash, my WebSocket server seems to receive no data. The Windows build actually hangs in the attempt to connect. Is this expected behaviour, am I right in assuming the other targets are using a protocol incompatible with WebSocket? Is it possible/necesarry to force WebSocket on other build targets?

My basic Node.js WebSocket server:

const WebSocket = require('ws'); 
const wss = new WebSocket.Server({ port: 443 });
wss.on('connection', function connection(ws) {
  ws.on('message', function incoming(message) {
    console.log('%s', message);

My OpenFL app:


import openfl.display.Sprite;
import openfl.utils.ByteArray;

class Main extends Sprite {
	private var socket:Socket;

	public function new() {
		socket = new Socket("localhost", 443);
		socket.addEventListener(Event.CONNECT, socketConnect);
		socket.addEventListener(ProgressEvent.SOCKET_DATA, socketData);
		socket.addEventListener(Event.CLOSE, socketClosed);
		socket.addEventListener(IOErrorEvent.IO_ERROR, ioErrorHandler);
		socket.addEventListener(SecurityErrorEvent.SECURITY_ERROR, securityErrorHandler);

	private function socketConnect(e:Event):Void {

	private function socketData(e:ProgressEvent):Void {
		var bytes:ByteArray = new ByteArray();
		if (bytes.length == 0)


	private function socketClosed(e:Event):Void {
		trace("Socket closed by server.");

	private function ioErrorHandler(e:IOErrorEvent):Void {
		trace("Socket IOError: " + e.toString());

	private function securityErrorHandler(e:SecurityErrorEvent):Void {
		trace("Socket SecurityError: " + e.toString());

You might need this?

Other platforms are standard TCP protocols.

Thanks @rainy.

I’ve been exploring a few of these, particularly the more recent ones (that support Haxe 4) but I’ve encountered a lot of issues with those and they’re not particularly well documented.

A deadline is looming and I’m still tossing up development options :sweat:

Thank you for confirming that non HTML5 targets are using the standard TCP protocols too :+1:

It would sure be nice if we had some code available to implement WebSocket client-side code in Haxe for other targets. Here’s some specific details:

I think most people have two end points in their backend, however having only one type would sure be nice

With web perhaps being the lowest common denominator, I did wonder that WebSockets probably represent the most cross-platform consistent means of communication. I believe support for WebSockets exists in some form for most (all?) targets, whether natively or via 3rd party libraries and extensions.

For the purposes of this project, I ended up building the server component with Node.js and the ws WebSocket library.

One aspect of the Flash API that OpenFL does not (yet?) implement, is the SocketServer, so if I’m not mistaken, even if WebSockets were supported for other targets in OpenFL, they would only be effective as clients, not listening servers.