GladNet - Free Opensource Networking Library

GladNet​

Notice: License change, still free but under BSD.

Are you tired of Unity's built-in networking not satisfying your needs? Tired of closed source networking solutions? Tired of networking libraries limiting your concurrent connection limit or just plain charging you some sort of fee to use their product?

If you answered yes to any of that, or even no to everything, then you may want to try GladNet, a free* open-source networking library!

*Requires only attribution as defined by the license file in the repository

What is GladNet?

GladNet is the brainchild, and a current work in progress, of my limited collective experience with various networking libraries. It is not, however, a revolutionary library. It's not going to set the world on fire, do your taxes or even compete with some of the paid networking libraries such as Photon Server SDK (OnPremise).

GladNet is based on a slightly customized Lidgren gen3 library. It provides what I believe to be a user-friendly API while still being functional and customizable. Lidgren is UDP-based but has an R-UDP implementation, which is exposed by GladNet, so you don't have to worry about losing the benefit of reliable messaging if you for some reason you prefer the reliability of things such as Unity's built-in networking.

Features:

• Standalone server applications with a windows form GUI launcher/loader and manager.
• Unity standalone and webplayer support
• Higher level messaging workflow allowing you to define struct-like classes to be serialized while abstracting the slight complexity of doing so
• Server to Server connections (allowing you to scale your serverside to distribute tasks/loads to other servers for whatever reason you desire)
• An exposed API for serialization; allowing the user to define custom serializers and register them and allowing serialization to be defined on a per packet basis (although you do not have to use this feature, you can keep it simple!)
• And every feature Lidgren gen3 offers* (aside from encryption)
• An Encryption API to register custom encryption algorithms along side a user-friendly default algorithm.

*Not all Lidgren gen3 features are exposed but can be or will be in the future

Upcoming Features:

• GladNet v2 is in the design stages. It will be rewritten to be more testable, documented and feature rich. It is difficult to keep my software up to date with the highest quality of code due to the fact that I'm constantly being exposed to new a better designs. I apologize for anyone who has cringed at this code. It will be better in the future.
  
  
• Integrated Webplayer support (though this may become irrelevant with the advent of Unity's webgl platform).

Current Issues:

GladNet is not without faults. The GladNet version being released is essentially the first releasable version. Testing lacks full code coverage, edge cases may exist and etc. However, I want to put this in the hands of the community ASAP. It's free but it's not perfect.

• May not work on mobile devices. It is untested.
• Documentation is currently lacking as the project has been influx for a couple of weeks.
• Mac and Linux testing hasn't been verified.
• There is currently no internal subserver authentication.

Release Information:

Released! There may be bugs. This is the first actual usable build of the project. This is analogous to a company like EA shipping a title that finally compiled and seems to not break. So be warned.

(Now just based on a BSD license)
License information: Link

(Please star the repo; this is mentioned in the license)
Public GitHub Repo: Link

Pre-built dll's: Link

Youtube Guide Videos: Link

Intro to the basics:

New Serverlauncher GUI and loading process.
(Plus I discuss some future features of GladNet and some information about another project you guys may be interested in towards the end)

 

glad to hear other alternatives, but you got nothing yet to show/test

practically just a teaser, all links , files to be announced?

so whats the purpose of this thread. might aswell wait until you could release something instead of teasing the community and even worse with an open source library,

i could understand in a close source teasing the community before beta releases or demo testings but open source and to be announced release date? hmmmmm not cool at all.


not sure if this was a good practice

so far the 14th evening and still no signs of release.

am confused now. :-(

anyways good luck with your contribution release , hope you get all sorted out ok.

 

I apologize, I'm currently preparing a test project that I will then record in video form to demonstrate GladNet's use. I tend to get excited about things so maybe I jumped the gun. I've just published the repo to github and have created the required terms of attribution. Give me about an hour and several of those links will be filled and I'll start work on a video tutorial. Everything should be available shortly.

Edit: I meant the 14th of the 15th. This post was posted on the 14th basically.

 

sorry, i guess i over reacted, i should not judge like that, i do apologize. i was eager to test and i guess i found out it was not available at the moment :-(


i want to thank you for making this library open source, it is a great gesture of you to do such a thing.


got several questions:
when you mentioned on the features:

can you elaborate a little more on this, it sounds interesting the above mentioned phrase/feature


also on the:

does this mean it will run as a console app? and not within a unity instance?

but how about server side collision detection, will the current setup be able to handle such a task?

 

• Server to Server connections (allowing you to scale your serverside to distribute tasks/loads to other servers for whatever reason you desire)

This implies that a server application can connect to other server applications. Internally this means Lidgren connects, from the same socket it polls for client connections, to another serverside application to become a peer of that server. Simultaneously a server application could let a server become a peer. Determining what type of client is connecting, whether it be a subserver peer or just a client, is indicated by a byte code that must be unique per the entire project.

• Standalone server applications

Currently the library only hosts serverside applications in pure C# console applications. This may be extended to windows services or something better, the way servers are currently launched needs to be reworked at the moment anyway. A Unity3D serverside, while making it easy to handle physics and collision, would not be efficient for a lot of online games. In such cases of MMOs like Tera, you could not have several Unity3D instances running as servers to service the game world. It would be inefficient. Previous to Unity5 various people like @CJR Gaming have attempted to implement a physics simulation to mock Unity. You'll have to ask @CJR Gaming how well that has worked.

I think we're all hopeful that Unity5's Physx 3.3 wrapper will better support scenarios such as this. I've never written a physics simulation on the serverside before so I could not fully answer that question. It will be harder but it will certainly be more efficient.

I will work on extending the ability for a Unity3D instance to become a server if there is demand for that.

Also an update on the release time, probably another hour. There are a couple of outstanding bugs that for some reason have appeared. Several issues had to be addressed because of Unity's poor support for some features even in .Net 3.5. Hopefully very soon I'll be able to post links to everything needed.

 

I've released the links to the repo. I'll start working on an example video to highlight some basics. Let me know if anyone runs into issues compiling the project or using the prebuilt dlls.

edit: Videos are now available. There is currently a bug with stopping the network thread in Unity. I'm working on a fix for this issue as we speak.

 

I'm working on a better server loader and launcher. It's almost in a usable state but atm it'll just be in the dev branch on the github repo. This will allow you to better manage your serverside applications.

From this windows form, sorry Mac and Linux users, you'll be able to generate config files that'll pass information into the constructor of your ServerCore child class. Removing the hardcoding from there. You'll also be able to initiate shutdowns on your servers via the launcher as well as view live information, in the future, about current connections and the load your server is experiencing; for example the cpu, memory usage and bandwidth consumption and etc.

Here is a quick pic of it so far today, it's obviously not finished yet:




Edit: Good news to Linux and Mac uses. I wasn't aware Mono had an implementation of windows forms http://www.mono-project.com/docs/gui/winforms/ you may yet be able to run the launcher. I'm not sure if there is any other windows specific API involded, I'm using pipes for message transmission between the launcher and server processes. You'll have to compile that yourself though and test. Let know if it works. If it does you can make a pull request and all will be dandy =).

 

This sounds interesting, I'm currently working on a similar project, exept i'm gonna run the complete game on the server (unity's headlessmode) and let the clients only send Userinputpackages. The Server then sends the World back as Snapshots, which the clients will display (That's basically a mix from Quake and Source Networking).
Very nice project though.

 

Thank you very much, I wish you luck on your project. Are you saying you're writing a networking library or an FPS, I can't tell? If you ever need some networking external to Unity for Unity I hope this may be able to fill your needs in the future =). Sounds like it'd be a pain to write an FPS like that in Unity though, I never got around to finding a solution to rewinding simulations upon disagreement in prediction but I'm sure it's possible.

 

Here is a sneak peak about what will be joining the main github branch soon, the server loader and launcher. Discussion about the future of the launcher is included as well as GladNet as a whole which may interest you more than the introduction of this silly Windows Form application.

At the end I even hint to another project of mine which may be more useful to all of you than GladNet. I won't spoil it though =).

 

Hey!

Just a tip, the license is a complete mess. No company working on any type of commercial product is going to take a chance with something like that. If you want people to use it, use a BSD or MIT style open source license, or sell properly licensed copies of it.

One more thing, in the lidgren folder you have replaced the lidgren copyright notice with your own, basically claiming that you have copyright over lidgren. This is not how the MIT license works.

 

Oh my, you're right! When this was in its own repo I must have accidentally overwritten the license file. I'll go ahead and fix that, thanks for noticing. You must of thoroughly checked my repo lol. Thanks for not commenting on how amatuer the code is.

I'll consider switching to a more orthodox license soon. As a realist I'm doubtful more than a couple projects, commercial or not, will even read the post itself let alone pick it up and use it.

 

GladNet's master branch now contains a new version of the project just merged from the dev branch. I'll release videos in the future about the encryption features.

Updates Include:

1. New updated license. GladNet is still free under a BSD license.
2. Provides a way to establish a symmetric key to message between the server and client securely.
3. An encryption API is now exposed to the users who want to register and use their own algorithms. Inherit from EncryptionBase and follow similar logic to the DiffieHellman example and register your method on the server and client to use. I'll produce a video on this at a later date. You can use the default out of the box by initializing encryption via a public method on the client peers.
4. Fixed a major breaking bug for how clients were handling messages. They were meant to dispatch them via a queue. However, I guess at 5am one night or something when I wrote it they were being dispatched directly from a networking thread.
5. Major refactoring. Parts of the codebase are ugly but overall this is improving. There are still a handful of methods that are puke worthy though. None of this is exposed to the end use of course though. If you don't want to work with GladNet's source you will not encounter any problems.

If you have any questions let me know.

 

Some bug fixes tonight. Read about them here:
https://github.com/HelloKitty/GladNet/pull/6
https://github.com/HelloKitty/GladNet/pull/7
https://github.com/HelloKitty/GladNet/pull/8

If these are any bugs you guys have experienced I'm sorry, they should be fixed now. If you notice anything else buggy let me know. The dev branch was just merged to the master branch so you should all probably update. Some of the bugs were rather serious.

 

Merging a couple more bugfixes. If you didn't read the updated first post GladNet is eventually be rewritten to be not only more testable but to able be test friendly for people who need to mock connections for tests. There is no timeline for this but it will eventually occur. It's unlikely many, if any, API changes will result.

I've added an additional parameter to the receive methods. It now provides some additional message information that previously was unknowable. Most importantly you can check that a given message was encrypted if you expected it to be. This is critical for avoiding packet injecting from malicious parties.

Edit: A couple of more bugs have cropped up. I'll fix those. These include exceptions being thrown if you attempt to register a packet multiple times, such as when you try to connect with a GladNetPeer more than once. I think I'll just check to see if a packet is registered and return true if it already is to avoid this.

Edit: False alarm I think on the editor crash. I think it's being caused by something unrelated to GladNet.