Cross platform sockets

[stephenberry]

Cross platform sockets

• Adding glz::socket and glz::server for TCP networking
• Builds upon these low level tools to replace glz::asio_server with glz::repe_server and glz::asio_client with glz::repe_client

Important

This code is cleaner and more future proof using std::format. When this is merged we will drop support for GCC 12 to support std::format.

Removing asio

This change replaces the glz::asio_server and glz::asio_client with glz::repe_server and glz::asio_client.

• Removes the asio third party dependency
• Allows recursive request calls with clients
• Allows us to develop networking for Glaze at a faster pace
• Allows us to optimize networking
• Allows tighter integration with RPC and network protocols (REPE, etc.)

[stephenberry]

Thanks for the feedback. Yes, currently the threading is on a per client basis, which isn't the best approach for a lot use cases. I plan to add a thread-pool solution as well as coroutines in the future. This is just an initial implementation to figure out the API and architecture.

[sam20908]

Just wondering: does this plan to support websockets? Or is there a way I can attach existing websocket to this?

[stephenberry]

@sam20908, yes within the next few months we plan to add Websocket support. The goal is to have the Websocket protocol separate from the socket code as well, so either the protocol or the socket code could be swapped out.

Right now we're working on cross platform coroutines with will be added to Glaze to support efficient server implementations.

[sam20908]

Nice to hear! I realized that is there a way one can use their own connection? E.g. I use MBedTLS to create a TLS connection (adding TLS support for Glaze sounds like pain)

[stephenberry]

Yes, I'd like to use templates on the sockets and create a general wrapping interface that will allow any networking library to work with the rest of the protocols, coroutines, etc.

[Nother62]

Hey,

Is there an ETA for when this PR will be merged into the main branch? I would love to use this for my current project, which would improve my current implementation of RPC.

Thanks

[stephenberry]

We're still figuring out the best approach to handling the underlying concurrency/scheduling. It's hard to say when this will get merged. I would say it will probably take until the end of September. We've decided to use https://github.com/NVIDIA/stdexec, which has been accepted into C++26. It could be sooner, but I don't want to disappoint.

[sam20908]

btw im wondering if theres a reason why you're implementing ur own sockets instead of having the users getting their own sockets setup and just parse the json response using this library?

[stephenberry]

The socket implementation has to be somewhat tied to the scheduler (I think). I wish https://github.com/dietmarkuehl/stdnet were further along, but it isn't mature and is not cross platform. As much as possible we want to separate the sockets, scheduler, payload spec, and RPC spec, but we need cross platform versions of all these that we can iterate on to figure out a general solution.

[sam20908]

I don't understand, there are cross platform libraries that handles socket connection. What does this do that other socket libraries don't

[stephenberry]

Currently Glaze uses asio, and I intend to still allow asio sockets. I've also experimented with libuv sockets. But, cross platform sockets is the easiest part of this implementation and it would be nice to not need third party dependencies.
There's also the fact that we'd like to eventually handle HTTP3 with QUIC, which asio doesn't have support for. One can argue that just simple UDP sockets can be used underneath a QUIC implementation, but then why bring in a big dependency like asio to use only a tiny piece of it. There are also some optimizations that get easier to manage when it's possible to manage the socket code oneself, particularly when it comes to header handling in various protocols. The project I'm working on has networking needs for various context, web UI, hardware interfaces with extremely low latency, and more, so there's a lot to consider.

[sam20908]

ok that makes more sense, i look forward to use it in my project when websocket support comes lol