#enet #library #networking #gamedev #c++ #cpp #csharp #dotnet #managed #udp #p2p #multiplayer #client-server
|
|
5 years ago | |
|---|---|---|
| MSBuild | 5 years ago | |
| MobileToolchains | 6 years ago | |
| Source | 5 years ago | |
| .gitignore | 6 years ago | |
| BUILD-FOR-SWITCH.txt | 6 years ago | |
| CMakeLists.txt | 5 years ago | |
| COMMON-MISTAKES.md | 6 years ago | |
| DOCUMENTATION.md | 5 years ago | |
| Directory.Build.props | 6 years ago | |
| ENet-CSharp.nuspec | 5 years ago | |
| ENet-CSharp.sln | 6 years ago | |
| FUNDING.yml | 5 years ago | |
| LICENSE | 6 years ago | |
| QUICKSTART-EXAMPLES.md | 5 years ago | |
| README.md | 5 years ago |
Please consider a donation (see the Ko-Fi button above) if this project is useful to you.
This is a improved/refactored version of ENet-CSharp. Due to unfortunate circumstances between two development entities, the upstream repository was archived and is only updated when patches are applied (all development work is done in private). Since you cannot interact with archived repositories outside of code-related things, this repository acts as a workaround to those issues.
Unlike the upstream repository code of conduct where issue tickets were closed randomly for no reason, if you have a problem with ENet-CSharp, we'll be able to investigate. We also have a proper implementation of the ENET_DEBUG definition, allowing logging output to be written to enet_log.txt for further diagnosis and troubleshooting. Code cleanups and optimizations for better performance are included, and if someone files a supposedly-a-bug tickets actually get analyzed and if it's really a bug, it'll get fixed.
Don't use the upstream releases with the code in this repository. You will most likely get crashes or weird things happening.
You can use the IDE of Visual Studio to build if you like. The following will be oriented for power users and command line heroes.
Unlike upstream, this repo has a complete build system that harnesses the power of MSBuild.
build-essential and cmake package installed. On Debian and Ubuntu-based distros, you can do sudo apt -y build-essential cmake to install the required things.dotnet build.Protip: You can append -c Release or -c Debug to your dotnet build command to build a release binary or a debug binary of ENET's C library.
You will see an anime babe appear followed by Ignorance ASCII art.
CMake will fire up, configure itself after inspecting your build environment and hopefully spit out a binary blob inside a Unity/Plugins directory. On Windows, this will be a DLL, on Mac it will be a .bundle file and on Linux it will be a shared object (.so). This can be used with Unity or another thing like a C# NET Core application or even other C/C++ apps.
dotnet test will run some sanity checks and make sure ENET initializes, data is received and sent correctly, etc.Inside the directory that you cloned the repo to, run:
dotnet cleandotnet buildIt is recommended to clean the repository work space before building.
ENet.Library.Initialize(); function. It will return false on failure, return true on success. You can use this to gracefully quit your application should it fail to initialize, for example.ENet.Library.Deinitialize(); function.A good idea is to check out the common mistakes during integration documentation.
Looking for example code and gotta go fast? No problem, got you covered here.
Usage is almost the same as in the .NET environment, except that the console functions must be replaced with functions provided by Unity. If the Host.Service() will be called in a game loop, then make sure that the timeout parameter set to 0 which means non-blocking. Also, make sure Unity runs in the background by enabling the Run in Background player setting.
The best-known strategy is to use ENet in an independent I/O thread. This can be achieved by using Threads and enqueuing packets to be sent and received back and forth via ConcurrentQueues (this is what Ignorance uses). In fact, some internal testing showed that ENet had very impressive performance using a thread and ConcurrentQueues approach to network I/O, even faster than RingBuffers/Disruptors. Use whatever queue system you feel comfortable with, just make sure you empty the queues as fast as possible in your applications.
Threading in Unity was problematic but later versions (2018.3+) have proven to be fine. Please beware that using Threads inside a Unity environment can be problematic and can lead to the Unity Editor or built games randomly crashing without any warning. Use them with caution!
In general, ENet is not thread-safe, but some of its functions can be used safely if the user is careful enough:
Packet structure and its functions are safe until a packet is only moving across threads by value and a custom memory allocator is not used.
Peer.ID as soon as a pointer to a peer was obtained from the native side, the ID will be cached in Peer structure for further actions with objects that assigned to that ID. Peer structure can be moved across threads by value, but its functions are not thread-safe because data in memory may change by the servicing functions in another thread.
Library.Time utilizes atomic primitives internally for managing local monotonic time.
See DOCUMENTATION.md here.
Some thanks to:
Psst... If you want to know what started this repository, go read my blog post as it'll detail the whole show. It's a good read.