Websocket module

[Faless]

Webassembly support is client-only for obvious reasons.
Other platforms support both client and server using libwebsockets.

Libwebsockets is released under LGPLv2.1 + static linking exception (and others, like not having to distribute the license itself, see the LICENSE.txt for details).

The module itself can easily work with other libraries, since it's done with custom implementations of generic WebSocketClient WebSocketServer and WebSocketPeer classes to allow for webassembly native implementation.

The module also supports the Multiplayer API, but beware that websocket uses TCP, and it's always reliable. This means that latency will grow indefinitely if you send too many RPCs.
This is fine for most non-realtime games, e.g. turn based, browser games, etc. and it's a first step toward having both web and server implementations done with godot, same scene, seamlessly.

The next step, when time allows, would clearly be WebRTC.

EDIT:
Closes #5806.
Brings #14627 to a better state.
Partly unrelated but #9624 should be closed as HTTPClient works in 3.0 for webassembly export.

[Faless]

I can't explain the failed build on X11 platform. It's my main platform, and it builds fine here with both builtin and distro's openssl

[Faless]

In any case SSL with lws is not yet implemented properly, so I might just disable it for now.

[akien-mga]

Also builds fine for me on X11 (Mageia 6 x86_64). Might be related to the OpenSSL version on Travis/Ubuntu 14.04?

[Faless]

Might be related to the OpenSSL version on Travis/Ubuntu 14.04?

You are totally right, apparently LWS requires OpenSSL >= 1.0.2 and ubuntu 14.04 seems to still have OpenSSL 1.0.1f . I for once agree with you @akien-mga that ubuntu packages sucks.
See warmcat/libwebsockets#666 (comment) and warmcat/libwebsockets@e7bf0aa

I see that function is protected by an ifdef block, I can try to disable SSL hostname verification and maybe try to implement it in a compatible way later.

[Faless]

Okay, it builds now, I'm pretty positive the client no longer does SSL hostname verification though.

We could fix it in the lws callback. I'm not sure if I'll have the time before January, but I'll try.

[akien-mga]

Otherwise we can just build on travis against the builtin openssl which is 1.0.2 (might increase build time a bit, but with the cache it shouldn't be too bad).

[Faless]

Otherwise we can just build on travis against the builtin openssl which is 1.0.2 (might increase build time a bit, but with the cache it shouldn't be too bad).

I guess official export templates for linux are shipping with builtin openssl.
In that case I'd say let's just bump openssl min version requirements :)

[akien-mga]

I guess official export templates for linux are shipping with builtin openssl.

Yep: https://github.com/GodotBuilder/godot-builds/blob/master/.travis.yml#L26

In that case I'd say let's just bump openssl min version requirements :)

Go ahead. You can remove your last commit then and tweak .travis.yml so that it builds against the builtin openssl.

[Faless]

@akien-mga you said tweak, I tweaked 😉

[akien-mga]

Thanks a lot for your contribution!
We are now entering a strict release freeze for Godot 3.0 and will only consider major bug fixes. We won't merge new features and enhancements anymore until 3.0 is released.

Moving this PR to the 3.1 milestone, to be reviewed once the release freeze is lifted. It could eventually be cherry-picked for a future 3.0.1 maintenance release if it doesn't change the user-facing APIs and doesn't compromise the engine's stability.

[akien-mga]

It seems to fail building on X11 and Windows.

[hpvb]

also the mbed_tls stuff should probably be removed. It seems like a bad idea to have two separate ssl implementations in the tree.

[reduz]

Actually if anyone wants to replace openssl with mbedtls in Godot, that could be good.. right?

…

On Feb 1, 2018 12:20 PM, "Hein-Pieter van Braam" ***@***.***> wrote: also the mbed_tls stuff should probably be removed. It seems like a bad idea to have two separate ssl implementations in the tree. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#14888 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AF-Z28O2hvU63TgbDCPmBX4fd88nFKC4ks5tQdYvgaJpZM4RJSgh> .

[hpvb]

@reduz I guess that'll depend on whether or not curl can work with mbedtls.

[Faless]

It seems to fail building on X11 and Windows.

Yes, my bad, I forgot to update it to comply the last minute change to the NetworkedMultiplayerPeer API (peer.transfer_mode property).
Should compile again now (does for me on X11)

[akien-mga]

I'd also support dropping openssl in favour of a more lightweight alternative.

At least in raw number of files, mbedtls seems quite smaller than openssl: https://github.com/ARMmbed/mbedtls/tree/development/library https://github.com/ARMmbed/mbedtls/tree/development/include/mbedtls

[Faless]

also the mbed_tls stuff should probably be removed. It seems like a bad idea to have two separate ssl implementations in the tree.

@hpvb the mbed_tls code does not get included by modules/websocket/SCsub so it does not (should not?!) be compiled at all (it doesn't in my tests).

It's left there because I prefer to not fiddle around with library files and allow to simply copy/paste them from the library source when a new version is released. It's true that it makes the Godot source tree slightly bigger but the resulting binary is not affected at all

[hpvb]

@Faless we've previously always deleted files that we don't build from thirdparty/ (look at what was done to thekla_unwrap for instance).

[akien-mga]

Indeed, we always copy only what we need from thirdparty sources, which is why https://github.com/godotengine/godot/blob/master/thirdparty/README.md has sections describing for all libraries what files should be extracted from the upstream tarball or repo.

[Faless]

we've previously always deleted files that we don't build from thirdparty/ (look at what was done to thekla_unwrap for instance).

I see, well, I'll check what files I can remove then.

[akien-mga]

Could you squash that last commit into the first one? This way we'll never have added this code to the repo ;)

[Faless]

Could you squash that last commit into the first one? This way we'll never have added this code to the repo ;)

Sure, I'll wait for the tests to finish so I'm sure it compiles everywhere (did some test here, but only cross-compiling from Linux)

[Faless]

Sqaushed commits, updated to latest Emscripten API

[LikeLakers2]

Apologies if I'm missing something, but I'm looking at the files under modules/websocket/, and I'm noticing several instances under the lws_*.cpp and emws_*.cpp files where there's a get_connected_port function. At a guess, this is probably a function to get the port that's being used for the connection. So assuming my guess is right, why are all of them set to return a static 1025 rather than the port variable? It just seems odd, like it was being used for debug and wasn't removed for production.

[Faless]

If I recall correctly the interface requires it, but it was never implemented. If you need it, open a new issue on GitHub. Otherwise, if the interface does not require it, we might just remove it. On Feb 7, 2018 06:53, "LikeLakers2" <notifications@github.com> wrote: Apologies if I'm missing something, but I'm looking at the files under modules/websocket/, and I'm noticing several instances under the lws_*.cpp and emws_*.cpp files where there's a get_connected_port function. At a guess, this is probably a function to get the port that's being used for the connection. So assuming my guess is right, why are all of them set to return a static 1025 rather than the port variable? It just seems odd, like it was being used for debug and wasn't removed for production. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#14888 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABnBbl6vHz4Jmp6p7nmhu9L6rXQbSawwks5tSTpagaJpZM4RJSgh> .

[matty]

Would just like to add that I have built Godot from master on Win 10 and I am using the WebSocket implementation and it's working well so far.

[endel]

Hi @Faless, is this WebSocket implementation tied to Godot Engine internals, or is it possible to use it in other environments as well?

I'd like to implement a Colyseus client targeting any C++ engine (Cocos2D-X, Godot, Unreal Engine), and I'm wondering if using this WebSocket implementation would suit this need.

Thanks a lot! Enjoy the holidays!

[Faless]

@endel when using gd_mp_api=false (default) both WebSocketClient and WebSocketServer simply acts as a standard-conformant implementation of RFC6455, so they will be compatible to any other RFC6455-conformant software.
If you enable gd_mp_api=true (i.e. you use it for high level multiplayer API), the internal Godot protocol for peer exchange and rpc/rset relaying is used on top of the standard WebSocket protocol (so it will be compatible, but data will be always transferred as binary, and will contain additional protocol data).

[joaopedrosgs]

there is any documentation about this?

[Faless]

@joaopedrosgs well, there's the official doc for the WebSocketClient class: http://docs.godotengine.org/en/latest/classes/class_websocketclient.html#description

[vini-guerrero]

Is there any tutorial on connectin this with a simple nodejs server? ( is that possible? )