Re: Linux Network Joystick interface

And what "trap" is TCP? UDP is fine, and all, but on a mobile device, I want
to guarantee delivery of packets and know if they fail.

There are a lot of "tricks" to get a good server system running with TCP,
but they are pretty pedestrian these days.

on a mobile device you don't want all those ack/nak signals floating
across the network.  They can saturate the network and cause messages to
be queued up and processed in much longer than real-time: a problem
if you're expecting to have joystick commands immediately processed.  This
is one case where QOS isn't a good thing because although TCP delivery is
somewhat guaranteed, there is no guarantee (when) the message will finally
get there.

Then there is the speed difference.  TCP over 802.11b (what you'll use if
going peer to peer) will be very slow.  Figure as a best case UDP on
802.11b will give effective thruput of about 5mb/s whereas TCP (with
no drops) will be less than half that rate.

UDP is really the only option for wireless command and control, but to
further the discussion, wireless ethernet really isn't appropriate for
wireless robotic control in real-time, especially if you want to do
(beyond line of sight) control.

I disagree that TCP isn't workable for wireless control, but UDP is a
good option where latency needs to be kept low and an occasional lost or
out of order packet is tolerable.  If you're sending something like
joystick states updated every few ms, UDP is good.  If a packet is
missed an update is coming soon behind it.  Include a sequence number in
the packet, and unless there's a severe delay between packets go with
the latest packet as current.  If there are several packets lost in
sequence TCP is unlikely to be getting through either.

On the other hand, if the protocol sends only changes in state most of
the time you need the reliability of TCP, but are saving bandwidth by
not sending redundant data.  Depending on the nature of data to be
communicated, TCP with such a protocol may deliver less latency on
account of bandwidth.

While that is somewhat true, but, properly coded you can "timeout" on the
API calls. If you have QOS issues, a networked API is problematic no matter
what. Using TCP ensures that packets get there and if they don't, you know
it.


Depending on packet size, maybe. If you are not sending a lot of data, i.e.
filling the MTU , as in sending a file, but are sending and receiving
relatively small packets, the bandwidth is not really an issue, even with
11b.

The best analogy I can come up with is the X Window System in UNIX. Human
interface devices are VERY SLOW, keyboards, mice, and joysticks are
nothing. Video and audio, now *that's* a lot of load.


Well, the video over IP is a problem as the video signal must be digitized
and there is often a few seconds lag with an MPEG encoder. I need to find
something faster, and that data is appropriate for UDP, absolutely.