Open reybinario opened 8 months ago
Thanks for such a detailed issue! https://blog.boyned.com/articles/a-reliable-case-for-unreliable-packets/ is a good blog post detailing a valid case for ordered unreliables.
for ordered unreliables.
That blog post only speaks to the case for unreliables in general, where have you inferred about ordered unreliables? Order for them is basically just a timestamp for when they were sent and then process them in that order.
Describe your feature
An ordered, unreliable event type would help developers handle data that immediately expires. It would reduce boiler-plate code in which expired data packets are thrown out and is a natural addition to a networking generated-library. Consider the following example demonstrating the problem such an addition would solve:
Alternatives
Implementation Details
Approach 1
A single, u32 "packetCount" variable for each event, incremented by the sender with each fire and used by the receiver to determine what order packets were sent, throwing out packets with a packetCount less than what has already been read.
Approach 2 (recommended)
Same functionality as before, but packetCount would be u16 and reset to 0 after the 65,535 limit is reached. When the receiver is at or near the limit, it would accept the first packet with a substantially small packetCount value (0, 1, 2, etc., not just 0 because the packet with packetCount 0 could fail to deliver). The receiver would not accept packets with huge packetCount differences (in case packet A has a packetCount of 65,535 and packet B's is 0, and packet B is delivered before packet A). At max sending speeds (every heartbeat), this result would result in a reset every ~18 min. I'm recommending this approach because it seems to be the sweet spot for timing resets and avoiding additional overhead.
Approach 3
Same as before, except a u8 packetCount is used. This would mean packetCount would reset every ~4 seconds at max speeds.
Additional context
Feel free to message me on discord: I'm @reydelcodigo.