Previously, duplicate filtering was...finicky. The duplicate filter was a fixed size, and sending too many messages too quickly could cause it to overflow, resulting in messages being handled when they shouldn't be.
This is a complete overhaul of the duplicate filtering system which makes it capable of adjusting its size as necessary to avoid overflowing.
This PR also adds a new "notify" message type, which is somewhat of a middle ground between reliable and unreliable messages. Notify messages act like unreliable messages in the sense that they are not stored and automatically resent when loss is detected. However, they differ in that they get a sequence ID and loss/delivery is tracked & reported via events in the Connection class, allowing the user to decide what to do in those circumstances.
In the process of adding notify messages, the sequencing system got an overhaul too.
Previously, duplicate filtering was...finicky. The duplicate filter was a fixed size, and sending too many messages too quickly could cause it to overflow, resulting in messages being handled when they shouldn't be.
This is a complete overhaul of the duplicate filtering system which makes it capable of adjusting its size as necessary to avoid overflowing.
This PR also adds a new "notify" message type, which is somewhat of a middle ground between reliable and unreliable messages. Notify messages act like unreliable messages in the sense that they are not stored and automatically resent when loss is detected. However, they differ in that they get a sequence ID and loss/delivery is tracked & reported via events in the
Connectionclass, allowing the user to decide what to do in those circumstances.In the process of adding notify messages, the sequencing system got an overhaul too.