I only recent heard of Lidgren but never seen it personally, linky? and I believe it was removed from the MonoGame package circa. 3.2?
You see, you are using a umm... what's the saying... cannot think right now but a bit of a mix of puddles, and complicating things... the idea of good code is using as few libraries as possible as you introduce precisely what you said...
... generating garbage along the way
Don't get me started on my opinion of Steam
Though your solution works, it relies heavily on two external factors...
1 - LidGren? Lidgren? continuing to function as future code changes occur across C#.NET/Core etc... and your project remains actively updated or you become reliant on LidGren for future projects and it suddenly stops functioning...
A solution to this is you create an interface in your code that can communicate with any networking system regardless of what language it uses, though this introduces a potential lag among other things, it allows you to plug and play any networking system at any time... I am considering this approach for the code...
2 - Steam, they could pull the project at any time and believe me it will happen, or it morphs and legacy code no longer functions, this leaves your project dead in the [Pun intended] water... [Get it? Steam = vaporised Water ]
Quoting your very words:
And I think you're even free to use the Steamworks.net libraries when you host the server yourself (I think I read that somewhere).
Another factor I like to avoid is cumbersome paperwork, [Albeit digitally] can delay the packaging phase of your project as you work through the legal factors of your game before publishing, and you SHOULD be doing this to cover your legal standing... I mean, ARE YOU using that SteamWorks.NET library legally? would you want to risk them shutting you down for a simple reason that you did not spend the 30-120 minutes to read through the paperwork?
I have studied Game Production... hence the stern point
Like I said, there will be several variations, and like any code, especially modular ones, there are design schemes that will work and enable the code to be modular and functional... if you broke the system down into core components and the following is not a complete overview... you would have components that did this:
-/ Establish network communication with outside world and create incoming listening connections
-/ Listen for new connections
-/ Receive connection and add it to a lobby
-/ cross communicate data to connected members
-/ Authenticate members [optional login scenario]
-/ Create a connection to a predefined server
-/ Send packets containing data
-/ Receive packets from server
-/ Process received packets
OK right that was not what I wanted to write... hang on...
Communicate [Send/Receive packets]
Umm I better go eat...
What I am trying to say is, there are components that can be added or removed without affecting the core functionality of the networking API code... like you will always need to establish a connection with a server, but not always require sending a message for chat functionality for example, or not always require sending a voice stream for voice chat... and the communications section can have parts that accept data from various components that can safely be ignored if they are not included...
The process will ideally be organic, such that, we can begin with a core engine that establishes a connection between a server which I plan to host in an ASP.NET application, or optionally someone can convert it into a console application... but the ASP.NET implementation can give an admin panel for use anywhere and as such I can create a server administrator app to go with it... thus even beginners can get some shared hosting somewhere to get a basic server system going while testing or even run their own on a local network using IIS...
And moving past the core functionality we can add things like the messaging routing system, lobby, auto matching, etc. as the requirements appear... and as the code will both be available to all, be usable by all, be maintainable by all and not rely on any central service as you can host it anywhere, it can essentially never die... thus giving any project you create [Say if it was P2P based] a project that has 10+ years to itself... this gripe comes from me because of what EA did with the Battlefield line of things, private servers that you have to rent, what ever happened to P2P gaming
So yeah, I like to think this will work, I know full well how much will be involved in this... If there is interest in such a project I will be willing to put in the effort of creating it, moderating it and contributing to it, otherwise I just end up making the whole thing in-house and beginners are left with no simple Networking API...
Put it this way, I am one of those beginners... but seeing as there is no Physics system readily available to use with MonoGame and no Networking either... the only solution is to make it... [I am not as versed in coding as some and moving to another system when I am happy with MonoGame is not an option for me]
Heck it could become a component of the MonoGame package, which would be doubly cool!
And yes I did just hint at doing the same for Physics... the idea of simply using a command like AddRigidPhysics(Object) or something should be a reality not a dream!
I really wish Microsoft would give more focus on C#...
Dang it, I waffled...
Is LidGren Open Source? found it I think, https://github.com/lidgren/lidgren-network-gen3 but it appears on google code as well... confusing... what does the name stand for anyway?