Re: TCP vs UDP

[Philip Brown <>]

>>>>[From Eric A. Anderson]
    
    Philip Brown <> writes:
    > >>>>[From Eric A. Anderson]
    >     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.

    But now you need acknowledgements and checks to make things arrive in
    order, and etc. etc.

Some things it matters, some things it doesn't.

In this particular example, the user clicks to move.
If he doesn't start moving, he clicks again. No big deal.


    > 
    > Are you talking bout loading pixmaps or something?
    No, I'm talking about the tcp algorithms to make sure that slow links
    aren't flooded at startup.  The lack of knowledge of stuff like this
    is precicely the problem that I'm talking about.  We as a programming
    group do not appear to know very much about how TCP is implemented.
    Hence it is not clear that we are qualified to implement some protocol
    overtop of UDP.  I believe we will end up implementing some decent
    proportion of TCP.  (Checksums for example)

UDP HAS:
1)   souce socket
2) dest socket
3) checksum
4) user data.

If you want, I'll post ALL the things tcp shoves in its packets.


    
    > 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.
    If you press it once, you know you will move north once.  Are we going
    to put any such nice guarentee into our protocol?

If you want a guarantee to get somewheres, you could use he
"click-to-move" feature, ie "MOVE x y" in protocol-speak.




otherwise, a guarantee of getting to square x in time y, never existed
anyway over a slow link anyways :-/