Is there a correct pattern when designing network layer to easily allow upgrades/backwards compatibility?

Im currenty writing a network layer of an iPhone app and accompanying server. The iPhone app operates in both a host mode and guest mode, and also communicates with a server, for relaying messages over 3G between devices. Both are written in C#, and im using sockets. Id like to stick with binary comms, for speed and efficency reasons.

Is there a correct design approach to designing the network layer, specificall开发者_如何学运维y the packets that will be transferred between server and client?

Should I create a base class as my first version, which allows basic operation of the system, then inherit from that for future versions and changes, serializing this?

I understand XML is an option, but I did some tests and XML serialization on an iPhone is orders of magnitude slower than binary serialization, and ultimately, parts of the network layer NEED to be binary, as im sending files between devices.

My app will need to be backward and forward compatible with different versions. I dont expect to have large changes in future to the functionality, but probably some form of new features.

Ive read this question: Backwards compatibility in .NET with BinaryFormatter

The last answer seems to be the best option, using a "manual" deserialization and serialization approach. Im just wondering is this the only option.

---

Sorry your question is too vague. You need to do some reading and come back with some clearer questions.

It does sound like you are intending to use C#, which won't work on an iOS device. So you are going to have to write seperate code for the device and server. Given that, the structure of your network packets (XML or binary) is not going to matter that much because they will be handled differently on the two systems.

Working in XML or JSON would be recommended by most poeple I think, simply because they have wide support and are much easier to work with that some custom binary format. Whether they are slower than a binary form will depend alot on your data. And the age old question that we always ask first - is the difference noticable enough to warrant the extra effort. In most cases, probably not. people tend to over-emphasis the necessity for speed sometimes, not realising that unless you have a lot of data to transmit, your network connection, not your packet format, will be the limiting factor.

So the way I'd probably appraoch each end of the equation (server C#, and iPhone Objectice C) would be to create a seperate class for managing the communications and one or more classes for handling the serialising/deserialising. This gives you the flexibility to swap out technologies as and if you need to.