"Serializing" classes

[David Horn]

I have a small amount of information to transfer between devices. It's uncomplicated, consisting of a simple list of class attributes.

IE, I have a class such as Game, and another called GameList, which is simply an organised list of Game objects.

I need to transfer the GameList object between two devices (via Bluetooth). While I suppose I could faff around trying object transfer or actually serializing the object (which appears terribly complicated in .NET), I simply parse the whole lot to a string, and transmit that.

For example, a sample string might look like:

Code: Select all

1	Game One|Developer One|^Game Two|Developer Two| etc.
	1 lines; 0 keywds; 0 nums; 6 ops; 0 strs; 0 coms    Syntactic Coloring v0.4 - Dan East

This is then parsed on the receiving device and a new GamesList object created. Apart from the obvious computational overhead and the risk of a title containing one of the delimiting characters, is this a practice seriously frowned upon? Is there a simple alternative?

Cheers,

David.

[Dan East]

That's perfectly fine. There are of course simple things that can be done to greatly optimize things. Generally speaking, use binary data instead of strings whenever possible.

For example, say an object can have one of three states. Instead of sending a string "Active", "Inactive" or "Deleted", send a byte with a value of 0, 1 or 2. Both the transmission of data and logic on the receiving end will be faster.

Personally, in most cases I would use a struct for all data (except strings, so they would not be fixed length to reduce the amount of data transmitted), and send it as one chunk of data. That works nicely because there is no parsing of data. You just read it directly into your struct and access it as needed. The biggest downside of this is compatibility between different versions of your software. If you change the struct size then compatibility will be broken unless you specifically implement backwards compatibility. To that end it is wise to send the size of the struct as the first two bytes of the data chunk.

One thing you have to watch with socket programming is that sends are not cached. There is a heavy penalty for sending multiple small packets instead of one large one. I just recently obtained a massive performance gain with one my projects using TCP connectivity over LAN by implementing caching on sends. I only transmit when the cache is full, a call is made to receive data, or the FlushCache routine is explicitly called. Synchronizing your cache size so it is a multiple of the send window size also helps.

Dan East