Java-Gaming.org Hi !
Featured games (91)
games approved by the League of Dukes
Games in Showcase (808)
Games in Android Showcase (239)
games submitted by our members
Games in WIP (872)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2
  ignore  |  Print  
  NitroNet - New, High-Level Networking Library  (Read 46320 times)
0 Members and 1 Guest are viewing this topic.
Offline Baseball435
« Posted 2015-05-17 02:02:07 »

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!
Offline GNecro1
« Reply #1 - Posted 2015-05-17 10:35:59 »

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

Java freak! Cheesy
Offline Baseball435
« Reply #2 - Posted 2015-05-17 16:03:56 »

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.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline yourjavaisbroken

Junior Newbie


Exp: 1 month or less



« Reply #3 - Posted 2015-05-21 17:23:40 »

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!
Offline Zeldar
« Reply #4 - Posted 2015-05-22 15:47:46 »

That looks cool, i don't know if it will be enough for a fast paced action game but it seems worth the try  Smiley
Offline theagentd
« Reply #5 - Posted 2015-05-22 16:46:32 »

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

Myomyomyo.
Offline mucaho

Senior Newbie





« Reply #6 - Posted 2015-05-23 21:19:29 »

When it comes to performance, how does this compare to Kryonet and other solutions? Does it support multithreading?
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?
Offline Riven
Administrator

« JGO Overlord »


Medals: 1371
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #7 - Posted 2015-05-23 22:52:16 »

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.

</nay-sayer>

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings!
Offline Eobard Aviles

Junior Newbie


Exp: 2 years



« Reply #8 - Posted 2015-05-25 11:18:32 »

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.
Offline theagentd
« Reply #9 - Posted 2015-05-25 11:25:14 »

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.
A multiplayer game with 8-16 players could easily be implemented with threads without any disadvantage.

Myomyomyo.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Online princec

« JGO Spiffy Duke »


Medals: 1146
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #10 - Posted 2015-05-25 11:54:44 »

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

Cas Smiley

Offline Riven
Administrator

« JGO Overlord »


Medals: 1371
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #11 - Posted 2015-05-25 12:01:28 »

... 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:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
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.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings!
Online princec

« JGO Spiffy Duke »


Medals: 1146
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #12 - Posted 2015-05-25 12:16:07 »

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

Cas Smiley

Offline Riven
Administrator

« JGO Overlord »


Medals: 1371
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #13 - Posted 2015-05-25 12:31:53 »

I'm way too busy to turn my semi-rant-style into proper educational material. Pointing

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings!
Online princec

« JGO Spiffy Duke »


Medals: 1146
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #14 - Posted 2015-05-25 19:49:34 »

"Riven - the Collected Rants"

Cas Smiley

Offline BurntPizza

« JGO Bitwise Duke »


Medals: 486
Exp: 7 years



« Reply #15 - Posted 2015-05-25 19:55:52 »

I'd buy that. Hell I'd review it on amazon.
Offline hwinwuzhere
« Reply #16 - Posted 2015-05-25 19:57:04 »

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

10/10 would totally recommend.

There are two kinds of people in this world: Those who can extrapolate from incomplete data,
Offline Mads

JGO Ninja


Medals: 26
Projects: 3
Exp: 10 years


One for all!


« Reply #17 - Posted 2015-05-25 20:16:26 »

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.

Offline Opiop
« Reply #18 - Posted 2015-05-25 21:02:58 »

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.
Offline Zanetski

Junior Newbie





« Reply #19 - Posted 2015-05-31 03:08:15 »

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.
Offline Opiop
« Reply #20 - Posted 2015-05-31 18:01:53 »

Kryonet has a lot of great examples out there, and then they have tests with source code included that you can look at. It took me half a day to understand Kryonet, you just have to work a little at it.
Offline KudoDEV

JGO Ninja


Medals: 79
Exp: 6 years


Game Dev Hobbyist


« Reply #21 - Posted 2015-07-14 23:21:47 »

Is this still alive?

I was wondering why you decided to use newCachedThreadPool(), instead of a fixed size pool.

I haven't looked through all of the code but this would make it easy for someone to cripple your server by sending too many requests?

Offline Baseball435
« Reply #22 - Posted 2015-09-10 19:16:36 »

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.

I'm not sure what you're talking about. The server can send a packet to any individual connection. It doesn't broadcast them. Are you talking about a client specifically sending to another client without the server having to do anything special?
Offline Baseball435
« Reply #23 - Posted 2015-09-10 19:29:50 »

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.

Yes I developed it with Kryonet in mind, I did like the way that they 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 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. These are just two of the features that set apart NitroNet from Kryonet.
Offline theagentd
« Reply #24 - Posted 2015-09-10 23:40:43 »

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.
This is only true for UDP. TCP has no concept of packets or a maximum size.

Another big issue I had was 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.
I really don't think this is needed. I doubt anyone will modify your packets in a way that it remains compatible with the receiver's expectations (won't crash the packet parser) UNLESS the person is intentionally trying to inject its own data into the stream, in which case whatever pesky checksum you have in there will probably be figured out and defeated in minutes by someone dedicated enough to try to do something like that in the first place.

Myomyomyo.
Offline Baseball435
« Reply #25 - Posted 2015-09-10 23:48:03 »

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.
This is only true for UDP. TCP has no concept of packets or a maximum size.

Another big issue I had was 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.
I really don't think this is needed. I doubt anyone will modify your packets in a way that it remains compatible with the receiver's expectations (won't crash the packet parser) UNLESS the person is intentionally trying to inject its own data into the stream, in which case whatever pesky checksum you have in there will probably be figured out and defeated in minutes by someone dedicated enough to try to do something like that in the first place.
TCP definitely has a concept of maximum size... persecutioncomplex

And even if they do find out the corruption method it still will slow them down. Add encryption to it and it will slow them down more. What you are saying is a little ridiculous. Almost anything can be hacked into. Saying that someone will defeat it and therefore will be pointless is absurd. If people followed this they would just leave their systems open without any protection.
Offline CopyableCougar4
« Reply #26 - Posted 2015-09-11 00:06:33 »

I think the point he was trying to make is that your system is rudimentary enough to be defeated quickly enough to render the effort useless, not that data shouldn't be protected.

Either wandering the forum or programming. Most likely the latter Smiley

Github: http://github.com/CopyableCougar4
Offline CopyableCougar4
« Reply #27 - Posted 2015-09-11 00:11:20 »

Also, IIRC TCP is handled as a stream of data, so there isn't really a max packet size.

Either wandering the forum or programming. Most likely the latter Smiley

Github: http://github.com/CopyableCougar4
Offline Baseball435
« Reply #28 - Posted 2015-09-11 00:14:50 »

Also, IIRC TCP is handled as a stream of data, so there isn't really a max packet size.

I think the point he was trying to make is that your system is rudimentary enough to be defeated quickly enough to render the effort useless, not that data shouldn't be protected.

I believe it's still better to have some system in rather than nothing at all. It's a sense of even the slightest amount of security if that's how you see it.

And if you want to send a file that is 414k bytes over TCP, how would you do it? You cant just send it over a socket because it will throw an exception. You would need to split it up and that's what my complex objects system does.
Offline CopyableCougar4
« Reply #29 - Posted 2015-09-11 00:15:53 »

TCP should do that for you. You should just be able to write to the socket output stream.

Either wandering the forum or programming. Most likely the latter Smiley

Github: http://github.com/CopyableCougar4
Pages: [1] 2
  ignore  |  Print  
 
 

 
Riven (846 views)
2019-09-04 15:33:17

hadezbladez (5789 views)
2018-11-16 13:46:03

hadezbladez (2602 views)
2018-11-16 13:41:33

hadezbladez (6205 views)
2018-11-16 13:35:35

hadezbladez (1498 views)
2018-11-16 13:32:03

EgonOlsen (4733 views)
2018-06-10 19:43:48

EgonOlsen (5791 views)
2018-06-10 19:43:44

EgonOlsen (3275 views)
2018-06-10 19:43:20

DesertCoockie (4174 views)
2018-05-13 18:23:11

nelsongames (5500 views)
2018-04-24 18:15:36
A NON-ideal modular configuration for Eclipse with JavaFX
by philfrei
2019-12-19 19:35:12

Java Gaming Resources
by philfrei
2019-05-14 16:15:13

Deployment and Packaging
by philfrei
2019-05-08 15:15:36

Deployment and Packaging
by philfrei
2019-05-08 15:13:34

Deployment and Packaging
by philfrei
2019-02-17 20:25:53

Deployment and Packaging
by mudlee
2018-08-22 18:09:50

Java Gaming Resources
by gouessej
2018-08-22 08:19:41

Deployment and Packaging
by gouessej
2018-08-22 08:04:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!