[Freeciv-Dev] Re: Network bandwidth, and other things.

[Christian Knoke <chrisk@xxxxxxxx>]

On Wed, Nov 06, 2002 at 02:40:40PM -0500, Jason Dorje Short wrote:
> Christian Knoke wrote:
> 
> >What happens with TCP/IP, when a single packet got lost? I think, in the
> >first place, _nothing_ happens. Neither of both endpoints of the connection
> >gets aware of this (But I may be wrong here!). Only after another packet is
> >sent in the same direction, or a specific amount of time passes, the
> >receiver gets notified of this and resends the packet.
> 
> After each packet sent an "ACK" packet is sent in return.  If the ACK 
> does not arrive in a reasonable timeframe (which is a very difficult 
> subject in itself), the packet is resent.

Yes, that's the question! If the timeframe is 10 sec or greater, the above
applies.

> So, this is not a problem.

Not?

> >So: What happens when I try to move a unit (cursor key) and the packet gets
> >lost? I wait a long time, getting nervous, losing needed time to fight the
> >battle. That has actually happened to me. Finally, the TCP/IP layer gets
> >aware that a packet is missing and resends it. Civserver answers, the unit 
> >moves on the screen, the battle's lost. Shit happens.
> >
> >What can we do? Just send a ping every second (if nothing else is sent
> >within a second). TCP/IP notices the packet loss when the ping arrives, and
> >retransmit of the lost packet is initiated. This should keep the delay 
> >below
> >2 seconds. - - And now the flames, please :)
> 
> Flame flame :-)
> 
> Sending a ping every second will only slow things down.  Now not only 
> will you have to wait for our lost packet above, but every time a ping 
> is lost you'll have to wait then too (although a later packet may 
> arrive, it will not be usable by the server until your.

Good point, but if a ping packet gets losts, you can go on after 2 seconds.
If a move packet is lost, you'll sit and wait ... Nothing you can do. You
*can't* just press that cursor key again. If you have bad luck, you wait
long.

> I can imagine (but can't say definitively) why the above behavior might 
> happen.  If you're on a slow (high-latency) connection, then the 
> round-trip-time from client to server will be high.  In this case the 
> packet will take longer to be sent.  And if the packet is lost multiple 
> times (which is probably likely - packets usually aren't just dropped 
> randomly but are dropped because somewhere a server's buffer is too big) 
> then the wait will be extended.

Ok, this may be true, that a server's buffer is overrun. But as soon as
one packet gets through (I think), TCP will correct the drops (by 
resending) and you'll be fine 2 sec later.

> jason

Christian

-- 
Christian Knoke     * * *      http://www.enter.de/~c.knoke/
* * * * * * * * *  Ceterum censeo Microsoft esse dividendum.