That’s great news @britzl @Mathias_Westerdahl! Thanks for letting us know this early!
I’m trying to use the new extension, but I’m getting this error:
Should I set-up something else to be able to use the new build system? Cheers!
Thanks!
Currently it’s using TCP_NODELAY, but I’m also in the process of adding a similar function for TCP_QUICKACK, it should be available in the defold beta later today. However, I’m not familiar with the quick ack functionality, so I’m not sure if one needs to set it once, or several times. I hope someone will help with this info 
Also, TCP_QUICKACK isn’t supported on iOS/macOS and Windows.
Ah, I should have been more clear. You need the 1.2.173 beta of Defold too to use it, since we’ve added a lot more functionality to the dmSDK (e.g. socket.h)
EDIT: Defold 1.2.173 BETA
PR for quick ACK is here: https://github.com/defold/defold/pull/5162
I’m also not sure of the implications of quick ACK. is it always beneficial to have it enabled regardless of how the socket is used (I’m thinking HTTP connection vs socket used in a game)? I also saw in a SO post that the quick ACK socket option can be changed by the system and that we might have to set it after every send.
Thanks for the clarification, it works using the beta.
So far the Desktop build is working just fine with Colyseus, but the HTML5 build is not connecting to the right endpoint (notice the URL segments and query string in the console log)
I’m going to provide some feedback on this thread as I face the issues… Hope not to annoy you all! 
The HTML5 version has a different code-path which explains the difference. We’ll look into this on Monday.
@endel I’ve uploaded a new version with a separate code path for the html5 code. I did make a quick stab in the dark by adding the path to the url when getting the address (trying to compare the functionality with the old extension), but I currently have no way of knowing if that works. You don’t happen to have an example echo test server on such an endpoint I could test with?
EDIT: To use this, update the beta editor (or bob.jar) and refetch the extension.
Awesome, thanks @Mathias_Westerdahl! Now it works fine, I’ve added a note to your commit here: https://github.com/defold/extension-websocket/commit/071adac853b2844e2fb5eb0ff8a20699c17f015a#r42065637
Going to do some more testing during the week
Thanks for testing!
I’m glad it worked, it was a bit of a stab in the dark
I’ve uploaded a new version of the extension without the superflous ‘/’.
Tried this in my colyseus project (using @endel’s new websocket-extension branch). It seems to work without problems in the html5 build. But for some reason, I am getting an error when running from the editor (Project/Build). I am using Windows 10, Defold 1.2.173 beta and latest websocket extension.
ERROR:WEBSOCKET: Failed to find the Upgrade keyword in the response headers
ERROR:WEBSOCKET: Response:
"HTTP/1.1 101 Switching Protocols
Server"
DEBUG:SCRIPT: websocket error: Failed verifying handshake headers:
Failed verifying handshake headers:
rver
Thoughts on what could be the issue? I am connecting via wss, nginx has been configured for http upgrade. It works fine with my html5 build, but not when running from the editor. I don’t have this issue with the old defold-websocket setup.
The Html5/Emscripten sockets are actually already websockets, so they don’t have to do the handshake.
For the other platforms, the extension expected the websocket handshake return headers as specified here:
https://tools.ietf.org/html/rfc6455 (see page 7)
I’ve already seen one discrepancy from that standard, and looking at your printout of the headers, you server doesn’t really conform 100% either:
"HTTP/1.1 101 Switching Protocols
Server"
Did the old extension (defold-websocket) work for you?
Our goal is to make them as close as possible in supporting the servers they already work with.
Perhaps @endel has some insight into this?
Yes. The old extension works for me and I don’t have this same issue.
Using this tool, does it successfully connect to your endpoint?
https://www.wss-websocket.net/
I’m wondering if I should skip checking for the “Connected”/“Upgrade” headers, even though they’re part of the standard.
Also note that in his post, the returned headers are following the standard:
So the question is, why isn’t your request returning those headers? 
I did a few more tests, and if I do a case-insensitive compare:
strcmpi(value, "Upgrade") == 0
in handshake.cpp the websocket seems to be upgraded successfully. For some reason, my server setup appears to be sending a header “upgrade” instead of “Upgrade” during the handshake (even if my nginx config also lists “Upgrade”).
With above change, I am able to connect successfully to the server and send/receive data properly. I have a new issue of “lost” messages that only happens in the desktop build as well, but this looks like colyseus related, so I will just wait till @endel releases a new colyseus client update to test things again.
Ok, that’s good to know. I’ll update the extension with a case insensitive test then.
Hi there, sorry the delay to provide more info here.
So, the example project from colyseus-defold worked fine, but after trying to use it on a real project (Raft Wars) I was losing my hair because some messages seemed to arrive inconsistently, I thought the problem was on my end, then today I’ve tried to reproduce the issue using a plain WebSocket server and the new Defold extension.
Apparently, the new defold extension is not able to dequeue messages arriving real fast one after another. I’ve prepared an example repo where you can see the issue happening, here: https://github.com/endel/defold-extension-websocket-issue
There are a few things to observe in this example:
1. Right after the connection is established, the server is going to send 4 short text messages and 4 short binary messages - this is to test if the client is going to receive them properly
2. Sometimes, this warning is displayed in the client-side, and no messages are received (need to keep closing & compiling the Defold project again until it works)
WARNING:WEBSOCKET: Waiting for socket to be available for reading
3. Most of the times, only the very last message is received by the client:
DEBUG:SCRIPT: received message, (RAW) =>
DEBUG:SCRIPT:
DEBUG:SCRIPT: (BINARY VERSION) =>
DEBUG:SCRIPT:
{ --[[0x115b5f870]]
1 = 4,
2 = 4,
3 = 4,
4 = 4
}
If we use setTimeout() for each message being sent by the server, none if this happens. The problem really seems to be when we have a bunch of messages enqueued one after the other.
Let me know if I can help with this! Cheers!
Love it! Many thanks for providing this feedback.
I created an issue to track this: https://github.com/defold/extension-websocket/issues/6
Thanks for the excellent repro!
I’m not really sure why the extension cannot read the message, I can clearly see that the server sends the “Upgrade” handshake, but when the extension wants to read that, there’s no data left to read, thus producing the “Waiting for socket to be available for reading”.
I’m looking further into this…