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.
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?
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?
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.
This is only true for UDP. TCP has no concept of packets or a maximum size.
[quote=“Baseball435,post:24,topic:54493”]
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.
[quote=“theagentd,post:25,topic:54493”]
This is only true for UDP. TCP has no concept of packets or a maximum size.
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.
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.
Also, IIRC TCP is handled as a stream of data, so there isn’t really a max packet size.
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.
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 
Your keyword there is that it should. I can tell you, from experience, that sending an amount of bytes that large will throw exceptions.
I guess a better question is why are you sending 414k bytes to the client?
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.
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.
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.
If for example you need to send a file over to a client to download?
EXACTLY! That’s exactly what my system does.
You can edit your posts so you don’t have to triple post.
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.
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.
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?
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.
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.
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.