Monkey Netty: Server-Client communication system for JME using Netty.IO

Hello,
For my Outside Engine I built a server-client communication system using Netty.IO for JME. Upon request, I have stripped it out of the Outside Engine, and created a standalone project for it.
You can find the source here: https://github.com/tlf30/monkey-netty/tree/master
You many notice that some things are structured odd, this is because this code came from the OutsideEngine, and had a supporting system underneath it that I had to strip out. I have tested this standalone system using the test I provided in the repo, but if you find any bugs please let me know so I can correct them. By adapting this for use without the Outside Engine I had to change some of the key network logic, so there may be bugs that I did not catch.

@oxplay2 this is the netty.io implementation we were talking about over PM.

Please let me know if you have any questions, and feel free to use this in your projects.

10 Likes

Thanks, first i will need investigate it more, didnt knew UDP require so much code when using Netty.

i have many questions like why need udp salted hash(instead Netty SSL code), why own connection limits were implemented,

also Like everywhere is ObjectEncoder and ObjectDecoder - default Netty classes
but in Client, in UDP only, there is DatagramPacketObjectDecoder. I understand it had reason that i need time to investigate to understand all.

i will need decide if just use this repo and contribute or pull only some changes into what i have now.(you probably anyway use OutsideEngine one i belive)

In any case you help me a lot, thanks! :slight_smile:

1 Like

Hello @oxplay2, yes, your are absolutely correct, there were reasons behind all of those questions. Here we go:

  • The UDP code is for allowing each client to have its own UDP connection. Netty does not really have a method for doing individual connections to clients for UDP, so I pieced on together.
  • I did not use the netty connection limits because in Outside we log which connections we reject and why, and I also do not reject connections for administrators. In order to add custom rules for when we reject due to connection limits I added my own limiter logic, which had to get modified when removing it from Outside.
  • The UDP salted hash is just for a key when establishing the connection. The key is sent to the client over tcp and the client to establish the udp connection must provide the correct key. This was for the server to know which UDP connection to relate to which tcp connection. Nothing to do with SSL/encryption. It could have also been implemented as a random number, it was a hash to prevent collisions, but it is only relevant for a very short time frame.
  • For the DatagramPacketObjectDecoder it is due to how Netty UDP client works. It receives an envelope, and the default ObjectDecoder does not understand the envelope, so instead of trying to decode the object in the envelope, it tries to decode the envelop itself and crashes. Server side does not have this issue because it is using my implementation of the UDP server which just deals with normal objects like the Netty TCP server does.

Although netty supports bandwidth monitoring and limiting, along with SSL, in this repo these features are not present. They are on my issue board for things to implement in outside, but I have not gotten to them yet. From what I have read it would be easy to do.

Feel free to submit issues or pull requests. I will update this as I update the implementation in Outside, just like my PhysicsSync repo which is also a modified version of code from Outside.

EDIT: Also checkout this netty issue on the matter, I have several good links posted there for reference that I used in my design. https://github.com/netty/netty/issues/344#issuecomment-625847691

1 Like

Thanks for explain. That tell much. Sounds like perfect solution for now.
looks like we would really need follow netty github issue you provided. (it would change much and is reason of it all)

can i have one simple request?

Could you remove:
image

and add “.gitignore” like:

.idea/
.shelf/
/.gradle/
/.gradle/*
/.nb-gradle/
/.nb-gradle/*
/build/*
/build/**/
.nb-*
.class
nbproject/private/

bin/
libs/
build/
.gradle
.gradletasknamecache

or some “clever one” that will “not track” all local workspace trash :wink: (could use similar to https://github.com/jMonkeyEngine/jmonkeyengine/blob/master/.gitignore)
thanks!

2 Likes

Yes, I will add a gitignore, i forgot!

1 Like

This now has a store page (with a terrible picture): https://store.jmonkeyengine.org/929c156b-3b0e-42c7-8474-f6c58ed8a1d5

1 Like

yes, will need replace picture later, hehe.(current one is hypnotic!) Maybe i will try prepare something later.

@tlf30 i suppose we can use their logo(since it seems to be official logo https://github.com/netty/netty/issues/7850), but not sure if can use mixed one, anyway i prepared something that merge both JME and Netty logos:

hope its fine.

4 Likes

Oh, I like that! Good Job!
The store requires 1280x720, can you resize it, or should I stretch it?

moment, will provide 1280x720

1 Like

later i will push xcf(editable version - GIMP) into repo.

here is 1280x720

2 Likes

Awesome, thank you! I have submitted the changes to the store page.

1 Like

Approval of the change is delayed pending resolution of issue 9.

2 Likes