Exact match. Not showing close matches.
'[TECH] Best communication method for the interne'
As more and more things are controlled over the internet ; What schemes are best for connecting embedded devices to [ laptops and smart phones and tablets ] ?
I have some presumptions ==> Most connections do not require high speed data transfer. Simple messages are sufficient. Simple while extensive ID schemes are best.....
What do PIClisters suggest ?
In the several projects I've done that work on private networks, I use
HTTP for a human interface and TCP for a machine interface. A host can
connect, send commands and get responses. My most recent project allows 5
simultaneous TCP connections. I've also done SNMP, but find TCP easier to
|On Sat, December 17, 2011 2:41 pm, Harold Hallikainen wrote:
To clarify what Harold said- for human interface, HTTP is probably the
best, but HTTP rides on top of TCP. You can make a custom protocol, but
if you want to avoid writing an application for each platform you want to
support, an HTTP interface is probably the most flexible.
For the basic protocol, UDP is simple- kinda like throwing a ball of data
in the general direction of the recipient and closing your eyes. You know
you sent it, but you don't know if it got there and you don't know if the
ball broke on the way. TCP is what's called (in internet terms, anyway)
"reliable"- you open up a connection and what goes in one end comes out
the other. If what you send doesn't get through or is corrupted, there is
enough going on that the stack realizes it, and re-sends. TCP takes more
processing and is slower (due to the handshakes required). UDP is good
when you're trying to get a lot of data across and late data would get
This is just barely touching on the subject. This is really a *huge*
topic- when you start throwing network latencies and the compromises you
have to think about in a microcontroller, it gets even more complex. For
starters, I'd start working with HTTP (which is a protocol on top of TCP)
with a PIC32 and at least 2 sockets and 1KB buffers on transmit and
receive. You start noticing the difference on buffer size mostly with
longer latency connections (such as communicating outside your local
network). You'll be able to get things to work first without getting too
deep into the protocol decisions.
Just outside of Austin, TX
The views I express are my own, not that of my employer, a large
multinational corporation that you are familiar with
YES NOPE9 wrote:
> As more and more things are controlled over the internet ; What schemes are best for connecting embedded devices to [ laptops and smart phones and tablets ] ?
> I have some presumptions ==> Most connections do not require high speed data transfer. Simple messages are sufficient. Simple while extensive ID schemes are best.....
> What do PIClisters suggest ?
I would suggest using a client-server architecture. The embedded devices connect to the server which feeds them instructions on what to do and gathers data from them. Users interact with the server not directly with the devices.
1: there are many situations (involving NAT and/or stateful firewalls) where it is easy to connect outbound to a server on the internet but difficult or impossible to receive connections from the internet. These are likely to become ever more common as IPv4 exhaustion bites.
2: centralised data is easier to secure, back-up etc
3: you are likely to want to aggregate data from multiple nodes
4: serving web pages is quite a complex task it's just about possible to do it on a pic18 but only with horrible compromises on things like concurrent users and/or buffer sizes.
5: it centralises any authentication requirements (important as your user count increases.
Depending on the workload and reliability requirements the server may be something like a beagleboard, a repurposed desktop PC or a proper server and it may be located in a datacenter or under your desk. The important thing is it can receive connections from the internet on a reasonablly stable public IP address and has enough cpu and ram to do TCP properly
More... (looser matching)
- Last day of these posts
- In 2011
, 2012 only
- New search...