Re: TCP vs UDP

[Philip Brown <>]

>>>>[From Eric A. Anderson]
    
    > You want to move north. You hold down the "up" arrow.
    >    client generates "move north" commands.
    > You get to where you want to go.
    > You let go the up arrow.  client stops generating "move north" commands.

    This introduces the problem of how fast does the client generate move
    north commands.  Conceptually, what *I* want is a move to the
    following location command, not move n w n n w e e s w w.

Client could implement that, too. a "click to move here" command.

    > Actually, depending on how the protocol finally happens, it won't make a
    > difference if we use UDP.

    Except we will have to re-implement all the slow start stuff to keep
    from overflowing slow and/or loaded links, we have to re-implement
    guarenteed delivery stuff, etc. etc.

Not sure what you're referring do, vis-a-vis "slow start stuff".

Are you talking bout loading pixmaps or something?


    > Pressing the uparrow could generate a "keep going north" protocol request.
    > releasing the uparrow could generate a "Stop going north" request.
    > This would exactly mirror the response you might get with tcp, but
    > with much less overhead.

    Except there are problems with latency and lost packets.  What happens
    when the stop going north request gets lost?  You don't have this
    problem with tcp.
    
Wel.. you have different problems with tcp, after all. it IS a tradeoff.
Sometimes, the "move north" tcp packet gets delayed, so you end up
pressing it a few more times, making movement unpredictable.

    > Sound reasonable?

    I personally think UDP would be a really big mistake.  We don't seem
    to have a very coherent opinion of what the protocol should be like,
    and I think it would be a really big mistake to try and implement
    stuff over UDP unless there is some very clear benefit.
    Overhead is not a clear benifit because over the slow links we keep
    worrying about, the protocols usually do some sort of header
    compression.

Anyone got some figures as to exactly how much gets "compressed", in a
tcp packet with 40 bytes of header, and 40 bytes of user information?!
(compared to UDP. does UDP get compressed at all?)


    Furthermore, we lose a lot of work that already gone into making tcp
    work well.

yes, sure.. but do we need somthing that works quite as thoroughly as tcp?
If we do not, then it's up to us to put some very reduced form of that
onto UDP, and save the net some bother.

If we end up putting 50% or more of what tcp already comprises, than of
course we should stick with tcp. But we don't need all that!!