Re: Relays - feedback wanted

[Patrick Lidstone]

--- In <a
href="/group/xAP_developer/post?postID=3keDTDj7r6164r3U0e5LEXTyb5uZ1BhUw6wCbyOslDq4KXm9Kk9RlQ_hS6tkWg4PAxmn96FxgnpOs6ni3w5F2dMTp8s">xAP_developer@xxxxxxx</a>,
"Ian B" <Ian@M...> wrote:
> Hi All
>
> I really need some feedback as all the following is currently
working and
> about to go into the next stage of development which is the PC
application
> and PCB production etc.
>
> Here are the commands my relay board will respond to. I have left
out all
> the extra stuff and just included the class, schema, body and
expected reply
> if any. At the moment where none is expected I return a reply which
echoes
> the received message back with a simple status=OK or status=error
addition.
> I don't expect this to remain in its current form and I am open to
ideas as
> to what to send back under what circumstances.
>
> Having said this in testing I have seen the need to send a reply of
one sort
> or another to all messages. I validate very thoroughly and if there
is not a
> reply I have no easy way of knowing the result of the command.

Ian,
This is how I currently deal with this problem for my own
configuration messages.

1. Heartbeat from device always includes a config version number and
a config checksum.

2. Send a config message with version number+1 and new checksum in
body.

3. Device acts on config, and immediately generates a heartbeat which
includes version number + 1, new checksum and simple status indicator
(1=OK, other=device specific error code)

This avoids the need for an expensive message in response to every
new config.

The inclusion of a checksum addresses the possible race condition
where two messages are sent to the device simultaneously - successful
and unsuccessful senders will all know.

I only acknowledge config messages in this way, but the concept could
be extended to other types of message I guess. The reliability of
serial is a concern, but I would strongly discourage the widespread
adoption of ack messages in a tcp/ip environment - it's simply not
needed in most cases.

This extension to the protocol opens up a potential denial-of-service
attack if rogue config messages are thrown at the device. I don't
have an elegant solution for this yet!

Patrick