NitroNet - New, High-Level Networking Library

Networking & Multiplayer
#1

NitroNet

[*]NitroNet is a library is used to simplify networking applications and decrease development time. It is multiplatform, supports UDP, TCP and HTTP, offers the ability to encrypt packets, includes packet corruption handling, packet streaming, SQL support, and much more. This library will allow you to quickly, easily, and efficiently develop networking applications.

Why Use NitroNet?

[]Networking is a very interesting part of programming but can be very confusing to setup and hard to understand. NitroNet simplifies the process of networking by allowing you to communicate between clients and servers through TCP and UDP with minimal effort.
[]Why not use other libraries like Kryonet you may ask? Kryonet has some issues with it and can be somewhat confusing to catch onto. It also does not offer many of the features that NitroNet has like packet corruption handling, encryption/decryption (to an extent), and packet streaming.
[*]I developed NitroNet with the idea in mind to simplify networking as much as possible for the user, but at the same time make it a very secure, efficient, and reliable library. The features it offers outdo features of other libraries and allow you to quickly and easily develop, what would typically be, complicated networking applications.

Features

[]TCP and UDP: Easily send packets of information over any 2 of the protocols by using only one method.
[]Multiplatform: Use this application on any device that supports Java and communicate with the server from other languages like C#.
[]Complex Objects A.K.A. Packet Streaming: Send large objects over TCP or UDP by splitting them into smaller portions and recreating them on the receiving side. This is all done in the background of NitroNet and easily allows you to send large objects with only one method.
[]Encryption and Decryption: Encrypt and decrypt the raw bytes of the packets to protect from hackers.
[]Packet Corruption Handling: Prevents packets that are edited by a 3rd party software from being processed. Hackers are able to modify packets being sent over a network, but NitroNet stops this from happening and doesn’t allow edited packets to be processed.
[]SQL Support: Offers an interface, IDatabase, to be implemented and used to communicate with SQL databases. NitroNet comes with an implementation of the JDBC connection in the JDBCDatabase class.

Open-Source

[*]NitroNet is completely open-source and welcomes new additions and recommendations for the library. If a bug is found you can easily submit it and myself and other developers will work on fixing it. You can view the source code on the Github page. As time goes on a plan to add new extensions to the library and also optimize it to make it as fast as possible.

Why Is This Better Than Kryonet?

[]I actually developed NitroNet with Kryonet in mind, I did like the way that it handled connections, disconnections, and received packets. What I didn’t like was their serialization system and I also believed that I could add other features that would benefit many applications.
[]As you may know, a packet over 65535 bytes can’t be sent through TCP or UDP and this can be a huge headache for the developers that need to be able to send packets larger than that. That is where my complex object system comes in. It will take a packet it, split it up into smaller pieces, send it to the other side, and finally reform the object. This is all done with a single message which works seamlessly with the listening system.
[*]Another big issue I had was the corruption of packets. Say that a third party edited the bytes of a packet as it was being sent over. Using Kryonet you may not ever know that it happened. I implemented a corruption handling system that will test packets before they are sent through the listening system. If it is corrupted then it wont pass it through.

Getting Started

[*]The Github page contains both text and video tutorials that teach you how to get started and use NitroNet. Getting started is very simple and I recommend watching the video tutorials to get a good idea of how NitroNet works and how easy it is to use.

Working Examples

[]Online RPG: An online RPG game that uses NitroNet as the backend for all of the networking and database portions.
[]Do you have a project you’d like to have up here as an example? Feel free to message me on here and I will put it up as an example!

#2

I quite like it. It is similar to kryonet but simpler, good for beginners!

#3

Yes there were some things that I didnt like about Kryonet but other things that I did so I designed it based off of some of the architecture of Kryonet, specifically with listeners, and then built new features from there.

#4

Looks promising!
I will be following this one!

GNetLib is a whole different audience, but I say this can be given to beginners as-is!

#5

That looks cool, i don’t know if it will be enough for a fast paced action game but it seems worth the try :slight_smile:

#6

When it comes to performance, how does this compare to Kryonet and other solutions? Does it support multithreading?

#7

Yeah how much overhead do these additional features incur (e.g. average additional bytes per UDP packet)?
How stable is the library - would you call it production ready since it’s been used in two applications already?

#8

Looking at it from a totally different perspective, I’m mainly concerned about baked in SQL support. It seems absurdly out of place. There hasn’t ever been a use case for this, nor will there ever be. Server-applications have no issue accessing an SQL server, and client-applications should never ever talk to a database directly, no matter how precisely user-privileges are configured. It leaves me a tad mystified as to why, and to me it poorly reflects on the library as a whole, as in Layman’s terms: it makes no sense!

It’s like a smartphone with advertised support for playing a specific YouTube video. I wouldn’t buy it, as it makes me wonder about the process that has led to this.

#9

Why do people use thread per connection? Iv been told a million times, it’s not recommended unless you’re doing some sort of Chat program.

#10

A multiplayer game with 8-16 players could easily be implemented with threads without any disadvantage.

#11

I’d say you could comfortably handle a couple of hundred clients with normal threads nowadays.

Cas :slight_smile:

#12

… and the advantage would be blocking behaviour, for both reads and writes.

The code complexity increases quickly, even for trivial cases, like prefixing a length to a payload.

With a blocking API, it would be along the lines of:


public void writePacket(byte[] payload, OutputStream out) {
   if(payload.length >= 64*1024)
      throw new IllegalArgumentException("payload too big");
   dos = new DataOutputStream(out);
   dos.writeUnsignedShort(payload.length);
   dos.write(payload);
}

public byte[] readPacket(InputStream in) {
   dis = new DataInputStream(in);
   int len = dis.readUnsignedShort();
   byte[] payload = new byte[len];
   dis.readFully(payload);
   return payload;
}

With a non-blocking API, you’d be looking at state machines, keeping track of various things, including whether you’ve read too few or even too many bytes, timeouts, etc. With blocking IO you can just shove a BufferedInputStream/BufferedOutputStream in the middle to minimize jumping into kernel-space too often. Reproducing that behaviour with NIO will mean writing a few hundred lines of code, that will be horribly broken, if written by a novice. When using non-blocking IO as a novice, you pretty much have to resort to network libraries that do the heavy lifting for you, even for the most trivial case like the one described above.

As long as many JGO members get confused by terms as buffer.flip(), buffer.rewind(), buffer.clear(), NIO would be way beyond their capabilities, at that point in time.

#13

You know, I think a wiki page about networking with a Java flavour would be a welcome topic.

Cas :slight_smile:

#14

I’m way too busy to turn my semi-rant-style into proper educational material. :point:

#15

“Riven - the Collected Rants”

Cas :slight_smile:

#16

I’d buy that. Hell I’d review it on amazon.

#17

10/10 would totally recommend.

#18

This looks remarkably similar to Kryonet, with the listeners and serialization-based packets. How is this different? How is this better? I’m currently using Kryonet in my application, and I’m very happy with it. Therefore, I am very curious about what issues it has, prompting me to change to NitroNet.

I’m also very curious about what kind of performance can be expected from NitroNet.

#19

From what I see on your Github page, you don’t support the ability to send packets to a specific client. Are there any plans to add such a feature? That missing feature (IMO) cripples the library. I agree with Mads, Kryonet has been my choice for networking for a while now and I don’t see a reason to switch.

#20

I hope this one has better documentation than Kryonet for newbies like me. Just an open source example of a good way to structure server/client would go a long way.