Hardware Reference
In-Depth Information
Interactive Systems and Feedback Loops
In every interactive system, there's a feedback loop: you take action, the system
responds, you see the response—or a notification of it—and you take another action.
In some systems, the timing of that loop can be very loose. In other applications,
the timing must be tight.
For example, in the cat bed application in Chapter 3,
there's no need for the system to respond in more than
a few seconds, because your reaction is not very time-
sensitive. As long as you get to see the cat while he's on
the bed (which may be true for several minutes or hours),
you're happy. Monski Pong in Chapter 2 relies on a rea-
sonably tight feedback loop in order to be fun. If it took a
half-second or longer for the paddles to move when you
move Monski's arms, it would be no fun. The timing of the
feedback loop depends on the shortest time that matters
to the participant.
connections between all the objects will be configured. Will
it be a star network, with all the participants connected
through a central server? Will it be a ring network? Will
it be a many-to-many network, where every object has
a direct connection to every other object? Each of these
configurations has different effects on the feedback loop
timing. In a star network, the objects on the edge of the
network aren't very busy, but the central one is. In a ring
network, every object shares the load more or less equally,
but it can take a long time for a message to reach objects
on opposite sides of the ring. In a direct many-to-many
network, the load is distributed equally, but each object
needs to maintain a lot of connections.
Any system that requires coordination between action and
reaction needs a tight feedback loop. Consider remote
control systems, for example. Perhaps you're building a
robot that's operated over a network. In that case, you'd
need not only a fast network for the control system, but
also a fast response from the camera or sensors on the
robot (or in its environment) that are giving you informa-
tion about what's happening. You need to be able to both
control it quickly and see the results quickly. Networked
action games also need a fast network. It's no fun if your
game console reacts slowly, allowing other players with
a faster network connection to get the jump on you. For
applications like this, an exchange protocol that's con-
stantly opening and closing connections (like HTTP does)
wouldn't be very effective.
In most cases where you have a limited number of objects
in conversation, it's easiest to manage the exchange using
a central server. The most common program example of
this is a text-based chat server like IRC (Internet Relay
Chat), or AOL's instant messenger servers (AIM). Server
programs that accept incoming clients and manage text
messages between them in real time are often referred to
as
chat servers
. The Processing program you'll write in this
chapter is a variation on a chat server. The server will listen
for new connections and exchange messages with all the
clients that connect to it. Because there's no guarantee
how long messages take to pass through the Internet, the
exchange of messages can't be instantaneous. But as long
as you've got a fast network connection for both clients
and server, the feedback loop will be faster than human
reaction time.
X
When there's a one-to-one connection between two
objects, it's easy to establish a tight feedback loop. When
there are multiple objects involved, though, it gets harder.
To begin with, you have to consider how the network of
