">Online RPG: An online RPG game that uses NitroNet as the backend for all of the networking and database portions.

Thanks for pointing out your library.

Could you go into a little more detail about how it compares to other common open source networking libraries?

* RakNet

* boost::asio

* ZeroMQ

* ENet

Most of those libraries have been used for larger projects than the ones you're currently suggesting, so choosing a new library has to be done for some significant and obvious benefit. What would you say your benefit is? How did you achieve/implement that benefit, compared to the others?

Thanks for pointing out your library.

Could you go into a little more detail about how it compares to other common open source networking libraries?

* RakNet

* boost::asio

* ZeroMQ

* ENet

Most of those libraries have been used for larger projects than the ones you're currently suggesting, so choosing a new library has to be done for some significant and obvious benefit. What would you say your benefit is? How did you achieve/implement that benefit, compared to the others?

All good points and there are definitely benefits that each library presents. I will address each of the libraries you said separately.

Raknet

This library is very advanced and does have features that NitroNet doesn't have, but on the flip-side my library has features that Raknet doesn't have. To start with Raknet only supports C++ and C# applications which can be a draw back for developers that are trying to develop games on different platforms. NitroNet is a Java library and allows communication from any other languages that can send bytes over a stream. With mobile games quickly become popular NitroNet is there for Java Android developers that want their apps to communicate to an external server. Raknet does support communication with C++ Android app developers though. Raknet also seems to come with a lobby system although this is nothing but an extension onto NitroNet itself and would be rather easy to extend using the database support.

Boost::asio

This library is a very low level library and does not implement many features into it. It is more open for developers to extend and build on top of it. It's biggest 'pro' is that it is a synchronized library so communication will stay constant among all connected clients. This library is more for those that want to stay low-level and have a good understanding of sockets and C++. NitroNet is the complete opposite as it is a high-level library and is easy to import into the project and get started with. NitroNet is aimed at the developers that don't care how the networking works in the background but only that it works and it works efficiently. On top of that NitroNet also implements the different features I have listed in the main post that Boost::asio does not.

ZeroMQ

This library also is a very low level library but seems to have a large community for it's development. Obviously that is not something NitroNet can compete with given that it is just starting out. The points that I would point out are the same as the ones in Boost::asio. It is another asynchronous library that requires most features to be added by the developer.

Enet

This library is very different from the others as it truly only supports UDP protocol with their own features built on top to add in some features that TCP offers like sequencing. It also has the same packet streaming, what it refers to as "fragmentation and reassembly". It does, however, require most other features to be built on top. The largest drawback of this library is that it can only be used on Windows and Unix-like platforms which is a huge drawback today when networked applications are running on mobile devices and other platforms.

So those are the comparisons between those libraries and NitroNet. The biggest thing with NitroNet is that it is high-level. It is designed so that any standard developer can include the library in their project and get communications started in a small amount of time. I actually designed this library to out-do the Kryonet library which is a widely-used library for Java applications but one that does not offer all of the features and efficiency that NitroNet does. I hope this helps!

Can I use it with C++? Would be awesome.

The IEncryptor is flawed, it provides no way to report when the bytes have been altered (and, no, the CRC32 checksum actually doesn't suffice). There are also no presets or recommended implementations for the IEncryptor, besides the example video where you add 1 to each byte. I don't know how the average user would feel but I would not feel comfortable using this library when it provides such broken functionality and calls it a "feature". Also, unless I misread, it seems that you are spawning one thread per TCP connection? (in TcpAcceptThread.java), this isn't particularly scalable, compared to the more modern completion port (or asynchronous sockets, or whatever) mechanisms; is there any reason you don't go with that approach?

You still haven't explained what makes NitroNet special compared to the other well-known libraries cited by hplus, you just paraphrased 4 times that NitroNet was "high level" and has extra features without explaining why said features are helpful to the user, you should elaborate a bit. Also, I am pretty sure ENet runs on at least Android and iPhone, so "the largest drawback of this library is that it can only be used on Windows and Unix-like platforms which is a huge drawback today when networked applications are running on mobile devices and other platforms" is a pretty strange statement - you do know that the only modern operating systems left today are basically Windows and Unix-like platforms, right?

I was going to ask about how the encryption worked but it seems bacterius has answered that for me. Am I right to assume that as of yet there is no proper encryption library such as gnutls implemented on top of your library?

Networking is sort of "my bag", so if you ever want a contributor as it's open source, let me know and if I have any free time I'll try to help you.

The IEncryptor is flawed, it provides no way to report when the bytes have been altered (and, no, the CRC32 checksum actually doesn't suffice). There are also no presets or recommended implementations for the IEncryptor, besides the example video where you add 1 to each byte. I don't know how the average user would feel but I would not feel comfortable using this library when it provides such broken functionality and calls it a "feature". Also, unless I misread, it seems that you are spawning one thread per TCP connection? (in TcpAcceptThread.java), this isn't particularly scalable, compared to the more modern completion port (or asynchronous sockets, or whatever) mechanisms; is there any reason you don't go with that approach?

I designed the IEncryptor interface with the idea in mind that the developer could design any encryption method they would like and implement it using this interface. I did not add any encryption libraries on top, like gnutls, but they certainly could be added. The functionality is there and it works. Im not sure what you mean when you're saying that it is a broken functionality. The IEncryptor interface will pass the bytes of each packet to you before a packet is sent so that you can do whatever you would like to the bytes. What I imagined was that people would use this interface, take the bytes, and use other encryption libraries on top of NitroNet. I left it open for the developer.

Also yes I spawn a new thread for each TCP connection and kill it when the connection leaves. When I first designed this 10 months ago I designed it using standard Java IO and I was developing this library in competition with another library called Kryonet. Kryonet is very popular when it comes to high-level Java networking libraries and is widely used, but I thought I could do some of it better and that's why I developed NitroNet. I do plan on making either an extension or build in NIO to NitroNet so that scalability is more possible.

I was going to ask about how the encryption worked but it seems bacterius has answered that for me. Am I right to assume that as of yet there is no proper encryption library such as gnutls implemented on top of your library?

Networking is sort of "my bag", so if you ever want a contributor as it's open source, let me know and if I have any free time I'll try to help you.

I just responded to Bacterius regarding the encryption. My main idea was to leave the encryption portion open to developers to implement whatever they'd like. If you would like to help out and contribute, it would be great if maybe you could build an extension onto NitroNet that provides ready-to-go encryption methods using libraries like gnutls. If you'd like to talk more you can PM me on here or add me on skype: baseball435 :)

I designed the IEncryptor interface with the idea in mind that the developer could design any encryption method they would like and implement it using this interface. I did not add any encryption libraries on top, like gnutls, but they certainly could be added. The functionality is there and it works. Im not sure what you mean when you're saying that it is a broken functionality. The IEncryptor interface will pass the bytes of each packet to you before a packet is sent so that you can do whatever you would like to the bytes. What I imagined was that people would use this interface, take the bytes, and use other encryption libraries on top of NitroNet. I left it open for the developer.

Yes, that is my point. That is not sufficient functionality, for an adversary could modify the bytes of the stream on the fly (defeating any checksum "protection" you might have in place) and you would be unable to detect the modification. Actually, you could in principle detect it inside the decrypt() method, but there is no way to report to the program that the bytes have been modified (just throwing an exception is not sufficient, who knows what might be catching it and what kind of side channel attacks can occur when doing this). Basically, encryption is hard, you can't just slap an encrypt() and a decrypt() method and expect it to be "secure". And if you wanted to leave the encryption portion open to developers, then the IEncryptor is not really a feature, since you have to implement it yourself... (which people are really bad at, hence the need for standard presets). Unless you are happy with half-assed security, of course.

In short, I would just drop that feature completely and let the user implement the encryption layer directly on top of the networking library (along with, say, compression, as needed). Since the user needs to implement that layer himself anyway, there is no benefit to using your restrictive and frankly dangerous IEncryptor interface instead of just directly layering it on top of the read() and write() methods of the UDP/TCP classes.

I designed the IEncryptor interface with the idea in mind that the developer could design any encryption method they would like and implement it using this interface. I did not add any encryption libraries on top, like gnutls, but they certainly could be added. The functionality is there and it works. Im not sure what you mean when you're saying that it is a broken functionality. The IEncryptor interface will pass the bytes of each packet to you before a packet is sent so that you can do whatever you would like to the bytes. What I imagined was that people would use this interface, take the bytes, and use other encryption libraries on top of NitroNet. I left it open for the developer.

Yes, that is my point. That is not sufficient functionality, for an adversary could modify the bytes of the stream on the fly (defeating any checksum "protection" you might have in place) and you would be unable to detect the modification.

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.