Binary Serialization vs. Byte Streams
 

Remeber back in C++ when to send a packet from one end point to another you create some structure for your packet headers and data, casted it into a bytstream sent it and then interpreted it again on the opposite end based on the header data?

Well I am about to tackle the task of creating a TCP Server/Client application only this time in C#. The good news is that the TcpClient and TcpListener classes take a lot of the monotonous base work out of creating a stable setup (and managing the sockets); however it leaves me wondering about sending the data from one point to another.

I will be dealing exclusively with binary data, no text. So again I will have to create a series of classes/structure which represent the various message that will be going across the wire; however having worked in the past with Xml and Binary Serialization to save data to disk, I am wondering if this would be a good approach to serializing the messages I am going to be sending across the network?

It does seem to be much easier than fiddling with the InterOp capabilities of my structures and specifying the memory layout so that I can produce a reliable byte stream, but I want to make sure that I am not sacrificing huge amounts of efficiency by using Binary Serialization. If binary serialization works anything like XML serialization extra data will be added into the bytestream to describe the values, this would produce overhead, though I am not sure how much yet.

Any insight?

You know I think the solution to this was a little bit easier then I originally anticipated...

When the packet goes across the stream it has to be a byte stream, this is the only way the NetworkStream will send or receive data.

I don't need to use InterOp to produce these byte streams, and I don't require the use of the Binary Serialization system, instead I can instantiate a basic low-level class with the byte stream which will read the first few bytes to determine the type of message that has been received.

This low level class can than either cast into a higher level class which represents specifically that message, and the properties of the object can simply read the byte stream to generate the proper values for that object.

Using binary serialization would be inefficient here because when it serializes or deserializes it will need to create copies of the byte stream.

The only thing that sucks is that I will need to either stick to fixed length messages, or write code for certain messages which will properly determine the byte stream length, which means I also need to do bounds checking.