Crossfire Mailing List Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: TCP vs UDP



>>>>[From Tero Jyri Michael Pelander]

    > [I write..]
    > IFF there is a holdup, and a packet gets lost with tcp... the server tcpd
    > will retransmit until it gets through. That is stupid, since by the time
    > it is retransmitted, you won't WANT the data anyway! It only serves to
    > screw up your responsiveness.
    
    So...  It doesn't matter that I just missed the update packet on the last
    change on the map.  There was just a new monster that attacks me and I
    don't know of it and the exit is no longer directly south as I see it on my
    screen.

No, it does NOT matter. You'll get another update in a split second.
There's no benefit in getting repeated old information before the newer
update you _really_ care about.

    Of course I still get the 'grimreaper hit you' and I know that
    the exit is "sw" and not "s" as I see it.  No problem.  I just want to give
    my commands a bit faster.

It's actually the opposite. You'll get UPDATES faster, That's what I care
about.

    No matter that the commands that tried to move my character newer got
    to the server as that connection too is just UDP connection.

Oops. forgot about that part :-)
Although if the client is implemented sensibly, the following will happen:

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.

If a packet gets lost, it will just take a little longer to get there :-/
It depends whetner you like overshooting more, or getting to where you
want more.

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

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.

Sound reasonable?

In this model, there might be a benefit for having seperate protocol
   commands for
   
 WALK <direction>
 RUN <direction>
 [and possibly a separate ATTACK <direction>]
 STOP {with direction, or maybe not}
  
    
    In xtrek the updates basically send the nearly same information many
    times over as the enemy ships move continuously.  This isn't the case
    in crossfire where there is a "grid" where the monsters/players can
    move.
    
Are you saying since there's a grid, monsters will move less? That's true,
IFF you let them all lock you into a square, and they all pile around you.
Otherwise, you'll be generating just as many updates as xtrek :-/