Java-Gaming.org Hi !
Featured games (91)
games approved by the League of Dukes
Games in Showcase (800)
Games in Android Showcase (237)
games submitted by our members
Games in WIP (867)
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 45308 times)
0 Members and 1 Guest are viewing this topic.
Offline Baseball435
« Reply #30 - Posted 2015-09-11 00:18:03 »

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

Go ahead and try that then come back to me lol  Wink Your keyword there is that it should. I can tell you, from experience, that sending an amount of bytes that large will throw exceptions.
Online CopyableCougar4
« Reply #31 - Posted 2015-09-11 00:50:37 »

I guess a better question is why are you sending 414k bytes to the client?

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

Github: http://github.com/CopyableCougar4
Offline KudoDEV

JGO Ninja


Medals: 79
Exp: 6 years


Game Dev Hobbyist


« Reply #32 - Posted 2015-09-11 03:16:16 »

Ideally when the writebuffer is full it flushes and continues. And eventually the entire message should send.

It's the receiving ends job to determine whether the entire packet has arrived. Then to start decoding.

Packet size doesn't matter. Unless of course its excessively absurd.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline theagentd
« Reply #33 - Posted 2015-09-11 03:26:14 »

That's completely irrelevant. How big packets TCP is allowed to use does not determine how much data you can send. In addition, you're most definitely adding some kind of data to the packet to keep track of this which means overhead. You should at least allow for it to be disabled.

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.
No, it isn't. If your 20 hour effort takes 1 hour to break through and adds CPU and network overhead, it's DRM. You're making your users pay for a futile attempt at stopping hackers.

Myomyomyo.
Offline Baseball435
« Reply #34 - Posted 2015-09-11 03:30:11 »

I guess a better question is why are you sending 414k bytes to the client?

If for example you need to send a file over to a client to download?

Quote from: KudoDEV link=topic=36131.msg348166#msg348166
It's the receiving ends job to determine whether the entire packet has arrived. Then to start decoding.

EXACTLY! That's exactly what my system does.
Offline theagentd
« Reply #35 - Posted 2015-09-11 03:32:55 »

You can edit your posts so you don't have to triple post.

Myomyomyo.
Offline Baseball435
« Reply #36 - Posted 2015-09-11 03:35:50 »

That's completely irrelevant. How big packets TCP is allowed to use does not determine how much data you can send. In addition, you're most definitely adding some kind of data to the packet to keep track of this which means overhead. You should at least allow for it to be disabled.

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.
No, it isn't. If your 20 hour effort takes 1 hour to break through and adds CPU and network overhead, it's DRM. You're making your users pay for a futile attempt at stopping hackers.


Of course it doesn't determine how much data you can send!!! That is exactly what my complex object to system is demonstrating! It splits a packet into pieces and shows that you can send more than the limit! It doesn't split the data everytime you send it. It's optional through a separate method.

And really? 10 extra bytes to a packet is "so much overhead"? Seriously? Dont be ridiculous.
Offline theagentd
« Reply #37 - Posted 2015-09-11 06:33:51 »

Of course it doesn't determine how much data you can send!!! That is exactly what my complex object to system is demonstrating! It splits a packet into pieces and shows that you can send more than the limit! It doesn't split the data everytime you send it. It's optional through a separate method.
Again, there is no need to do this for TCP. You just write to the stream and the TCP implementation takes care of splitting it up into packets. You only need to do manual splitting with UDP.

And really? 10 extra bytes to a packet is "so much overhead"? Seriously? Dont be ridiculous.
It is significant. For 1 hour of playing with 60 packets/sec, that's 4 MBs (2 up and 2 down) of wasted data. On a server hosting 16 players with 60 packets/sec, that's 68 MBs. Do I want to pay for an additional 1 658 MBs per 24 hours I host my server? That's a significant cost for the dedicated server you pay for. Not to mention that a lot of people have download and upload caps. When you consider the fact that most game update packets are very small, those 10 bytes could be 10-50% of the payload in each packet. Don't go and double my bandwidth usage, 'kay?

Myomyomyo.
Offline Baseball435
« Reply #38 - Posted 2015-09-11 13:09:24 »

If that's seriously an issue than I'll add in a configuration to either enable or disable the corruption handling. That way it can be the developers decision whether to use it or not.
Offline KaiHH

JGO Kernel


Medals: 783



« Reply #39 - Posted 2015-09-11 19:27:50 »

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.
That sounds fascinating. How is that different from the common approach to achieve message integrity and confidentiality by using asymmetric encription algorithms with digital certificates?
In my opinion, if one really needs to ensure message integrity and wants to check the authenticity of the communication peers, a good solution is to use for example SSL/TLS with digital certificates for applications that require such high security.
That's one of the reasons I was using the Netty framework in my last project. It provides all that (security and framing algorithms) in a fine configurable and pipeline'able way.
There is also a really nice plug-and-play-designed class javax.net.ssl.SSLEngine in the JRE that is exactly suited for this kind of task in custom frameworks.
However, I doubt that message integrity is really a prime concern with the applications you might target with your framework, which are likely games, since in order to really protect you from man-in-the-middle attacks you need some way to securely transfer information (key, token, ...) between both peers (such as with a public key infrastructure). Everything else is guaranteed to be broken by someone with enough dedication.

...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.
True. That's the reason why every encryption algorithm is open and standardized, adhering to the Kerckhoffs's principle by not making the algorithm a secret (since every algorithm can be broken), but relying on some secret data element (token/key).

In the end every security solution needs to weight effort to realize/enforce it versus effort and risk to break it, and also take into account the impact of the application performance when encoding/decoding/encrypting/decrypting.

A simple checksum solution would probably suffice and be fast enough for a simple game not worth putting much effort in breaking it, because the gain for the attacker might be too low. However, more sophisticated solutions, up to using TLS with digital certificates, would be suitable to protect applications that require it, however with the risk of adding a bit of latency to the communication.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Riven
Administrator

« JGO Overlord »


Medals: 1371
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #40 - Posted 2015-09-12 11:30:55 »

The myths in this thread are trivial to debunk.
1  
2  
3  
4  
5  
6  
Socket s = new Socket(...);
OutputStream os = s.getOutputStream();
os.write(new byte[414 * 1024]);
os.flush();
os.close();
s.close();

No exception is thrown, all data is sent, there is no need to split your data into tcp-packets by yourself, the TCP layer does that for you.


As for checksums: this is (hopefully!) not about information integrity, but about data integrity. Even with TLS your (generated?) private key is on the client's machine, so it's all hackable. What actually happens IRL however, is that the IP-packet checksum is merely checking the packet header, not the payload. Adding a checksum to the payload is ensuring that the data that the client sent (however malicious) is verifiable by the server as what the client intended to send. CRC32 is enough for this, as we're checking for TCP payload-corruption, not an attack of any sort.

Data integrity, information integrity (signatures) and information secrecy (encryption) are entirely different topics. That SSL/TLS incorporates them all does not imply SSL/TLS is the right tool if one merely needs integrity. If you need information integrity, as to prevent a man-in-the-middle from altering your data, there is no need to add encryption to the mix. You can cryptographically sign raw data just fine and send it over the wire. There is just this pesky problem of which public keys you deem trustworthy to verify the signatures. In the end it's about trusting a session, not a party and especially not a packet.

Anyway, the amount of misinformation on which this library was built, does not bode well for its potential users.

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

« JGO Overlord »


Medals: 1371
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #41 - Posted 2015-09-12 12:36:53 »

I decided to peek at the sourcecode, starting with Server.java, when I stumbled onto this:

https://github.com/baseball435/NitroNet/blob/master/src/com/jmr/wrapper/server/Server.java#L65

1  
2  
3  
4  
5  
6  
      try {
         tcpSocket = new ServerSocket(tcpPort, 1, InetAddress.getByName("0.0.0.0"));
      } catch (IOException e) {
         e.printStackTrace();
         throw new NNCantStartServer();
      }


A ServerSocket with a
backlog
of 1. I have never seen this before and hopefully never will again, as it's a sure way to bounce/drop incoming connections. By default the backlog is 50, I have had busy servers where I had to bump it to 200. A value of one would have gotten me pulled off the project instantly.



Not to meantion line 4 and 5 force log-verbosity, while hiding information (the true cause of the IOException) from the application, which is exactly the opposite of what one would want in a serious application.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings!
Offline Baseball435
« Reply #42 - Posted 2015-09-13 07:11:15 »

I decided to peek at the sourcecode, starting with Server.java, when I stumbled onto this:

https://github.com/baseball435/NitroNet/blob/master/src/com/jmr/wrapper/server/Server.java#L65

1  
2  
3  
4  
5  
6  
      try {
         tcpSocket = new ServerSocket(tcpPort, 1, InetAddress.getByName("0.0.0.0"));
      } catch (IOException e) {
         e.printStackTrace();
         throw new NNCantStartServer();
      }


A ServerSocket with a
backlog
of 1. I have never seen this before and hopefully never will again, as it's a sure way to bounce/drop incoming connections. By default the backlog is 50, I have had busy servers where I had to bump it to 200. A value of one would have gotten me pulled off the project instantly.



Not to meantion line 4 and 5 force log-verbosity, while hiding information (the true cause of the IOException) from the application, which is exactly the opposite of what one would want in a serious application.

This was obviously a simple mistake, with the backlog, and has been changed to be configurable in the configuration settings. I post my source openly to let others look at the code and point out things like this. So thank you. And my IO exception catch is printed out with a new error thrown after so that you would know the problem.
Online CopyableCougar4
« Reply #43 - Posted 2015-09-13 07:23:33 »

But that new error doesn't keep track of what actually caused the error, just that the server can't start.

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

Github: http://github.com/CopyableCougar4
Offline Baseball435
« Reply #44 - Posted 2015-09-13 15:48:50 »

The myths in this thread are trivial to debunk.
1  
2  
3  
4  
5  
6  
Socket s = new Socket(...);
OutputStream os = s.getOutputStream();
os.write(new byte[414 * 1024]);
os.flush();
os.close();
s.close();

No exception is thrown, all data is sent, there is no need to split your data into tcp-packets by yourself, the TCP layer does that for you.


As for checksums: this is (hopefully!) not about information integrity, but about data integrity. Even with TLS your (generated?) private key is on the client's machine, so it's all hackable. What actually happens IRL however, is that the IP-packet checksum is merely checking the packet header, not the payload. Adding a checksum to the payload is ensuring that the data that the client sent (however malicious) is verifiable by the server as what the client intended to send. CRC32 is enough for this, as we're checking for TCP payload-corruption, not an attack of any sort.

Data integrity, information integrity (signatures) and information secrecy (encryption) are entirely different topics. That SSL/TLS incorporates them all does not imply SSL/TLS is the right tool if one merely needs integrity. If you need information integrity, as to prevent a man-in-the-middle from altering your data, there is no need to add encryption to the mix. You can cryptographically sign raw data just fine and send it over the wire. There is just this pesky problem of which public keys you deem trustworthy to verify the signatures. In the end it's about trusting a session, not a party and especially not a packet.

Anyway, the amount of misinformation on which this library was built, does not bode well for its potential users.

Yes it is completely about data integrity and I am indeed using CRC32. It has no function in preventing attacks. I currently don't have SSL implemented but I am going to try to work on an implementation for it.
Offline Falkreon

Junior Newbie





« Reply #45 - Posted 2015-10-02 01:19:54 »

There are so many things wrong with this I can't just ignore it. Run away from this library. Run really fast, and don't look back.

  • TCP in java is stream-oriented. All underlying primitives such as packets are transparently hidden by the OutputStream and InputStream interfaces. The OpenJDK implementation of this system is open-source, publically available, massively popular, and as a result, well peer-reviewed. It can be reasonably assumed to be error-free. Attempting to do additional disassembly and reassembly over the TCP streaming layer is ignorant and error-prone.
  • IEncryptor is useless. The existing OutputStream and InputStream primitives already have a transformation layer available. Just wrap your InputStream in your preferred subclass of FilterOutputStream, or more specifically a CipherOutputStream if it's encryption you're looking for.
  • While the easy part (creating a CipherOutputStream) is treated as if it were hard, the hard part (actually encrypting the data) is treated as if it were easy, offering no user-friendly primitives for dealing with keys or certificates where Java often drops the ball. Instead the tutorials casually suggest a ROT1 cipher, which is essentially plaintext.
  • Many other places in the code reflect a very basic ignorance of very common java functions. For instance, ComplexObject.java line 118-124 illustrates to me that the author does not know of the existence of System::arraycopy
  • Given these casual mistakes and ignorant design decisions, the likelihood for actual knowledgeable peer review is quite low, except in posts like this advising not to use the library. As such the code quality is also not likely to improve in the forseeable future.
Pages: 1 [2]
  ignore  |  Print  
 
 

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

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

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

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

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

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

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

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

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

nelsongames (4555 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!