Protocol Bandwidth Optimisation

[mh]

[metlslime]

[mh]

[mh]

[metlslime]

[mh]

[frag.machine]

[Spike]

The strengths/weaknesses of many protocols come down to just how they transfer entities (the QW/NQ split is not entirely backwards compatible, and is the main reason modders still don't much like QW - because many features were stripped). But if you want backwards compatible protocols then the major optimisations come from entities.

The original Quake protocol has only a baseline. Every single frame, all entities that are visible are resent deltaed from that baseline. There is no context other than the current state of the entities and the baseline. If you read the documentation somewhere, you'll see that they claim it to be a deltaed protocol. Presumably they didn't even have baselines at one point. Hurrah for LANs.
This copes with packetloss nicely though. :D
Just a shame that each update clogs that 56k modem for half a second each packet. Or longer.

The Quakeworld protocol has 64 different versions of each entity.
The client acknoledges the packet sent by the server, the server sends the differences between the ones that were sent in that packet. New entities are deltaed from the baseline. Drop too many packets and the entities are resent from baselines again.
This works well for reducing apparent latency. A dropped packet will not be noticed beyond the next packet that did arrive.
But on a high latency link, you'll receive the same updates 5 times in a row.
An individual entity will never be half updated.
Note that quakeworld's protocol implements rate limiting as actual dropped packets. :)
Quakeworld was really designed for 300ms ping and 10% packetloss...
Make for AOL!

The DP5+ protocol is slightly different. I wish I could fully remember how it works, so I might be slightly wrong here. Ultimately it only resends entities that are known to have been dropped.
This exhibits worse behaviour when you have packetloss as any dropped packets will not be resent until the next one has arrived and been then acked and received by the server also.
I'd say more, but my memory of the protocol is hazy.
I *think* an entity can be half-updated if there was packetloss.

The (expected) CSQC protocol works similarly to DP5+. The versions are used to remember which version was last sent to the client. The server saves the packet index and the version each time it sends an entity to the client. If the client's sequence numbers indicate a dropped packet, the server resends any entities with a still-unchanged version number with that sequence.
A rapidly moving object will be updating its version number frequently. Its true that the entire entitiy is resent each time the version changes, but with things like rockets, the only actual data expected to be in the packet are its type, origin, and direction. (actually, csqc expects rockets+nails to be sent as source+direction, and to have their version updated only twice - once at spawn, once at removal). Players end up with constantly changing angles and origin anyway. The extra redundancy makes little difference.
Entity updates will be seen updating fully. But only when they actually update. You won't get a half-way changed csqc entity (unless you use multiple ents for a single 'object'). This is part of the justification for having a seperate entity mechanism.


Note that QuakeWorld also sends players using a seperate mechanism from enitities (unless using csqc for players, of course).
Also note that the nq protocol resends the ammo counts every packet (QW and DP5+ do not).
QuakeWorld also never sends the current time across the network, while NQ sends the time in every unreliable packet. This is a hinderance to smooth animations however. But for some reason, sending 77 packets every second (vs 20?) kinda negates the need.

[Urre]

There will be a CSQC protocol? Cool.

Speaking of which, and as it's related to networking, I'll say it here. I recently realised I quite dislike the fact that CSQC always sends the entire entity, it seems unnecessary to me. Is there really no way to redesign that to be able to send partial updates, coupled with some sort of recieve confirmation, so packetloss isn't fatal. Like, create packets which stay in memory and keep being resent at regular intervals until a confirmation about recieval from the client is intercepted, and check packet versioning on the client to make sure old values don't overwrite newer ones in case an old packet is recieved after a newer one.

[Spike]

[Urre]

[LordHavoc]

[Entar]

[mh]

[Entar]