GameNetworkingSocketsDotNet.LowLevel 1.0.0

GameNetworkingSocketsDotNet.LowLevel

Low level .NET 7 bindings for Valve networking library found at: https://github.com/ValveSoftware/GameNetworkingSockets.

Available as a Nuget package at: https://www.nuget.org/packages/GameNetworkingSocketsDotNet.LowLevel/

The only class in this library: ValveNativeLibrary contains bindings to Constants, Enums, Functions but also to Structs mapped 1-to-1 to the native ones. So they can be passed along and accessed via pointers without any marshalling. (for simple value types at least)

This wrapper only dependencies are the .NET framework and the valve C++ library. It provides a very raw access to the native library.

For a higher-level solution, you can use my other project found at: https://github.com/Azengar/GameNetworkingSocketsDotNet/tree/main/GameNetworkingSocketsDotNet/GameNetworkingSocketsDotNet.HighLevel.

Building the native library

The native library binaries can be obtained either through an official release find on the official GitHub repo or by building it yourself. I recommend building it yourself in case you need one of the improvements listed just below.

Improvements to the native library

On top of these bindings, I also offer some small and targeted changes to the native library, for performances and/or special uses cases. Read more about this in the main README of the project, found at: https://github.com/Azengar/GameNetworkingSocketsDotNet.

All these improvements were made as separate commits in the dotnet-improvement branch of my own fork of the native library, I try to keep it up-to-date with master: https://github.com/Azengar/GameNetworkingSockets/tree/dotnet-extension.

I list these improvements right below.

Using different interfaces

When using the valve library it might be desirable to use different interfaces.

This might happen if you have separate clients or servers running in a single application that have nothing in common and you want to process them separately.

Doing so is possible from native code but no C binding-friendly function has been made to fit that use-case.

In the .NET ValveNativeLibrary class you might notice the function:

public static partial ISteamNetworkingSockets* GameNetworkingSockets_Create(SteamNetworkingIdentity* pIdentity, sbyte* errMesg);

This function allows you to do what is mentioned above but in order for it to work, the counterpart should be added to the native C++ library.

This requires a small addition to Valve's sources.

In steamnetworkingsockets.h:

STEAMNETWORKINGSOCKETS_INTERFACE ISteamNetworkingSockets *GameNetworkingSockets_Create( const SteamNetworkingIdentity *pIdentity, SteamNetworkingErrMsg &errMsg);

In steamnetworkingsockets.cpp:

STEAMNETWORKINGSOCKETS_INTERFACE ISteamNetworkingSockets *GameNetworkingSockets_Create( const SteamNetworkingIdentity *pIdentity, SteamNetworkingErrMsg &errMsg)
{
	CSteamNetworkingSockets *pSteamNetworkingSockets = new CSteamNetworkingSockets( ( CSteamNetworkingUtils *)SteamNetworkingUtils() );
	if ( !pSteamNetworkingSockets->BInitGameNetworkingSockets( pIdentity, errMsg ) )
	{
		pSteamNetworkingSockets->Destroy();
		return nullptr;
	}

	return pSteamNetworkingSockets;
}

Custom memory management

If you need fine-grained control over how the message buffers are allocated / de-allocated in the native library (for example in order to recycle buffers with pools) then you can do so with:

public static partial void SteamAPI_ISteamNetworkingUtils_SetCustomMessageDataMemoryManagement(ISteamNetworkingUtils* self, void* fnAllocator, void* fnDeallocator);

The native library gives you the option to do that with ougoing messages but not for incoming messages, so this change bridges this gap.

All messages created with the cbAllocateBuffer parameter will then be allocated with the functions passed in the above call:

public static partial SteamNetworkingMessage_t* SteamAPI_ISteamNetworkingUtils_AllocateMessage(ISteamNetworkingUtils* self, int cbAllocateBuffer);

For this function to work, you will need to implement the changes in the commit Allows custom memory allocation functions for message data.

However, from what I noticed with benchmarks, it is actually faster let the system allocate and deallocate memory rather than using pools, unless you work in a single-threaded environment.