state of server-side packetdup

[sthalik]

Is there a particular reason why server-side packetdup is entirely disabled by default and guarded by USE_PACKETDUP? I'd expect having packetdup on both the client and server to guard against random packet loss to a large degree, along with allowing packet size to decrease to about 500-byte payload.

@skullernet I can do research and work on the packet loss issue but I'd like to hear if this is a lost cause. Naming of SV_PacketdupHack_f in particular is a bit alarming. Why is it a hack?

Some personal notes that confirm this issue:

• during paid work on mobile-phone-based 720p video transmission, 500-byte payloads were most impervious to random losses and bufferbloat, regardless of protocol negotiated; UMTS, HSPA or better. that was despite IP and UDP header overhead, as well as some ~16 byte payload overhead. right now q2pro disallows low packet size set on the client, without changes.
• one could duplicate keyframes only, leaving intermediate frames prone to loss. they're common enough.
• fifteen years ago my ISP had low but noticeable losses to Polish servers in other cities. player position changed to one from several seconds ago, as well as other typical packet loss issues.
• the losses back then were random but consistent. there weren't any periods of extended packet loss at all.

[skullernet]

Is there a particular reason why server-side packetdup is entirely disabled by default and guarded by USE_PACKETDUP?

Doubling packet rate by unconditionally sending each packet multiple times in a tight loop is an awful hack in itself. No transport layer protocols ever do that to combat packet loss AFAIK. It has never worked for me, but players complain until they can use packetdup command, therefore this code is included.

cl_packetdup uses different approach, it includes backup commands in each outgoing client packet without doubling packet rate. It is much more sane and safe to enable by default.

right now q2pro disallows low packet size set on the client, without changes.

net_maxmsglen 512 should work, which results in ~520 bytes UDP payload sizes.

one could duplicate keyframes only, leaving intermediate frames prone to loss. they're common enough.

It doesn't work this way for Q2 protocol. All server frames are equal in terms of importance. "Keyframe" notion in source code only refers to frames that are sent at 10 Hz to all clients in case server FPS is > 10. They are not compressed differently from other frames at all.