1

Topic: What happens when a packet is lost?

Let's say a packet containing msg "shoot" gets lost on its way to server.
Then how does Teeworlds handle this?
Does it try to resend? or just ignore?

2

Re: What happens when a packet is lost?

Teeworlds uses the UDP protocol... So yea, it is "just lost".

Real programmers don't comment their code - it was hard to write, it should be hard to understand.
Proudly verkeckt since 2010.

3

Re: What happens when a packet is lost?

Well teeworlds uses UDP and therefore packages may get lost but teeworlds uses a system to figure that out and resends packages. It depends on how you send a package.

uptee - a simple web interface for hosting and maintaining teeworlds servers
teerace - a website gathering results of trusted Race-mod servers providing global ranking and statistics
*gV* rox ^^

4

Re: What happens when a packet is lost?

Wait..... Then, why do you "emulate" tcp (check if packages are lost, resend, etc) when you can just use tcp and get better performance? (or use both)

Having troubles finding servers in the serverlist? Go to Pastebin (its a referer cause there is daily a new pastebin) and add the lines to your settings.cfg (in %APPDATA%\teeworlds). Then open teeworlds and go to the favorites tab. (Note however, standard teeworlds client can only show 256 favorites, use ddnet instead)

5

Re: What happens when a packet is lost?

xush wrote:

Teeworlds uses the UDP protocol... So yea, it is "just lost".

It's not that simple, TCP uses IP, so packets may get lost, however the transport layer ensures that the application will not notice these losses.

Teeworlds uses a system of vital and non-vital messages. For vital messages it ensures that they arrive and that they arrive in order, for non-vital messages it doesn't. Input and snapshots (snapshots are the game state that the server sends to the client) are the two non-vital messages I know of, this is because by the time you'd resend them, they are already outdated.

Now I'm not completely sure how the loss of an input packet is worked around, the shot is definitely happening sometime later, but I don't know how eager the client is to resend an input packet when nothing changes.

6

Re: What happens when a packet is lost?

The packet is lost, and is not re-sent. However, since the inputs use a counter to indicate that a shot has been fired (every you press/release fire, the counter is incremented), the shot will be fired once the next input message reaches the server, as the server will be able to tell that the counter has been changed/incremented since last time.

7

Re: What happens when a packet is lost?

Schwertspize wrote:

Wait..... Then, why do you "emulate" tcp (check if packages are lost, resend, etc) when you can just use tcp and get better performance? (or use both)

You can't partially drop features from TCP, which is why you have to implement on top of UDP instead. The most important feature of TCP that we don't want to have is the transparent reliability, that you have to wait for intermediate packets if you already got newer info.

See e.g. this pretty good article on TCP vs UDP: http://gafferongames.com/networking-for … dp-vs-tcp/.

8

Re: What happens when a packet is lost?

heinrich5991 wrote:
Schwertspize wrote:

Wait..... Then, why do you "emulate" tcp (check if packages are lost, resend, etc) when you can just use tcp and get better performance? (or use both)

You can't partially drop features from TCP, which is why you have to implement on top of UDP instead. The most important feature of TCP that we don't want to have is the transparent reliability, that you have to wait for intermediate packets if you already got newer info.

See e.g. this pretty good article on TCP vs UDP: http://gafferongames.com/networking-for … dp-vs-tcp/.

After read it, idk what is the problem for use TCP in download process... when the client is downloading maps does not in time "critical"  no? DDNet have this feature... and in the final the author tell that you can use for example TCP to talk to some RESTful service (and this in 'critical' time)... :\

9

Re: What happens when a packet is lost?

unsigned char* wrote:

After read it, idk what is the problem for use TCP in download process... when the client is downloading maps does not in time "critical"  no? DDNet have this feature... and in the final the author tell that you can use for example TCP to talk to some RESTful service (and this in 'critical' time)... :\

Map download is indeed one of the things that could optionally be TCP, as DDNet demonstrates quite well. Note that the TCP-like attributes of the TW protocol are also used for chat messages, rcon, etc., where additional TCP wouldn't be as useful. Also, you should probably still have a map download fallback via UDP, so it doesn't break because TCP doesn't work (I think that's also how source games implement it, you can optionally provide a HTTP URL where clients can get the resources, but the client can also get them from the game server directly).

10

Re: What happens when a packet is lost?

nuborn wrote:

The packet is lost, and is not re-sent. However, since the inputs use a counter to indicate that a shot has been fired (every you press/release fire, the counter is incremented), the shot will be fired once the next input message reaches the server, as the server will be able to tell that the counter has been changed/incremented since last time.

But how would the server know the direction of the shot?

11

Re: What happens when a packet is lost?

kiwon0905 wrote:
nuborn wrote:

The packet is lost, and is not re-sent. However, since the inputs use a counter to indicate that a shot has been fired (every you press/release fire, the counter is incremented), the shot will be fired once the next input message reaches the server, as the server will be able to tell that the counter has been changed/incremented since last time.

But how would the server know the direction of the shot?

It effectively doesn't I guess. It'll just take the direction once it learns that you shot some time ago.