Packet payload for a RFC message with IBinarySerializable as argument

[JosephHK]

So what is packet payload for a RFC message with a IBinarySerializable as the only argument when nothing is written into the BinaryWriter passed to the IBinarySerializable?

I did a simple test. If I am correct, it seems that an empty IBinarySerializable argument will cost unacceptable 50 bytes. Please clarify.

[JosephHK]

Oh. I knew the reason now.

The types of the arguments of a RFC message are serialized as strings. And the type of the struct implementing the IBinarySerializable interface cost 50 bytes.

It is really inefficient.
May I require an corresponding improvement please?

[ArenMook]

IBinarySerializable implies you will implement two functions for serialization, so whatever you send in the Serialize is completely up to you. If you write nothing, then it will only send the header for this class so that it knows what type it is. This header is a string of your class name. For example if your class is named "ABC" and it's inside namespace SomeProject, then the sent value is going to be "SentProject.ABC" -- 15 bytes for the data + 1 byte for string identifier + 4 bytes for string length, meaning at least 20 bytes right there.

If you want to send less bytes, either have shorter class names, or simply define your custom classes in TNSerializer. Check TNet.Serialization.GetType, TNet.Serialization.WriteObject, TNet.Serialization.ReadObject. If you implement your class there, you'll drop the header down to 1 byte.

[JosephHK]

Can you modify the TNSerailizer so that it is possible to register the type by method like TNSerailizer.RegisterBinarySerializer(Type type, byte id)?

[ArenMook]

I could, but it wouldn't make much of a difference because to add new types to the serializer you will need to recompile the stand-alone server or it won't be able to communicate with your client. So either way you will need to change code.