I recommend building upon the layers of protocol provided by the underlying architecture you have chosen, for example, TCP/IP, Bluetooth, USB, etc. If the underlying communication layer provides data integrity and delivery then it should not be duplicated in the application portion of the communication protocol. At a minimum, you are looking to have a low-level handshake between subsystems with assured delivery. Consider the following questions:
- Does the packet need to be routed?
- Does the sender need to know that the recipient received the communication packet?
- Is the data intact?
Now you can move to the business logic portion of the packet--the data payload definition--and begin to address these questions:
- Is there a command/response requirement?
- What is the general packet definition?
- Are there different types of packets?
- Is the packet size variable- or fixed-length?
- What are the physical units of the data transmitted?
- Was the packet understood by the receiving subsystem?
In addition to these questions, it's imperative that you list all of the possible error conditions. Ask yourself how you will be able to make them happen so you can test for robustness, which sometimes requires writing test applications to intentionally insert error conditions. Sometimes an external communication test device is the best choice.
There are many factors to consider, and this brief writeup is simply a starting point. What issues do you think are most important in building a robust communication mechanism?
-Gary
