Guidelines for designing forward compatible communication protocols?

Question

I'm working on a communication protocol between embedded devices. The protocol will definitely need new commands and fields in the future. What do I need to do to make sure I'm not painting myself into a corner?

Answer 1

This is a wide open question. Here are some random thoughts about it:

1. Leave spares.
2. Use a very basic header with a "number of bytes to follow" field.
3. If there are enumerated message types, make sure the type field can accomodate growth.
4. If you use bitflags, leave spares.
5. Possibly include a "raw data" message, which can be used to wrap any protocol future generations think up.

In summary, Leave spares.

Answer 2

If at all possible, allow a human at one end of a cable to figure out what is at the other end of the cable. Ideally, a human could hook up a dumb terminal and hit the keyboard three times (Enter Question-mark Enter), then a long, detailed message would come back describing what kind of machine it is, what is its model number, the name and phone number and web site of the organization that built it, the "official" protocol version number, and the unofficial build time:

__DATE__ ": " __TIME__

Also send the same detailed message every time the machine boots up.

If at all possible, try to design your protocol so that a human being with a dumb terminal can talk to your device. The HTTP is one such human-readable protocol, and I suspect this is one of the reasons for its popularity. Human-readable implies, among other things:

• Limit yourself to characters that a human can read and type. Avoid special control characters. Take advantage of the power of plain text.
• Always send CR+LF at the end of each packet (as mandated by many Internet protocols).
• Accept characters at any rate, from maximum-speed file upload from a PC to a non-touch-typing human slowly pecking at a keyboard.

You might also want to glance over the list of common protocols for embedded systems. Perhaps one already meets your requirements? Is there any reason to use something more difficult to decode than the standard Netstring format?