Im sorry, I dont understand how exactly it would defeat the checksum protection by allowing them to modify the bytes. The checksum will always try to be received regardless of whether or not someone modifies the bytes.

CRC32 is not a cryptographic checksum. It's very easy to modify the bytes in such a way that the modified bytes have the same checksum as the original (for instance https://github.com/theonlypwner/crc32) and it's even easier if one can modify the checksum itself since it's being sent over the wire as well. That's because CRC32 is a cyclic redundancy check, intended as protection against accidental errors such as line noise. It's useless against an opponent (a "hacker"). That's only one vulnerability.

No offense, but I would say it's not very responsible of you towards your users to advertise encryption features if you yourself don't understand what makes a network protocol (in)secure...

Also yes I spawn a new thread for each TCP connection and kill it when the connection leaves.

This is a big draw-back of any networking library. For 8 players, it's probably OK. For a server with hundreds, or thousands, of active players, it's a big no-no. I'd hope that every modern networking library would use evented I/O and worker threads, rather than thread-per-socket. (Look at the nio library in Java, for example.)

Im sorry, I dont understand how exactly it would defeat the checksum protection by allowing them to modify the bytes. The checksum will always try to be received regardless of whether or not someone modifies the bytes.

If your protocol doesn't address client and server authentication (using private/public keys,) message digest authentication (using a cryptographic message digest and negotiated key,) initialization vector management (which may add payload the the underlying stream,) and session key negotiation (which probably should use Diffie-Hellman or similar,) then you're probably better off just not mentioning encryption.

Also, any C/C++ library can be ported and run on any environment (iOS, Android, Windows, MacOS X, Unix, Blackberry, Symbian, Bada, Xbox, Playstation, Wii, ...) The same cannot be said for Java; there exists platforms where no good Java runtime environment exists for user-defined code. It's also pretty easy to wrap a C/C++ library in JNI and call it from Java. The reverse cannot be said.

So, again, thank you for giving a reference to your library. I probably won't include it among the "recommended set," though, given the weaknesses suggested above, given that the other options are significantly more robust and implemented in a context of more experience of real networking challenges.

It's also pretty easy to wrap a C/C++ library in JNI and call it from Java.

It is?

Back-end servers developed in Java are very popular nowadays because of their stability and scalability. Sure C/C++ can be used but Java is certainly an easier language to pick up and begin developing with. Im sure most can say that to be true. Im taking all of the criticism's into account and they're not going to stop me from continuing development on NitroNet. Ill take them all into consideration and build off of them to improve it. I am going to focus on Java's NIO library and either build an extension onto NitroNet or completely rewrite the networking portions to improve speed and be able to handle more connections like stated.

It is?

I think so. JNI's pretty reasonable, as far as interoperability goes. Not as nice as P/Invoke, or the Haskell FFI, but better than Lua or Python or such.

they're not going to stop me from continuing development on NitroNet

I hope I didn't sound like I suggested that you should! We learn by doing, measuring, and repeating.
Glad to see you're finding value in this project.

All of the statements here are completly valid and I would like to encourage you working on it further.

You opened your code now to the public and those are the responses you get and you should work with.

Everyone of those guys here and the developers of other libraries have developed projects in their free time and learned from it and maybe built onto this.

The question "what makes your library special" is a very good question you should ask yourself, because it is the target you want your project to be heading at.

However you answered already why your engine is better then Kryonet, it doesn't need to be better then every other engine.

I think the use of Java is a very important approach as Servers very often use Java technology including but not limited to the possibility that the VM can crash safely without damaging the server itself and it is a by far easier language to work with then with C++, also it is THE language for Android.

C# is just Java again but one year in the past, so yeah thats about it.

While you can bind C++ code easily with JNI (and there are also many IDE plugins doing that automatically for you) there are still many problems i.e. using casting and stuff which do not translate great between C++ and Java.

So the "language" you are using is indeed interesting for Java-Developers.

I am right now using Java because of development on Android and C++ turned out in the past to be a huge pain in the... on this platform as there are like a bazillion different smartphone models on the market which is basically the downside of C++ making it even more complicated.

Though for encryption and decryption you might want to implement another existing (C++) library as both parts can be critical spots needing skilled developers to work on.

So I am considering working with your library. Http and Https is part of the standard Java library, I never use TCP in games especially not when multiple Threads are involved (on typical Android hardware!? Very bad idea!) and I don't think the players would benefit from any encryption in my game anyway.

That said I am here for the UDP part of your library.

Do you think games can benefit from your UDP part?

What are the benefits instead of doing it by myself? (My project right now contains no single line of networking code, just an empty thread looping, doing nothing, waiting for something to do)

And how can I implement your library into my existing project?

Then the final and most important question is: Am I allowed to use your code?

I can't find a "licence" or "conditions of use", maybe I am overseeing something but... can't find anything.