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
-- Change is inevitable, progress is not.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.