Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WIP] Rewrite network communication #98

Draft
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

pehala
Copy link
Collaborator

@pehala pehala commented Sep 1, 2021

Overview

Current networking sucks, this PR aims to completely redesign and rewrite the entire networking component of the game.
This includes:

  • Server module
    • Almost everything will be brand new, 90% of the original classes will be deleted
  • Client module
    • We will now use Netty even on the client instead of a custom pure socket solution.
  • Shared module
    • Many of the classes will be used across both server and client so the shared module will get a lot bigger.

New network communication system

  • Currently using TCP sockets with SSL encryption and Gzip compression with binary messages.
    • Entire Java objects are being sent and received
    • This should make this really efficient in terms of traffic (not that it even mattered that much)
    • Possible to use different backends like WebSockets/HTTP/UDP without that much of a rewrite
  • Compared to old messages (or packets), current ones are much more sparse, I have managed to remove a lot of useless messages or merge them into existing ones, which helps with the responsiveness of the client (It had to wait on soo many messages).
  • Build on top of Netty 4.1

Implementation

  • PacketReceiveHandler is the main listener for all packets received. The packet is routed to the listener based on a header and each listener can specify which packet it accepts.
  • Multiple PacketReceiveHandler are grouped together into HandlerGroup, which can be used to register/deregister multiple listeners. This enables me to create logical "phases" e.g ClientInitialization, LobbySelect, Game etc. each with their own group that is registered/deregistered when the Client enters the phase.

How much is currently implemented

  • Basic network core
  • Ping keep-alive system
    • Just to check if the sockets are still live
  • Only ClientIntialization is done, meaning up to the screen with choosing Game Type (Single, Multi, Dual).
  • Disconnect is not handled properly yet.
  • Should be usable through maven:exec goal as before

Removed features

  • Reconnecting - I found out there is a reconnecting feature, but decided to not implement it yet
  • Number of player thread - apparently there was a running thread on the client which asked every few seconds for a number of players in lobbies (WTF, WHY?). The functionality of this is going to be incorporated into the network communication.

TODO

  • Finish the redesign to be at least able to play a multiplayer game.
  • Fix tests
  • Write new network tests
  • Add JavaDocs (I should really do this one)
  • Create a Sequence diagram to visualize how the network communication works and what messages does it send.

@PhilippvK If you have any questions or suggestions, feel free to comment.
Fixes #99, #70, #93, #69, #63

@PhilippvK
Copy link
Owner

I have one question, even if it is not really relevant for the current state of the implementation: Do you see a possibility to detect the usage of a client-side aimbot by using the new network protocol?

@PhilippvK
Copy link
Owner

Good work, I can not wait to try it out. More stability and responsiveness would be great.

@pehala
Copy link
Collaborator Author

pehala commented Sep 1, 2021

I have one question, even if it is not really relevant for the current state of the implementation: Do you see a possibility to detect the usage of a client-side aimbot by using the new network protocol?

I do, there is a place for that check already in the communication scheme. The harder question is how to implement it right:
A) I can do one using naive approach where client just sends bool if he has it enabled, it would not solve much as it would be really easy to edit the client to bypass this.
B) We could devise a much harder protection (e.g. client hashing the entire jar or some class and sending it for verification) but that is out of scope for this PR

@pehala pehala changed the title [WIP] Rewrite server [WIP] Rewrite network communication Sep 1, 2021
@PhilippvK
Copy link
Owner

great. Let's go for A) and maybe extend that in the future.

@PhilippvK
Copy link
Owner

@pehala Are there any updates on this? I do not want to push, just don't know if you have been waiting for my feedback since September...

@pehala
Copy link
Collaborator Author

pehala commented Mar 6, 2022

There is small progress, currently I am in process of rewriting lobbies endpoints but I do not work on this actively and it is a tedious process. I can however push the latest changes so you can check it out and review at least those :)

pehala added 2 commits March 10, 2022 07:51
- Keep old networking and code intact for now
- Upgrade to netty 4.1
- Only for Multi game
- Too many collateral changes to list here
@pehala
Copy link
Collaborator Author

pehala commented Mar 10, 2022

What now done:

  • Networking up to selecting a game, you can connect to a server & create a lobby
  • Checks for the same name, cheating and compatible versions

@PhilippvK If you want you can try it out.

If anyone else would like to help with this just let me know, there is enough work yet to be done :)

@PhilippvK
Copy link
Owner

@pehala I gave it a try and the points you have described work as expected. Good work!

@pehala pehala marked this pull request as draft August 23, 2024 05:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Desyncs while playing multiplayer
2 participants