[FEAT] Add "OrderedUnreliable" Type

[reybinario]

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:

• Some client sends three unordered packets modeling an object's physics data at a given moment in time via an unreliable remote in the following order: packet 1, packet 2, packet 3. Note that data in packet 1 is thus older than data in packet 2, and likewise to packets 2 and 3.
• The server receives the packets out of order (say 2, 1, 3), however, nonetheless processes the data (in the order received) and replicates it to other clients.
• Other clients apply the physics data in the order received (say 2, 1, 3 again). Because packet 2's data is older than packet 1's, some "rubberbanding" occurs when applying the physics data to the game world.

Alternatives

1. The control alternative would be to not have this type and simply leave packet ordering to developers. This is fine, but as said before such a type would be a natural addition to a networking library and would reduce boiler-plate code.
2. A new field ("order") could be added to the event constructor. I probably wouldn't do this because such a field would only be relevant for events with type set to Unreliable.

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.

[sasial-dev]

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.

[Ukendio]

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.