[Rxtx] phidgets

[Mike Kirkland]

Kustaa and Mariusz,

Yes you have very good comments on when UDP would be better for some
applications.

The applications I have worked on have been limited to the types where
missing data would be a big issue and it would be better to lose the
connection.

It is what makes participating in Internet forums so fun and interesting;
others have had such a wide range of experiences solving difference types of
problems.

Mike

-----Original Message-----
From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of
Kustaa Nyholm
Sent: Wednesday, December 30, 2009 7:01 AM
To: rxtx at qbang.org
Subject: Re: [Rxtx] phidgets



> From: Mariusz Dec <mariusz.dec at gmail.com>
> Date: Wed, 30 Dec 2009 12:30:23 +0200
> To: Mike Kirkland <m.kirkland at comcast.net>
> Cc: <rxtx at qbang.org>
> Conversation: [Rxtx] phidgets
> Subject: Re: [Rxtx] phidgets
> 
> Hi Mike,
> 
> 2009/12/30 Mike Kirkland <m.kirkland at comcastnet
> <mailto:m.kirkland at comcast.net> >
>> ....
>> UDP is not likely a good choice for this as there is no guarantee that
the
>> data will arrive at the other end. I would suggest sticking with TCP. UDP
>> could also present NAT routing issues.
> 
> Yes, you are right, but sometimes in internal networks, when communication
> errors occur not often, remembering about UDP is good idea.
> 
I agree that one should not just off hand disregard UDP and go with TCP by
default. It all depends.

I've recently implemented a couple of devices where I used TCP and
in retrospect I'm confident that I could have done better with
UDP. With TCP , in my case, I needed to have the mechanism to monitor
if the connection is still there (users often unplug/plug cables
for one reason or an other), and mechanism to re-establish the
connection and update state information between the devices. So
basically all the mechanism one needs when dealing with the
'unreliable' UDP protocol PLUS THE NEED TO MONITOR the connection.

UDP would have been at least marginally bit simpler. Also I think
it could have resulted in a more responsive system as the
detection of a broken TCP connection and re-establishing it
connection takes several seconds in our system whereas a continuous
UDP packet stream would be up and running in a few milliseconds
once the cable is plugged in.

br Kusti

_______________________________________________
Rxtx mailing list
Rxtx at qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx