hi i am wondering about the header size of tcp and udp packets on google i found TCP = 20 UDP = 8 is that correct? How would you improve the a fps network for low bandwidth connections? currently I plan to update the positions and angles with 30 delta pakets per second all the data bitpacked together to reduce paket size and every x msec i let the client send his state information about each player on the server so the server knows if he had to resync the stateinformation on the client from my calculations i have 2.5kb/s of 7.5 kb/s left so i can make use of the upstream of the client for state resync each packet contains a sync number between 0 15 (++i)%16 to keep packets in order if the client misses a packet for x ms it sends the server its current state for resync any idea on how to improve it my aim is to optimize for low bandwidth

30 updates s-1 seems a touch on the high side. As you've probably realised the packet overhead isn't that light.

A better bet is to send more information less often and let prediction compensate. A good motivation is to calc the # of bytes sent per second, then look at how much of that is data and whats overhead. Less updates, more info gives significantly better results.

Have a look at Quake 3 packet logs for an idea of a good implementation. In fact seeing as the source is available now, just grab that and have a look-see. Should be pretty helpfull given that it'll run on a 56k, first time i seen the upload usage i think i catagorised it as 'stoopid low' ;-)

Think i might toddle off and have a peek at their souce myself.


EDIT:
Can't remember the TCP / UDP overhead at present but remember that each TCP packet requires an ACK in return which i think is of around 72 bytes. And on top of the UDP / TCP info you've got the eth and ip data too.

ethereal is handy if you haven't got it yet.

I will use UDP since lost pakets will be compensated by state packets

In call of duty i have my packet setting at 30 which is perfect

with a decent isdn connection you get a ping of 41-44 ms to a decent webserver

with dsl and fastpath around 15-20 ms this allows for low pings of e.g. <70 ms even on isdn although the amount of data send influences the latency a lot

another thing i do is putting the whole network part into a seperate thread aiming for dual core processors so lag spikes or processing heavy scenes don t affect latency that much

what i propably could do is putting all the none critical information at the end of each packet to make use of the already send packets headers to avoid overhead

but on the other hand the more packets you send the smaller the delta values ->less information to send and the drop of one packet isn t that critical

you just request a state update by sending your current state the server evaluates whats different and sends you an update

I also want to keep the update visibility dependent

e.g. there are 3 zones 1. 2. 3.
the second blocks
so when you enter zone 1. the server starts updating your state information so you can pass into zone 3. without lag spikes

however at the latest games e.g.: call of duty which i play a lot i make the experience that heavy gunfire increases your lag a lot and the producers of these titles don t makes this huge amout of data an optional part of network traffic that can be skipped when you exceed bandwidth

It really depends what you mean by low bandwidth. In the console market, when peer to peer connectiosn aren't used you'd be crucified for using anywhere near 5k upload, in my experiance at least.

Its all relative, if you don't have to worry about server costs then having frequent updates is a quick solution to making the game feel more responsive. In the long run a better prediction system would either allow you to send more data, or reduce the bandwidth your game consumes.

As far as i know the lag from heavy fire in COD is a dual effect, the particles spawned from the Thompson can kill the frame rate, likely it increases net traffic though i don't remember any significant increase. Its been a while since i checked so i may be wrong.

TCP packets have a 20 byte TCP/IP header plus a 20 byte TCP header, so the overhead is 40 bytes. For UDP, the overhead is 28 bytes. However, with TCP, you don't really control what gets sent into a packet. When you send something, it might remain in a queue until your Operating System's TCP/IP handling system decides there is enough data to send. And as said earlier, there are also ack packets. But this is not the only problem. Additionally, if a packet gets lost, it has to be resent, and you can't get the packets coming after until this lost packet has been received, which "paralyzes" your network traffic for a brief period... While in fact, you probably prefer that lost packet to remain lost.

In general, for FPS games, or anything that demands responsiveness, UDP is the way to go. Unless you only plan to run your system on a LAN. All the mainstream FPS games (Quake 1/2/3, HL1, HL2, Unreal 1/2/T/..., etc.) use UDP for the reasons I mentioned above. TCP is mostly practical for strategy/low paced games, like Age of Empires or Starcraft, where it's nice to have the protocol handling most of the data consistency issues for you.