Making Things Talk

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