Only suitable for client use not Steam Game Server

[JamesMcGhee]

Your transport uses a lot of client only interface calls so wont work on a steam game server
We have created a variant that wraps these with

#if UNITY_SERVER
// server variant
#else
// client variant
#endif

That said its based on our framework not Steamworks.NET so wouldn't work in your case but wanted to raise this to you. but you are welcome to it https://www.dropbox.com/s/topkpniiqshroo7/SteamMirrorTransport.cs?dl=0

Follows is a list of the modifications we made

1. Our own wrap up of Steamworks.NET we dont use SteamManager so everywhere you see SteamManager.Initalized gets changed to SteamSettings.Initalized.
2. Our own kit handles initalization and is smart enough to know when it should initalize SteamAPI vs GameServer so we dont let things like a transport do a lot of what yours does ... thus we gutted it :)
3. Our kit supports MLAPI and a few others so the naming is a good bit different we have also made your transport self contained e.g. IClient and all that are now a child of SteamMirrorTransport
4. SteamNetworking is a client interface thus its wrapped such that on a server build it will use SteamGameServerNetworking and on a client it will use SteamNetwokring
5. Similarly SteamNetworkingUtils is a client interface, wrapped to use SteamGameServerNetworkingUtils when appropreate
6. Similarlly again SteamNetworkingSockets == client we have wrapped it to use SteamGameServerNetworkingSockets when appropreate
7. We assume you are using a modified Steamworks.NET in that NativeMethods is private and shouldn't be called directly. We haven't tested it yet but are using data.Release() which should do the same thing

Note we are aware of either a bug or at least bit of confusion around GameServer.Init with the Steamworks.NET wrapper causing issues on port bindings. So if you go to test this you may run into that you can see more on that here rlabrecque/Steamworks.NET#407

[Chykary]

Thank you, this is certainly interesting! I'll look into this once I have some more time on my hands. :)

[JamesMcGhee]

Just for note we find that when using sockets we get memmory access violations and a crash
Its something with the socket code I haven't had a chance to chase it up yet. Wondering if its to do with release on SteamNetworkingMessage_t

In our case we use data.Release();

in your case your calling
NativeMethods.SteamAPI_SteamNetworkingMessage_t_Release(ptrs);

data.Release calls that same method as such

                /// Function to used to decrement the internal reference count and, if
		/// it's zero, release the message.  You should not set this function pointer,
		/// or need to access this directly!  Use the Release() function instead!
		internal IntPtr m_pfnRelease;

                ...

                /// You MUST call this when you're done with the object,
		/// to free up memory, etc.
		public void Release() {
			NativeMethods.SteamAPI_SteamNetworkingMessage_t_Release(m_pfnRelease);
		}

Could be an issue else where but wondered if you saw the same when testing sockets or if its just us :)

[Chykary]

I have encountered crashes when using the object's Release function as described in this issue: rlabrecque/Steamworks.NET#388

When I replaced it with the native method as you quoted, it did work.

[JamesMcGhee]

This issue is resolved by the pullrest #22 which has been merged into the master branch