Just curious if you are going to venture further into the design of an actual protocol? I'm also wondering if there is a proper forum to discuss protocol design.
I'm involved in development of an application where we have built our own protocol (over TCP) from scratch. Its a binary protocol. One thing that I've had trouble with is the message header. Our header currently looks like <magic><type><len>. The magic is mainly to help track down development issues, type is the type of message and len is the total length of the message. Anything beyound the header is specific to the type. Is this sane? I've been thinking of adding an ID field to the header, so any message that requires a response would send the ID back so the application could determine what triggered that response. Anyways, I'm rambling now and look forward to more articles on protocol design.
At some point I might look in detail at a specific protocol or two and go through their design from the ground up.
Using type and length prefixing is a reasonable design. For matching up responses, using an id for messages is the common practice when responses are optional or may come back in different order than requests. Depending on your protocol structure it might be part of the message header or part of the message contents.
For example, in Banana (http://twistedmatrix.com/documents/TwistedDocs/current/specifications/banana.html -- currently undergoing rewrite but this is still pretty relevant), messages are nested lists, so a protocol built on top of it might say "first item in top-level message list is the message id".
I'll be covering these issues and more in future articles.
Previous Message
