Re: F1 22 UDP Specification

@Hoobiechoobie I think this was already discussed in the past, but I think currently it's not possible to properly handle "flashbacks" with the data sent by the game (I think this is true since F1 2018). If I'm wrong, please correct me ( @cjorgens79  😉 )

We collect data for telemetry analysis, and not being able to handle flashbacks results in bad data streams, mixing packets from different "time-lines".

The main issue is that when a flashback occurs, both the the fields m_sessionTime and m_frameIdentifier wind back in time at the old values, making impossible to detect in a reliable way the event (e.g. if the FLBK event is lost or arrives out-of-order) and properly handle it (newly arriving packets will be indistinguishable from "old" packets, making impossible to understand if they're duplicated UDP packets, old out-of-order delivered packets, or new packets following a flashback).

This is an example from a real captured data flow:

Packet 13587 arrived notifying a FLBK event (considering the UPD protocol, it could easily go lost or arrive at the wrong moment, so it's not really useful in this context - but here you can see the correct header values received):

Packet 13588 arrived, and now m_sessionTime and m_frameIdentifier wind back and are now using "old" values:

A very simple solution would be to have m_frameIdentifier to continue with monotonic increasing values, also in case of a flashback. This would easily allows to detect and handle in a reliable way flashbacks (since m_sessionTime would be have wound back).

Thanks.