222 MAKING THINGS TALK
Look, Ma: No Microcontroller!
Since the beginning of the book, you’ve been working with programmable micro-
controllers, writing the whole program yourself. You don’t always have to do this. The
various network devices you’ve been working with — the Lantronix devices, and XBee
and Bluetooth Radios — all have their own microcontrollers built in. Some of them have
their own digital and analog input and output pins. You can configure these devices to
activate and respond to these I/O pins with network messages, but you need to learn
their protocols first. To give you some examples of how you can use these network
modules to their full potential, none of the projects in this chapter use programmable
microcontrollers.
Sessions versus Messages
In Chapter 5, you learned about the Transmission Control
Protocol, TCP, which is used for much of the communica-
tion on the Internet. To use TCP, your device has to request
a connection to another device. The other device opens
a network port, and the connection is established. Once
the connection is made, information is exchanged, then
the connection is closed. The whole request-connect-
converse-disconnect sequence constitutes a session. If
you want to talk to multiple devices, you have to open and
maintain multiple sessions. Sessions characterize TCP
communications.
Sometimes you want to make a network in which objects
can talk to each other more freely, switching conversational
partners on the fly, or even addressing the whole group
if the occasion warrants. For this kind of communication,
there’s another protocol used on the Internet, called the
User Datagram Protocol, or UDP.
Unlike the session-based TCP, UDP communication is all
about messages. UDP messages are called datagrams.
Each datagram to be sent is given a destination address
and is sent on its merry way. Once the sender sends a
message, it forgets about it. There is no two-way socket
connection between the sender and receiver. It’s the
receiver’s responsibility to decide what to do if some of
the datagram packets don’t arrive, or if they arrive in the
wrong order.
Because UDP doesn’t rely on a dedicated one-to-one
connection between sender and receiver, it’s possible
to send a broadcast UDP message that’s sent to every
other object on a given subnet, For example, if your
address is 192.168.1.45, and you send a UDP message
to 192.168.1.255, everybody on your subnet receives
the message. Because this is such a handy thing to
do, a special address is reserved for this purpose:
255.255.255.255, which is the limited broadcast address,
goes only to addresses on the same LAN, and does not
require you to know your subnet address. This address is
useful for tasks like finding out who’s on the subnet.
The advantage of UDP is that data moves faster, because
there’s no error checking. It’s also easier to switch the end
device that you’re addressing on the fly. The disadvantage
is that it’s less reliable byte-for-byte, as dropped packets
aren’t resent. UDP is useful for streams of data where
there’s a lot of redundant information, like video or audio.
If a packet is dropped in a video or audio stream, you may
notice a blip, but you can still make sense of the image or
sound.
The relationship between TCP and UDP is similar to the
relationship between Bluetooth and 802.15.4. Bluetooth
devices have to establish a session to each other to com-
municate, whereas 802.15.4 radios like the XBee radios
in Chapter 6 communicate simply by sending addressed
messages out to the network without waiting for a result.
Like TCP, Bluetooth is reliable for byte-critical applications,
but less flexible in its pairings than 802.15.4.
X
Making_Things_Talk.indb 222 11/13/09 4:54 PM

Get Making Things Talk now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.