[NTLUG:Discuss] What is the best method to communicate between a device and a server?
Stephen Davidson
gorky at freenet.carleton.ca
Fri Apr 4 09:22:54 CDT 2008
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Kipton.
What's wrong with an HTTP Get/Post for the communications? Most devices
have some kind of browser type idea built in, and even if they don't,
lots of libraries are available. Then, on the server, something like
'Jetty' (very powerful Servlet Container/WebServer), with a Servlet
updating the DB on incoming requests. If needed, can even be configured
to do authentication, etc.
Advantages:
- - HTTP is a well known an understood protocol.
- - 'Basic' Jetty is nice and simple. You would only need a few lines of
code for your software, container (Jetty) would take care of the rest.
- - Servlets are a standard tech, so talent and assistance is readily
available. And your use case sounds like its almost 'Hello World'
complexity.
- - Many devices have http clients, as well as JVMs or a variant (Java --
which also has an http protocols built in, and browsers/http clients are
freely and readily available - I like the ones from Apache group).
- - Much local talent to ask if you run into Java Questions
(http://javamug.org)
- - Fairly scalable (you would need more 'sophistication' if you were
going to start exceeding a couple of hundred thousand devices to
support) -- this should handle several thousand w/o breaking a sweat.
~From what you are saying, I suspect the limiting factor would actually
be server bandwidth, not DB or server capability.
Support and simplicity example:
I could probably give you most of the info you needed (at a minimum,
where all you needed to look) for the server side over a coffee. Might
need a second coffee for the client side.
Disadvantage:
You might need to spend a couple of hours learning how to set up a Jetty
Server and deploy your application in it.
Disclaimer -- I often do something similar for a living.
- -Steve
http://j2eeguys.com
Kipton Moravec wrote:
| I am designing a device or appliance (it does not matter what) that
| needs to report results to a server, over the Internet and get new
| instructions once a day or whenever it powers up. (Or had a power
| failure). There could be thousands of these devices.
|
| I have to assume the device will be behind a firewall so the device will
| have to contact the Linux server and the server will not be able to
| initiate the communications to the device.
|
| The device will send a progress report each day, reporting a few
| statistics (probably 100 - 200 bytes). The only other time it will
| report is when things go wrong.
|
| When it checks in, it will look for any new commands for itself,
| including software updates. A command may be to provide additional data,
| or a recommendation to check in at a specific time (for load balancing
| on the server). It may be required to download a new program revision,
| and reprogram itself.
|
| I do need to keep track of time, so I am thinking of implementing NTP
| also. It will have its own clock that is good to a couple of seconds per
| month.
|
| What application protocols are best for something like this?
|
| I can see using FTP to upload and download files with the data.
|
| I can see using SMTP and a POP server (email) for sending and receiving
| messages.
|
| Some have suggested SNMP which I am not familiar with.
|
| Another way is to open a socket to socket custom connection.
|
| Someone suggested opening up a secure telnet connection.
|
| I am sure there are more ways to do this. But what I do not know is what
| is the best way to do this. I want something that is robust, and easy.
| (KISS) And preferably small.
|
| It is hard to predict what will be required in the future so flexibility
| is good for both sides, the device and the server.
|
| Any suggestions? And more importantly why one way would be better than
| another?
|
| Kip
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iD8DBQFH9jm+SphIUSiVzgYRAqqDAKDs1NBMf47Hv2O3B3u5goCOcUSTMACfYkQK
aCnHzI/YP4/rA/ZxJWWhJDQ=
=Sozv
-----END PGP SIGNATURE-----
More information about the Discuss
mailing list