Skip to content

Conversation

@Raugharr
Copy link
Owner

This PR does the following:

  1. The isSystemPacket check never worked as the PingResolver never explicitly checked if the packet was a system packet, causing the first registered packed to be interpreted as a ping.
  2. Removes one of the Connection constructors that would partially setup the connection then finish setting up with onConnect. Instead create the Connection add listeners, then connect with connect. This also removes the onConnect method and puts it into the connect method.
  3. Add CloseConnection A packet that declares the other side is disconnecting.
  4. Moves the CallbackResolver code into the AbstractResolver so you can do callbacks on every resolver now.
  5. More comments and debug logs.


public abstract class AbstractPacket {
public interface Type {
int getType();
Copy link
Collaborator

@sandysimonton sandysimonton Dec 31, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unused imports
Is Type ever going to be needed outside AbstractPacket
Can we name the nested interface "PacketType" instead, to disambiguate from other Types
Maybe getType instead of getId?

public static PacketType fromInteger(int type) throws InvalidPacketException {
switch (type) {
case 0: return PING;
case 1: return CLOSE_CONNECTION;
default: throw new InvalidPacketException("Invalid PacketType");
Copy link
Collaborator

@sandysimonton sandysimonton Dec 31, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we want to gracefully handle this?

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you have any suggestions? Currently the hope is if someone disconnects, the other end will know either because the CloseConnectionResolver gets called and closes the connection, or the heartbeat doesn't get a response and it closes that way.

Copy link
Collaborator

@sandysimonton sandysimonton Jan 3, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So sorry I put comment on wrong line, should be line 50

throw new InvalidPacketException("Invalid PacketType");

Having this in mekwars/common might be ok... Do all modules know they have to handle the InvalidPacketException?

I guess my concern was that the InvalidPacketException is thrown and crashes the client or server because it propagates to the top of the stack

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, these methods only get called by Connection#readObject, which only gets called by Connection#read, which fizzles any packet that doesn't have a valid packet type.

Copy link
Collaborator

@sandysimonton sandysimonton left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At your discretion

@Raugharr Raugharr force-pushed the connection-upgrade branch from a22019a to 57f18f9 Compare January 4, 2026 15:58
@Raugharr Raugharr force-pushed the connection-upgrade branch from 57f18f9 to 56143ba Compare January 4, 2026 16:00
@Raugharr Raugharr merged commit c91a333 into main Jan 7, 2026
1 check passed
@Raugharr Raugharr deleted the connection-upgrade branch January 16, 2026 21:18
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.

3 participants