Re: [Linuxtuples-devel] best effort communication

[Bram S. <br...@sa...>]

Will Ware wrote:
> On 9/14/06, Bram Stolk <br...@sa...> wrote:
>> As an optimization, I've added a best-effort communication channel
>> (UDP based) to the tuple server.
> 
> That sounds interesting. What kind of a situation does that come up?
> Any rough guess of the TCP overhead?

TCP overhead is enormous.
I don't have exact figures, but all sorts of handshaking is required
between parties to setup/close and use a connection.
Each handshake takes a round-trip.

This means a TCP communication is several times slower than
your ping's rtt.

For a single UDP datagram, it should be half your rtt of ping.
So 0.5*rtt, instead of N*rtt for TCP

This is a big issue on WANs.
The speed of light is lower than you think: it takes light
almost 0.1sec to travel from europe to CA USA, and back again.

> 
> I could imagine that if I had zillions of jobs to delegate, I'd
> put_be() all the requests, collect the answers for a while, and then
> check to see which answers I hadn't gotten, and put_be() those again
> (or maybe just put() them, since their smaller number might make the
> TCP overhead acceptable). Is this the kind of usage you have in mind?

I have a different use.
I'm working with Robert Belleman to use the tspace for viz/collab
work. A lot of information in a visualization loop is not essential.

E.g: in video, missing a few pixels, or even an entire videoframe,
does not affect the usability of the video.
Also: in steering... when using a joystick: losing joystick data
for a fraction of a second is no biggie.
(on the other hand: you cannot afford to lose e.g. a QUIT button press).

In rendering 3D frames: when missing a changed transformation of
an object is surmountable if you will receive a new trf next frame.

All these are examples where computer output is generated to be
interpreted by a human. Often the human is too slow to notice
short disruptions.

The cost of reliable communication is not worth it in these cases.


But the scenario you described makes a lot of sense also.
When processing in bulk, where order is not important, you could
work with udp.

Take e.g. peer 2 peer:
I've always been bothered by the use of tcp in torrents.
It makes absolutely no sense!
You get chunks from the peers all the time... if one is lost, no
problem: you'll get it from another peer later. Yet, bittorrent
does TCP.
I've started writing a p2p system on UDP some time ago in python,
but that's gathering dust now.


    Bram

> 
> Will