May we please have a C# wrapper? about gamenetworkingsockets HOT 52 CLOSED

+1 for Unity

from gamenetworkingsockets.

I've finished working on the wrapper. It's released here.

Please, keep in mind the following things:

1. Everything is translated to C# manually line-by-line, so if you have interop skills and you found some mistakes, let me know.
2. The code is written in a readable and clean form unlike the native code (sorry guys, but there's chaos 😸), an API reference is under construction. I hope I'll finish it soon.
3. The flat interface doesn't provide a function for releasing messages on the unmanaged side as I mentioned here. If @fletcherdvalve doesn't close this gap himself, I'll wrap the low-level function later.
4. The native library potentially has some problems with a burst of incoming connections and there's something wrong with payload length of internal messages. More investigation is required.

Happy networking.

from gamenetworkingsockets.

As soon as this is released in Steamworks, which it sounds like it will be in 1.43, I'll get it added to https://github.com/rlabrecque/Steamworks.NET, that should likely work nearly identically to the standalone version here with the exception of the PInvoke dll name.

from gamenetworkingsockets.

@nxrighthere Thanks for this help! I'll add a flat wrapper to release a message, and look into the deadlock thing you mentioned.

from gamenetworkingsockets.

@nxrighthere Thank you! This is amazing!

from gamenetworkingsockets.

The wrapper updated to the latest version up to c4a9773 commit. API reference is under construction.

from gamenetworkingsockets.

Yeah the Steamworks SDK has a "flattened" version where all the entry points are plain functions, not virtual methods. We should add a flat interface to make it easier to bind to other languages.

There are legit reasons for the "get a pointer to an interface" idiom. It isn't really useful in this case where you are binding directly to a specific version of the interface and statically linking, and you don't have two different potential "identities" (a "client" and "gameserver" -- that's a weird Steam thing.)

from gamenetworkingsockets.

from gamenetworkingsockets.

Disclaimer: I don't write/do a lot with c/c++.

I don't see how one could make a working C# wrapper for this library as-is. It's based around that 1 method which returns a C++ class with lots of virtual functions. I don't think you can PInvoke into
(virtual) c++ class functions. You'd have to somehow marshal the class layout, which isn't (cross compiler / platform) defined for c++.

There'd need to be an explicit C export wrapping the class functions by passing a pointer to the class and calling the desired function. Probably together with explicit constructor & destructor exports.

Though to be fair, I'd guess that's required to use this library properly in C as well.

from gamenetworkingsockets.

If anyone has made any progress on this, I'd love to hear about it :)

from gamenetworkingsockets.

@fletcherdvalve I have good news and bad news...

The good news is that the fixed flat interface seems to work fine, thank you. I've made a basic wrapper, and it works.

The bad news is that I encountered some problems with the library. I've tried to perform stress test without sending any messages:

As you can see here, only 70 simulated clients was successfully connected. I've captured 30,000 packets on loopback and here's what I got:

I can send you everything you need for further investigation.

from gamenetworkingsockets.

I've tagged an official v1.1 release, if you want to pin it to that.

from gamenetworkingsockets.

I never worked with Unity. But my understanding is that Unity has pretty similar transport layer under the hood (that is already integrated with their ECS etc). Just out of curiosity - what is wrong with Unity's system that make you people want to use Valve's sockets lib?

I'm also assuming this will require a lot of extra work to integrate it with Unity's entities and not just C# bindings.

from gamenetworkingsockets.

@igore34 Unitys low level networking is closed source and they're veeery slow to fix broken things. Even a memory leak that was reported a few months back is still waiting to get fixed.

from gamenetworkingsockets.

While C# bindings would be nice generally (not everyone using C# is using Unity), C# already has exemplary support for C++ interoperating. It wouldn't be hard to declare extern methods for the functions of the library you need to use and DLLImport them.

from gamenetworkingsockets.

for c# put the library in an SafeNativeMethods class in an SafeNativeMethods.cs file and P/Invoke the library.

from gamenetworkingsockets.

This would be relatively simple to add through the use of SWIG-- although this project should transition to CMake first

from gamenetworkingsockets.

I wrote C# bindings for basic functions, but the funniest thing is that the library works fine in native code, and only partially in .NET application. The initialization works fine, GameNetworkingSockets_Init return true without any error, but it looks like CreateListenSocket doesn't work. Did I make a mistake somewhere? @rlabrecque

from gamenetworkingsockets.

What happens when you call CreateListenSocket? That actually looks pretty good!

from gamenetworkingsockets.

CreateListenSocket always return HSteamListenSocket = 1647690432 for the server and client. GetListenSocketInfo doesn't return pnIP and pnPort for some reason.

@tycho @fletcherdvalve Any thoughts, guys?

from gamenetworkingsockets.

I don't know anything about C# interop, sorry.

from gamenetworkingsockets.

Found the problem, your EntryPoint's are almost all wrong, copy/paste error :) So 1647690432 is just the address that SteamNetworkingSockets() is returning. Do I still use EntryPoint in Steamworks .NET? I think I got rid of it, or at least thought of getting rid of it for reasons like this, it's just unnecessary duplication which leads to problems like this.

		[DllImport(nativeLibrary, EntryPoint = "SteamNetworkingSockets", CallingConvention = CallingConvention.Cdecl)]
		public static extern HSteamListenSocket CreateListenSocket(int nSteamConnectVirtualPort, uint nIP, ushort nPort);

from gamenetworkingsockets.

How EntryPoints can be wrong if I clearly see them in the DLL?

It's obvious that the functionality is behind them because runtime throws the EntryPointNotFoundException. I've double checked everything, functions itself works fine.

from gamenetworkingsockets.

The only thing that comes to my mind is that ISteamNetworkingSockets interface should be implemented in C# bindings to execute these functions properly. Or, as an option, write the native proxy which will process everything and trigger callbacks and stuff on the managed side.

from gamenetworkingsockets.

You're just using the SteamNetworkingSockets entrypoint everywhere, except for the first two functions.

Like CreateListenSocket needs EntryPoint = "CreateListenSocket", but it currently has EntryPoint = "SteamNetworkingSockets"

from gamenetworkingsockets.

Do you understand what you are suggesting, and why it's not working for this library? This is not the Steamworks API where the all functions are globally accessible. In this library, there are only six global functions. At least, please, just take a look at the source code.

from gamenetworkingsockets.

Exactly. I think the best way to solve this issue is to make an EntryPoint for each native function. At least, this is how it's done in other libraries.

from gamenetworkingsockets.

@nxrighthere Ah yeah, I see what you mean, but my point still stands that you're merely getting the initial entry point. You could try implementing it like this: rlabrecque/Steamworks.NET@e217e9b But yeah like @pipliz said it's not going to be portable unfortunately.

Edit: @fletcherdvalve The Steamworks SDK flat API still requires the pointer to the interface, it just essentially takes it as its 'this' arg, so it works out really well. You can still pass in your interface pointer from both the client and the gameserver. \o/

from gamenetworkingsockets.

I see what you mean, but my point still stands that you're merely getting the initial entry point.

Yeah, that's true. All these functions return the same value.

You could try implementing it like this: rlabrecque/Steamworks.NET@e217e9b

Nah, I'm tired of this for now. 😆

from gamenetworkingsockets.

Nah, I'm tired of this for now. 😆

Yeah, I also wouldn't recommend it. 🙃

from gamenetworkingsockets.

Now that the flat interface has been written, anybody want to take a stab at the C# wrapper?

from gamenetworkingsockets.

Still doesn't work for me. SteamNetworkingSockets_CreateListenSocket return 2147500035, and SteamNetworkingSockets_ConnectByIPv4Address return 2.

from gamenetworkingsockets.

Callbacks are not firing, and SteamNetworkingSockets_GetListenSocketInfo return zero for both pnIP and pnPort values.

from gamenetworkingsockets.

I am trying to build a C# wrapper too, and I have met the similar problems about Callbacks. During the connection_test.cpp example, you do some work in the g_Callbacks such as AcceptConnection , change the connection state(connecting -> connected), And if I want to do the same thing on C# side, I should have to do things like:
Step_1.Implement a FSteamNetConnectionStatusChangedCallback type callback in C# side
Step_2.call SteamNetworkingSockets_RunConnectionStatusChangedCallbacks in some suitable places.

But I am not sure if it is possible to marshal a FSteamNetConnectionStatusChangedCallback type func pointer in C# side (or if someone knows how to do this please tell me!!!!!). So I guess that I have to write my self-define callback function in c++ and add interface so I can invoke the callbacks on C# side, but this work flow seems a little bit strange. I thought my callback functions should totally be written in C# but not in the libGameNetworkingSockets.dll.

Any one has some suggestions?

from gamenetworkingsockets.

Maybe one can use c++ /clr to and somehow display the types and functions of the library using that to C#. I used that before in .NET when nothing else worked for me on something I thought was simple.

from gamenetworkingsockets.

Yes, the native proxy is what I said earlier, but it's an ugly way to solve this... 😞

from gamenetworkingsockets.

@tycho Has pointed out a bunch of flaws in the first attempt at a flat interface, many of which you guys bring up here. We'll take another stab at it.

from gamenetworkingsockets.

@nxrighthere I've updated the flat interface. Could we take another look at getting this working? what problems were you seeing?

from gamenetworkingsockets.

@fletcherdvalve Sorry, I'm very busy these days and don't have time for this, unfortunately.

from gamenetworkingsockets.

Is there work being publicly done on a C# interface? Would love to possibly contribute.

from gamenetworkingsockets.

@kkukshtel DO IT! Let me know if the flat interface is missing anything.

from gamenetworkingsockets.

@fletcherdvalve Is there any documentation on how the library is intended to be used besides the test file?

from gamenetworkingsockets.

What @rikimaru0345 said :)

from gamenetworkingsockets.

With only a few clients everything works fine. I think this issue is related to the burst of incoming connections (deadlock?).

from gamenetworkingsockets.

Also, CSteamNetworkingMessage::Delete should be wrapped in the flat interface for destroying received messages via release pointer.

from gamenetworkingsockets.

I am not sure about the underlying implementation of the wrapper but why would it be deadlocking? is it run on the main thread or something? Why not use Tasks then from C#'s TaskFactory in System.Threading.Tasks.Task.Factory if it is?

from gamenetworkingsockets.

The problem not with the wrapper, problem with the native library itself.

from gamenetworkingsockets.

The native library is full of SteamDatagramTransportLock based on recursive_timed_mutex in nutshell. In almost every single function.

from gamenetworkingsockets.

oh I see.

from gamenetworkingsockets.

Work on API reference completed. Any technical or grammatical corrections are welcome.

from gamenetworkingsockets.

I added a link to @nxrighthere's project.

We don't really have expertise doing this, so I don't think this is something we would implement ourselves.

from gamenetworkingsockets.

The wrapper and API reference are updated up to 2d2001f commit.

from gamenetworkingsockets.