Re: [Project] Kbd/LCD device

[patrickl@xxxxxxx]

>
> If we reach a concensus today I might start to put together some of
the
> network code tonight and post to the group as soon as so we can
start to
> iron out bugs and make sure it does as requested.

Some stakes in the ground:

1. All interactions should be stateless (no dependency between one
message and the next). That is, there should be no concept of
a "session" or similar (*). This simplifies the coding of both
the
client and the server portions, makes error recovery much simpler,
and will result in a more resilient device (failed commands can be
resent with no adverse effects; no state machine errors to creep in).

(*) This is achievable if spontaneous status indications are sent
{broadmulti}cast, but not if spontaneous status requests have to be
sent point-to-point to a number of pre-registered listeners.
If point-to-point comms is a requirement then there needs to be a
discovery process which is initiated everytime a device powers up or
watchdogs. Also, what happens when a device has no more storage to
register a listener? Some kind of lease mechanism will be needed to
keep the listener address cache clean. This is enough to put me off
the use of point-to-point for status indication in favour of
{broadmulti}cast.

2. All commands which generate a response (request-reply
interactions) should allow the sender to append an opaque field to
the message which is simply copied into the reply verbatim. This
simplifies code on the originator side because they no longer have to
preserve state related to the request; it can be bundled with the
request.

3. Do we need an application level checksum to verify the integrity
of each command? This would prevent the use of a simple telnet
session to interact with a device (unless it was optional/could be
turned off). Should mis-formatted commands simply be ignored or
generate an error response? The former allows for the transparent
upgrade of a command set, but can be frustrating for debugging
purposes. Should successful commands return a positive response (so
you know the device is there), or should you just assume the command
worked? We probably need both.

4. Maximum length of a command should be one unfragmented UDP packet.
For simplicity, one packet per command. Don't allow multiple commands
to be concatenated in a single packet.

5. Devices should heartbeat to the network on a periodic basis to
indidcate they are alive. This is essential if the system is to
support intelligent failover/fault tolerance in the long term.

6. How do we configure a device? An unconfigured device needs a user
friendly way of discovering it's IP address, and retrieving a set of
operating parameters. Related to (*).

7. It should be possible to soft start and cold start a device over
the wire (for situations where the device needs resetting but is
inaccessible). We probably also want to be able to "core dump"
over
the wire.

Patrick




Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/