Background — In RTS we relied everyday on a UDP message replay tool, taking in a msg file and a corresponding time file. Both binary files. I saw
no message delimiters in the msg file, partly because this file is produced in production. Inserting delimiters would add overhead in production parser engine.
Given there’s no delimiter, I believe the timestamp file must have a seek-offset values (marker) corresponding to each timestamp.
Q: how would you implement a similar replay tool?
Driver is the timestamp file. Every time I see a timestamp, I would wait_until() that timestamp (adjusted to my start time). Upon wake-up, I would send the corresponding chunk of bytes between current and next markers.
I would use condition_variable::wait_until(). As noted in c++condVar 2 usages #timedWait, this function has nanosec precision.
(The mutex needed in wait_until? My program is single-threaded, so the dummy lock would be held forever.)
The chuck of bytes would be sent as one UDP packet. No split. Each chunk should starts with an original packet header created by the matching engine, and received in the original feed.
Q2: how about TCP?
TCP receiver can deal with partial messages very effectively, as I saw in my tests.
However, TCP receiver can introduce delays in the sender i.e. my replay tool, so the transmission will not be instantaneous. In fact, send() can block! This could lead to drift in the timer. That’s why I need wait_until()
Q3: Explain timer drift?
Suppose in the time file, Timestamp #1 is 9:00:00:000001 and Timestamp #2 is one microsec later, but the data transmission can take 10 nanosec esp. with TCP blocking send(). This 10 nanosec is a small drift but it adds up to microseconds.