We have msg_id for limited replay protection. We could also include those message numbers in textual messages themselves - that way, reconnects would be apparent (msg_id would normally increase by one, and when it instead decreases to 1 or stays at 1 this means a reconnect). This could be done in LKRG or in lkrg-logger (if a message was correctly verified with the expected next msg_id, that number must be the same as LKRG had it on the other end). Alternatively, lkrg-logger could log extra messages of its own upon reconnects (but logging them intermixed with received messages feels maybe conceptually wrong?)
Separately, we could include sent message numbers that would not be reset on reconnect. When not increased, that would indicate an LKRG reload. When increased by more than 1, that would indicate a lost message.
Right now, we already include kmsg message numbers coming from the kernel, but those do not reflect LKRG reloads (they only reflect kernel reboots), some might legitimately be missing if we introduce filtering (#304), and some would have no such number if we introduce extra messages that are not in the kernel's ring buffer (#309).
Nov 10, 2022
We have
msg_idfor limited replay protection. We could also include those message numbers in textual messages themselves - that way, reconnects would be apparent (msg_idwould normally increase by one, and when it instead decreases to 1 or stays at 1 this means a reconnect). This could be done in LKRG or inlkrg-logger(if a message was correctly verified with the expected nextmsg_id, that number must be the same as LKRG had it on the other end). Alternatively,lkrg-loggercould log extra messages of its own upon reconnects (but logging them intermixed with received messages feels maybe conceptually wrong?)Separately, we could include sent message numbers that would not be reset on reconnect. When not increased, that would indicate an LKRG reload. When increased by more than 1, that would indicate a lost message.
Right now, we already include
kmsgmessage numbers coming from the kernel, but those do not reflect LKRG reloads (they only reflect kernel reboots), some might legitimately be missing if we introduce filtering (#304), and some would have no such number if we introduce extra messages that are not in the kernel's ring buffer (#309).