As a basic transport service…

[Anonymous]

I currently handle serialization/deserialization on my own. I have -many- subclasses, than inherit from a base datapacket class. They override the Serialize and Deserialize methods, and just use the binary reader/writer. The result is either a byte array of the serialized data, or a new object created from the serialized data.

The packet has a header of one int (message length), 1 byte (packet type), and the actual serialized data. When I deserialize these, I have a large switch based on the packet type. Something like this:

			switch (dataPacket.PacketCommandType)
			{
				case PacketCommandType.UpdateEntityPosition:

// The datapacket has already been deserialized properly
UpdateEntityPosition((UpdateEntityPositionDataPacket) dataPacket, player);
					break;

One for each packet type.

So, what I would like is a better transport mechanism, which handles the message disassembly and reassembly, and Networkcomms seems to be that. However, I’m a bit fuzzy on how it handles inheritance. From the examples, it looks like you need to do this:

[ProtoContract]
//As with the ProtoMembers we include child classes in the 
//serialisation format using the ProtoInclude attribute
//The (tag) 100 on the ProtoInclude can be anything as long as it 
//does not clash with the ProtoMember attribute tags.
[ProtoInclude(100, typeof(CustomObjectExt))]
class CustomObject
{

I really, *really* do not want to have to list each subclass in the attribute of the base class, I would find this pretty cumbersome.

Basically…I think I just need networkcomms to handle transfer of the byte data, and I handle deserialization and such. I believe that using the binarywriter and reader to explicitly handle serialization results in a message that is as efficient as possible.

`public override void Serialize(BWriter writer)
{
writer.Write(Id);
writer.Write(_Position);
writer.Write(_YRotationInBytes);
}

public override void Deserialize(BReader reader)
{
_Id = reader.ReadInt32();
_Position = reader.ReadVector3();
_YRotationInBytes = reader.ReadByte();
}`

So I guess my question would be…do you think this would be a good use of networkcomms, just letting it handle the transport? Is this even possible, given that

public T DeserialiseDataObject<T>(
byte[] receivedObjectBytes

Seems to require me to specify the subclass types?

I looked in the documentation for how to just send/receive the serialized byte data for the completed messages, and must be missing it.

Maybe if Networkcomms and Json serialize would handle serialization so much more conveniently, that it would be better to switch even though the messages are less effecient.

 

 
Thanks for your assistance!

[Anonymous]

Heya AMGuy. Welcome to our forums and thanks for your interest in NetworkComms.Net.

You can indeed handle any serialisation and deserialisation yourself, just using NetworkComms for the sending and receiving. As far as NetworkComms is concerned you are only ever sending and receiving byte[], i.e. in the case of incoming data the subclass you would specify <byte[]>.

For reference the performance of the binarywriter is OK for small classes, where the serialised size is <10KB, but becomes increasingly poor for anything larger. The default serialiser/deserialiser used by NetworkComms.Net is Protobuf which does require implicit links if used with inherited classes. You can also change the default serialiser/deserialiser to binarywriter in NetworkComms, avoiding the need to add the code yourself, please see the advanced send example in the source download bundle for an example.

If you have any more questions please feel free to post back.
Regards,
Marc

[Author]

Posts