P2P API on C# side

[unalkalkan]

Hello, first of all thanks for your efforts so far. It helped so much along the way.

I was wondering if you are planning to implement the P2P callbacks and function calls on the C# side. Especially on Signalling implementation.

[nxrighthere]

Hi, sure. Can you point me to the exact API that you would like to wrap?

[unalkalkan]

P2P implementation is in this source file: test_p2p.cpp

As far as I have looked, one of the main thing that we need to add is this "SetGlobalConfigValue" API, which is used like this:

// Hardcode STUN servers
SteamNetworkingUtils()->SetGlobalConfigValueString( k_ESteamNetworkingConfig_P2P_STUN_ServerList, "stun.l.google.com:19302" );

// Allow sharing of any kind of ICE address.
// We don't have any method of relaying (TURN) in this example, so we are essentially
// forced to disclose our public address if we want to pierce NAT.  But if we
// had relay fallback, or if we only wanted to connect on the LAN, we could restrict
// to only sharing private addresses.
SteamNetworkingUtils()->SetGlobalConfigValueInt32(k_ESteamNetworkingConfig_P2P_Transport_ICE_Enable, k_nSteamNetworkingConfig_P2P_Transport_ICE_Enable_All );

Other than this, we need these API's:

• SteamNetworkingSockets()->CreateListenSocketP2P( g_nVirtualPortLocal, 0, nullptr );
• SteamNetworkingSockets()->ConnectP2PCustomSignaling( pConnSignaling, &identityRemote, g_nVirtualPortRemote, (int)vecOpts.size(), vecOpts.data() ); (which takes ISteamNetworkingConnectionCustomSignaling as a parameter)
• SteamNetworkingSockets()->ConnectP2PCustomSignaling( pConnSignaling, &identityRemote, g_nVirtualPortRemote, (int)vecOpts.size(), vecOpts.data() );

These are the ones that I can see right away, if you want me to look more detailed I can dive deeper.

[nxrighthere]

@fletcherdvalve Fletch, in the flat interface functionality for ISteamNetworkingConnectionCustomSignaling and ITrivialSignalingClient seems missed.

Also, this signature const SteamNetworkingIPAddr & across the header is not ANSI C compatible (linkage will be failed).

[zpostfacto]

I am probably going to rework this interface soon. I'll correct the calling conventions at that time.

[zpostfacto]

I just checked in an entirely new interface, ISteamNetworkingMessages. It is the same as the Steam version, and is intended to make it easier to port UDP code.

Now would be a good time to collect a list of things that I need to fix with the flat interface or other stuff that makes the binding awkward.

After I get the flat interface in a good state with all this stuff, I'll probably make a new release.

[zpostfacto]

Pinging this again, because I'd like to make sure I am doing what is needed to support this. Are these the only two issues?

• Flat functions for the interfaces that the client code must implement. I'm not clear on this, though. When would the flat interface get used? The app code never actually calls into those interfaces -- only the C++ code. The app code is the one implementing them.

• Fix any places where the flat interface is accepting a reference.

[nxrighthere]

I'm slammed with other projects and IRL stuff at the moment, so can't check this out yet, unfortunately.

[nxrighthere]

@fletcherdvalve I've looked into this again. The first issue is that in accordance to @unalkalkan request above, ConnectP2PCustomSignaling() and ConnectP2PCustomSignaling() are both requires ISteamNetworkingConnectionSignaling as a parameter which is not exposed (it's a C++ class). I'm not sure what he is trying to achieve with that.

As for the second issue, yes, parameters like SteamNetworkingIPAddr & should be replaced with SteamNetworkingIPAddr * in the interface to enable compatibility with ANSI C.

[zpostfacto]

@nxrighthere On the first item, my library requires that the application code provide a class that implements a certain interface. It's really just a way for the app code to specify a set of callbacks and shared context in a bundle. This is really easy and convenient in C++, of course. I can make a slightly different flat interface, and some glue to do it with plain C-style callbacks. I'll hit you up when I have something and get your opinion.

Thanks for creating and maintaining this

[nxrighthere]

Thanks for creating and maintaining this

@fletcherdvalve It's an investment for bonus points for a potential job at Valve. 😸

I'll hit you up when I have something and get your opinion.

No problem! I'm not familiar with recent P2P stuff that you implemented, but it seems interesting!

[fghl]

Just passing through, but for what it's worth-

ISteamNetworkingSockets has these methods.

If you were able to implement them it would make P2P socket connections via steam relay easier.

HSteamListenSocket CreateListenSocketP2P( int nVirtualPort, int nOptions, const SteamNetworkingConfigValue_t *pOptions );
HSteamNetConnection ConnectP2P( const SteamNetworkingIdentity &identityRemote, int nVirtualPort, int nOptions, const SteamNetworkingConfigValue_t *pOptions );

[jwlondon98]

Any updates on this? I'm looking to do P2P with this. Does this C# library support P2P, and if not, what needs to be done in order to get it functioning the way GameNetworkingSockets does? Thanks.

[nxrighthere]

I need to find time to update the wrapper. I'm slammed with IRL stuff and my other projects.

[jwlondon98]

@nxrighthere this repo uses Valve's relay but does not require Steam, correct? in other words, this can be used on non-pc devices?

[nxrighthere]

Theoretically, yes.

[DoomT-DaveK]

Hi there. Sorry for resurrecting this old issue, but are there any updates related to the P2P functions being accessible in the C# library?

What would need to be done in order to support this functionality? Can you point me in the right direction to add support for this? Have other posters on here added it on their projects and willing to share the updated C# wrapper?

We are looking into using this for our networking for our game and having the P2P functionality would be great.