Wrap the new networking APIs about steamworks-rs HOT 5 OPEN

@garyttierney As far as I am aware no one is working on this, so go ahead :) I would personally do this but I have been absolutely bogged down with job and other projects recently, so I barely have time to even review PRs 😓

As for GameNetworkingSockets-rs: I think you are right, having it be standalone would be definitely nicer, but also more work. I am not opposed to it, but added maintenance is definitely an issue at my current time budget. Getting a working Steamworks version out would be a good way to go at start, I think it should cover a good number of use cases.

from steamworks-rs.

I don't know if anyone is still interested in that, I gave it a shot: https://github.com/hussein-aitlahcen/gns-rs

from steamworks-rs.

I'm interested in this, especially in having the open source version also be available. I looked a bit at how to write bindings for it but I'm not entirely sure where to start.

from steamworks-rs.

Hi, is anyone working on this? I'd like to pick it up if not.

Regarding supporting the open source version: GameNetworkingSockets provides APIs to select from either the library interface (open source version, no SDR, steam identity, STUN) or the Steamworks interface at runtime. A reasonable approach might be to have a separate GameNetworkingSockets-rs crate and have steamworks-rs re-export the interface types.

A developer could either always use the Steamworks version by using the steamworks-rs API directly, or call the GameNetworkingSockets-rs APIs to decide whether they get the Steamworks version or a core version. Code that works with ISteamNetworkingMessages, ISteamNetworkingSockets, etc. should work for both cases.

Though carrying bindings for GameNetworkingSockets as a standalone library is a separate maintenance burden, which I don't want to assume steamworks-rs is happy to take on. A Steamworks only version might be a better first approach.

from steamworks-rs.

I'm currently looking into wrapping the GameNetworkingSockets API for consumption in rust. I'm attempting to leverage the steamworks-rs code as much as possible, but I'm having a bit of trouble with some slight architecture differences between the SteamWorks SDK and GNS, especially related to callabcks.

Looking at the stemworks-rs code, it seems you are using the SDK's ManualDispatch callback mode. I don't think anything comparable exists in the GNS library. To be honesty, I'm still having a bit of trouble understanding how the steamworks-rs callback mechanism works (especially how function calls are mapped to spmc queue sends) so feel free to correct any misunderstandings I have there.

A small overview of my understanding of how the GNS callbacks work

GNS allows you to register callbacks globally using the ...SetGlobalCallback... family of functions or register them on a specific ListenSocket/HNetConnection/etc using the config option set function.

These callbacks are triggered under the hood by the library when calling the RunCallbacks function. These callbacks pass a Steam...Callback_t and don't take any sort of user provided void *.

My current guess at an implementation

Callback logic/data ownership is moved from Client to NetworkingSockets. At a high level, I think this makes sense here as the RunCallbacks function takes a ISteamNetworkingSockets* as it's first argument. This would take at the form of a run_callbacks method on NetworkingSockets. One thing I'm a bit unsure about here is having multiple instances of NetworkingSockets on the rust side that can all have run_callbacks called.

When calling connect_by_ip_address, create_listen_socket_ip functions, do the following

1. Create callbacks that close around a ListenSocketEvent spmc sender handle, do type conversion from Callback_t to ListenSocketEvents and send those to the event queue. Maybe there is something in this library that already handles this, but to me it seems like I would want to use libffi-rs to handle mapping raw C callbacks to rust closures. This closure wrapper object needs to be stored somewhere to keep it in scope. It seems like the ListenSocket object (maybe the inner object?) might be the best place to handle this from a logical perspective. My concern here is there is some thread safety concern or something else I don't understand that is behind having the networking_sockets_data member on the root client in steamworks-rs
2. Pass the callback registration parameters as described here.
3. Update the ListenSocket drop logic to delete these closures when the listen socket goes out of scope?

I'd appreciate any feedback you might have on this solution and how it fits into the steamworks-rs architecture. Maybe there is a cleaner way to do this using what already exists?

I have a fork of this repo here that has most of the non networking related code ripped out and a modified sys package that can build against a vendored GameNetworkingSockets library. Everything I've tried...seems to be working but I'm not 100% sure as without callbacks it's a bit difficult to accept connections in order to test anything.

from steamworks-rs.