Kryonet packet identifying

I’m looking into obfuscating the client. That means obfuscating kryonet packets aswell. This means I’ll have to implement KryoSerializable.
Now there’s one problem left, which is how to know which packets are which. I know you can assign id’s to packets. But I’m not sure if that can work when a packet is named a.class in the client and LoginRequest.class in the server. Are there work arounds? I haven’t tested it yet because I haven’t found any time to do yet.

What I want:
client -> packetID+packet.write();
server -> which packet should be known using;

Eh? ::slight_smile:

Your problem is that you (probably) have no problem.

KryoNet works with registering packets, you call Kryo.register(ClassNameHere.class) on both ends independently.

This means: It only matters in which order you register stuff, it does not matter if the class (or its methods and variables) have different names as long as they are containing the same fields in the same places.

How would KryoNet know that the classes have different names on both ends if everything that is transmitted is an ID (= order of register call) and a pile of data representing the fields.

Write your own Serializer if you want to go 100% sure that nothing fancy happens:

public class Vector3Serializer extends Serializer<Vector3>{
	public Vector3 read(Kryo kryo, Input in, Class<Vector3> vectorClass) {
		return new Vector3(in.readFloat(), in.readFloat(), in.readFloat());
	public void write(Kryo kryo, Output out, Vector3 vec) {

Then call this instead of your normal procedere:

kryo.register(ClassNameHere.class, new ClassNameHereSerializer());

And read the KryoNet readme on github, mostly everything is explained there.

Great, I tried it in the past but I would get exceptions all over the place. As I used default serializers, which means I couldn’t retrieve the correct value by field.
Going to try this soon.

I was forced to use obfuscating for a client once. So i worked on it a bit. Long story short. You don’t need it. I can still hack your client just as easily even if i just use the bytecode! I hardly need to decompile. And now it is a PITA to inspect stack traces and stuff.

But if you insist.

You need to be very careful of implied dependencies ie via reflection or otherwise. Since then things can just be left out completely. In fact i used these tools to make much smaller jars and stuff.

Obfuscating is indeed a poor, sometimes horrific solution, but:

there’s an app for that :point: You’d simply recover the original stacktrace.

Yes but it is more work, and if they are on an older version or something. It just adds hassle for little if any gain.