[core] check timestamp carryover for keepalive packets

[gou4shi1]

If client keepalive for more then 1h10m, then server will not know the timestamp has been carryover.

[maxsharabayko]

Good catch!
If a client is sending keepalive for more than 1h10m and does not receive any data, another problem would be to compensate clock drift once the transmission is resumed. 🤔

[gou4shi1]

So we should also addRcvTsbPdDriftSample() for keepalive packets?

[ethouris]

No, this won't help. The problem of keepalive packets is that it's one direction only and unreliable as well, while in order to update the drift you need to have some request-response cycle.

I think that it might be needed that in the situation of stopped transmission and sending keepalives the transmission start time shall be reset to 0 and set again only at the first received packet. This time always serves as a time pattern of the expected arrival time, so such a time reset shall restore time conditions to "zero drift" again. The problem might be though that this method need not be reliable, and of course, this must be also treated exceptionally differently for backup groups.

[gou4shi1]

My fix will cause the "No room" issue...
Can you provide a hotfix without drift?
I don't care about drift since I disabled drift tracer (which will cause the "No room" issue).

[maxsharabayko]

My fix will cause the "No room" issue...

Do you mean that the fix you've provided does not help in your use case?

The "no room to store.." will likely be caused by clock drift, accumulated while the link is idle.
Note. The error message is to be improved in #1909 .

[gou4shi1]

Do you mean that the fix you've provided does not help in your use case?

It should help, but with this fix, srt report "No room..." frequently

The "no room to store.." will likely be caused by clock drift, accumulated while the link is idle.

so I have disabled the drift tracer long time ago

Note. The error message is to be improved in #1909 .

Thanks!

[gou4shi1]

Anyway, I have workaround this issue with a hack:
if the connection is connected for more than 1h and idle for more than 5s, reconnect it :)