Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use wslay as a WebSocket library #30263

Merged
merged 7 commits into from
Jul 4, 2019
Merged

Conversation

Faless
Copy link
Collaborator

@Faless Faless commented Jul 2, 2019

I know, I know, another WIP, sorry! 🙏
I have a few intertwined PRs, this is probably next in line, then I'll move back to the Crypto one.

Why WIP? There are some edge cases when the client gets disconnected it does not emit the appropriate signal. I'm working on it. (plus few TODOs, mostly optimizations).

EDIT: No longer WIP, ready fro review.

Beside that both client and server are working. Client also support SSL (server should be able to do that easily as soon as the Crypto PR is in).

While I'm pretty happy with this work, I'm sure it's still not as stable as the other library, mainly because this Godot integration is less tested then the other.

It would be great if people who uses the WebSocket module could give this PR a try with their servers to verify I didn't mess up the handshake part ( ❤️ ).

Please report any issue you might encounter, I'll try to fix the edge cases mentioned above in the coming days.

Fixes #27632 (given the libwebsocket is dropped, and the new lib uses our StreamPeerSSL implementation).
Sadly, while the new library do include a .pc file, it does not seem to be included in Debian/Ubuntu packages, not sure about other distros.

@Faless Faless force-pushed the ws/wslay_pr branch 4 times, most recently from 37df4dc to 9d7a933 Compare July 3, 2019 12:34
@Faless Faless changed the title [WIP] Use wslay as a WebSocket library Use wslay as a WebSocket library Jul 3, 2019
COPYRIGHT.txt Outdated Show resolved Hide resolved
COPYRIGHT.txt Outdated Show resolved Hide resolved
@akien-mga
Copy link
Member

akien-mga commented Jul 3, 2019

Sadly, while the new library do include a .pc file, it does not seem to be included in Debian/Ubuntu packages, not sure about other distros.

I'll package it for Mageia to give it a try, and if that works I'll import it in Fedora too.

Edit: It actually is packaged in Debian/Ubuntu already in recent versions, as well as openSUSE: https://pkgs.org/download/wslay
They're not all on 1.1.0 though so not sure if they'd build fine.

@akien-mga
Copy link
Member

I added a conflict in the SCsub as I replaced all CPPFLAGS by CPPDEFINES.

if not env['builtin_libwebsockets']:
env.ParseConfig('pkg-config libwebsockets --cflags --libs')
if not env['builtin_wslay']:
env.ParseConfig('pkg-config libwslay --cflags --libs')
Copy link
Member

@akien-mga akien-mga Jul 3, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just for the reference (no need to change anything for now), the libwslay.pc pkgconfig file is not a given even on distros which package the library. wslay comes with two buildsystems, autotools and cmake, and only the former configures and installs the .pc file.

openSUSE use the autotools buildsystem and have thus libwslay.pc installed, so this will work.
Debian/Ubuntu use the CMake buildsystem, <troll>which, like any good CMake project, is CMake-centric and only installs its own .cmake config files</troll>. I'll open a ticket on https://salsa.debian.org/debian/wslay to suggest that they add a pkgconfig file. Edit: Done, https://salsa.debian.org/debian/wslay/issues/1

For Mageia I used the CMake buildsystem, and wrote a libwslay.pc file myself. I use the same patch as Debian for the CMakeLists.txt to get a shared library with proper soname and libwslay.so, instead of libwslay_shared.so (ugh).

@akien-mga
Copy link
Member

Builds fine locally on Mageia 7 x86_64. I tested both against the builtin version (default) and against the system-provided wslay package that I just packaged for Mageia :)

@akien-mga
Copy link
Member

@AshfordN , @RyanJEC, would you be able to test this PR on your WebSockets projects to ensure that there are no regressions compared to libwebsockets 3.0.1?

@Faless
Copy link
Collaborator Author

Faless commented Jul 4, 2019

@LikeLakers2 too could be interested

@LikeLakers2
Copy link
Contributor

LikeLakers2 commented Jul 4, 2019

I don't currently have any projects I'm working on that use websockets (the only one I've done so far, a discord library, I'm thinking of remaking from scratch anyways; that one will be a ways off though), but I do have a couple ideas for ones. I might as well test it when I get the chance.

@ghost
Copy link

ghost commented Jul 4, 2019

Seems to be working with my systems. Found no major hitches...Yet

Could we get an example on how to use WebSocketServer with SSL when it's ready.

Both client and server are supported on native builds (as usual).

SSL server is still not supported, but will soon be possible with this
new library.

The API stays the same, we just need to work out potential issues due to
this big library switch.
@Faless
Copy link
Collaborator Author

Faless commented Jul 4, 2019

Could we get an example on how to use this with SSL when it's ready.

Sure, client already works as before (just pass wss://mydomain.com, i.e. wss instead of ws).

Server will likely have two new parameters to listen e.g. listen(port, protocols, gd_mp_api=false, key=null, cert=null). When they are not null, SSL will be used. It should be quite straight forward after the crypto PR.

I'll make sure to implement it in the websocket_chat_demo and push it to the godot demo projects repository.

Thank you for trying this out!

@akien-mga akien-mga merged commit 550f436 into godotengine:master Jul 4, 2019
@akien-mga
Copy link
Member

Thanks a lot, awesome work! :)

@akien-mga
Copy link
Member

For the reference, if anyone wants to cherrypick this PR for their own 3.1 branch, you'll need #30419 too to keep feature parity.

@Faless
Copy link
Collaborator Author

Faless commented Jul 8, 2019

And also #30434

@djole1973
Copy link

why did you change/remove libwebsocket?

@Faless
Copy link
Collaborator Author

Faless commented Jul 19, 2019

why did you change/remove libwebsocket?

because it was bloated, broken, unmaintainable.
If you check the line changes, it's +4,052 −49,109. This already gives you a picture of how bad that library was for our needs.
Each library update changed the file structure completely and tended to break stuff (see #27560), so much that we had to roll back (#28568).
We couldn't use our socket implementation (i.e. the library do not support I/O abstraction) and the developer clearly stated he had no intention in accepting work in that direction.
The SSL support was troublesome due to their awful wrapper (#27632),
in general it's a badly written library, and the developer seemed more interested in implementing non-standard features instead of fixing existing issues.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Linux build fails against system libwebsockets using OpenSSL
4 participants