This is a follow on post to my previous one about "Bit-level protocol or text-based protocol?" (thanks very much guys for the good replies).
Apart from defining the structure of the frame/message, I think a protocol also needs to define things like sequencing and timing, ack/nak, error handling etc.
Any suggestions on how to approach this? What need to be defined and how? Any examples?
Thanks
Very broadly speaking, there are often two categories of comms: - "are you there" - periodic polling or reporting-in to check that both ends are still there - "here's what's changed" - on a change of status, an update of the changes.
Bear in mind that with Ethernet and TCP/IP, the underlying layers are already doing some handshaking - TCP is a "guaranteed delivery" system (and UDP isn't). However I find it convenient to use belts and braces, and deal with TCP as if it were a serial stream. Thus I still tend to have an ACK/NAK system at the application level.
Somewhat in haste,
Steve
In the interest of not re-inventing the wheel, see how it's been done in a field-tested protocol. IP being a readily available and well-documented example.
Look into "TCP/IP Illustrated" by Stevens for a great text on how each of the IP sub-protocols work - their formatting, their timing, and their flow. It's "illustrated" because they have a lot of visuals for the data flows.
There's a reason it comes in 3 volumes, two of which are ~600 pages. If you're doing more than a simple atomic request/response protocol, the complexities of higher performance / reliability / interoperability start piling on.
Richard
"Design and Validation of Computer Protocols" by Holzmann is a very good book. You can buy iot from Amazon or look at it here:
Regards, -=Dave
Have something to add? Share your thoughts — no account required.
Ask the community — no account required