|
DROS Message Format
Maintained by: David Austin
|
For communication, a standard is required which both parties know. In
the context of a software system with components that must communicate
with each other, this means that, at the lowest level, there must be a
standard for the bytes that are actually transmitted. This document
outlines the template of the messages (in terms of bytes) and also
describes how messages should be managed.
Note: you do not have to use GeneralComms: it is possible to
communicate with any process within DROS using whatever communications
library you wish, so long as you obey this message formatting
protocol.
The management of message formats over time is a crucial issue. DROS
will exist for a period of years, meaning that we must think carefully
about how new message formats are created, how they can be changed and
finally, how obsolete message formats can be deleted. Thinking about
this subject, I've decided on the following rules:
- New message formats can be created as and when required.
[The number of possible formats is large and can be made larger.]
- Existing message formats cannot be altered. [If you
change a message format that has been released, you will break someone
else's system. Instead, create a new message and mark the old one as
obsolete and begin phasing it out (over a fairly long period!).]
- Obsolete message formats can be deleted after a period of not
being used in the DROS code base. [I'd suggest 6 months. When a
message is obsolete, note this and the date in
GlobalHeaders/DROSMessages.h. ]
Each message starts with a header, as follows.
| Stx | MessageType | Length |
Encoding | Checksum | Id |
| 2 bytes | 4 bytes | 4 bytes |
1 byte | 1 byte | 4 bytes |
Note that every message should be replied to (I believe) and that the
Id field from the original message should be copied to the response.
A good idea would be for the Id to be a sequence number so that the
client can have a lot of outstanding requests.
The message formats are listed here. However, for up to date
information, check the file
GlobalHeaders/DROSMessages.h.
General Messages
Invalid
This message is here just in case we ever need one.
This message has no data (aside from the header).
ConnectionlessPacket
This message is not used.
Ack
Acknowledge a transmission with a status.
| Header | status |
| 16 bytes | 4 bytes |
GenString
Send a string.
| Header | string |
| 16 bytes | variable number of bytes |
|
Copyright 2001 David Austin
|