While resetting the stats isn't strictly necessary, it seems like a bit of a bug to me since the old values will be considered as part of the smoothing function.
Resetting time also isn't necessary with respect to reliable_endpoint_update, because the first thing it does is overwrites it, but it also gets used in reliable_endpoint_receive_packet to update rtt, so maybe it's a good idea to reset it, too? Whether it's the old value, or zero, it would be a bug in reliable_endpoint_receive_packet, so I'm just assuming that reliable_endpoint_update always gets called before reliable_endpoint_receive_packet after a reset. The zero feels like an easier bug to catch if someone calls them in the wrong order. 🤷
While resetting the stats isn't strictly necessary, it seems like a bit of a bug to me since the old values will be considered as part of the smoothing function.
Resetting time also isn't necessary with respect to
reliable_endpoint_update
, because the first thing it does is overwrites it, but it also gets used inreliable_endpoint_receive_packet
to updatertt
, so maybe it's a good idea to reset it, too? Whether it's the old value, or zero, it would be a bug inreliable_endpoint_receive_packet
, so I'm just assuming thatreliable_endpoint_update
always gets called beforereliable_endpoint_receive_packet
after a reset. The zero feels like an easier bug to catch if someone calls them in the wrong order. 🤷