[Date Prev][Date
Next][Thread Prev][Thread Next][Date
Index][Thread Index]
Re: [Project] Kbd/LCD device
- To: ukha_d@xxxxxxx
- Subject: Re: [Project] Kbd/LCD device
- From: Martin Greenwood <martin@xxxxxxx>
- Date: Tue, 5 Jun 2001 10:22:36 +0100
- Delivered-to: rich@xxxxxxx
- Delivered-to: mailing list ukha_d@xxxxxxx
- Mailing-list: list ukha_d@xxxxxxx; contact
ukha_d-owner@xxxxxxx
- References: <9fi3la+sk2l@xxxxxxx>
- Reply-to: ukha_d@xxxxxxx
Just got back from two weeks holiday with no email or computers....
A lot has been happening whilst I was away, 900 emails from ukha
mostly about design of HA stuff.
I'm glad it is all on the ukha email list rather than on separate
lists otherwise I would have missed it all!!
At work we have been setting up a protocol to allow remote plugins to
our system (real-time colour image processing not HA!). We have been
looking at all the ethernet / serial, HTTP, XML, SOAP XML-RPC, SNMP
bits to evaluate best, most powerful, yet simplest method of comms.
Looking at the Kbd/LCD thread, it appears that half of you favour a
complex protocol, half want something simple. So it may be hard to
reach a consensus!!
Anyway what we went for is that each device should support a simple
connectionless socket ascii protocol over ethernet.
We used a simpler version of XML-RPC (RPC was very very verbose)
Each packet is self identifying (i.e. anyone listening can understand
it even if they did not request it) and fits in a low-level or raw
IP/UDP packet.
This way every device can cope with this, as this sort of software
decoder will fit in a few kb of code. It is XML compliant, so some of
the manufacturers we are working with have used an off the shelf XML
parser, other have just written a simple parser.
The Arp protocol is very simple and allow devices to discover their
ip addresses, assuming there is a controller.
Then in addition devices can have standard HTTP server capabilities
if required.
But remember this system does not need to be totally "industry
standard" so it does not need the complexity / excess baggage. It
just needs to be robust and simple, but without limitations.
Anyway the discussion is great and the project are very interesting.
Regards
Martin
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Home |
Main Index |
Thread Index
|