In a windows implementation, I found the following code allowed me to read the test string below:
Client:
var socket = new Socket();
socket.connect("localhost", 1234);
socket.writeUTFBytes("test.¤");
Neko threadserver:
override function readClientMessage(c:Client, buf:Bytes, pos:Int, len:Int) {
// find out if there's a full message, and if so, how long it is.
trace("testing the string reading capability...");
var complete = false;
var cpos = pos;
while (cpos < (pos+len) && !complete)
{
//check for a terminator symbol (¤) to signify complete message
complete = (buf.get(cpos) == 164);
cpos++;
}
if ( !complete ) return null;
With an HTML implementation for the client, I found that the buffer, instead of returning the string, returns a lot of information about the browser being used.
The packet you are receiving on server side is the HTTP message used for Websocket handshaking.
That’s because HTML5 only supports Websockets, so your server has to handle them.
You should find a few implementations of Haxe servers supporting Websockets on the Web, like this one :
Thanks very much for your response. I learned a lot from reading that code, and also from this link, which I include to help future people that have the same issue.
So I now have managed to get the systems to successfully complete the handshake.
However, I’m having some problems with communications. If I send a single webframe then things work more or less ok, but this webframe appears ‘over’ a copy of the original handshake request.
Sending another webframe seems to append webframe 1 and webframe 2, then have those appear over the original handshake request.
The attached image might help explain this a little better.
I’m guessing this is a problem with the buffer somehow not being cleared between messages? Is there a way to do this with a command?
Could you show how you send the message from the client ?
Handshake should be done only once, so if you receive another HTTP request from the client, it might be because the server response is not valid.
FYI, returned hash should be : Base64.encode(Sha1.encode(wskey+"258EAFA5-E914-47DA-95CA-C5AB0DC85B11"))
I’m using openfl.net.socket to send the message (note I get the same error when I try to use js.html.WebSocket)
for the initial connection I use
socket.connect("localhost", 1234);
then, later in the code I send the message with socket.writeUTF("The quick brown fox jumps over the lazy dog");
I am pretty sure the initial handshake works out ok - if I try to use socket.writeUFT before connecting the server doesn’t respond to it. Once the server sends the handshake response I see that using socket.connected gives me a ‘true’ response.
Do you get any errors in the web browser console ?
Also Chrome & Firefox provide a “Network” tab in the Dev tools (F12), which often helps to debug such issues.
I looked deeper into the threadserver code and managed to fix this by clearing the buffer between messages.
It looks like this was specific to the way the neko.net.threadserver code was implemented and interacts with websockets (i.e doesn’t seem like an issue with openfl.net.socket, and I had an earlier version working very well with a desktop target). Once I have my code working I’ll look at this during the tidying up process.
