Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Net: Include more message numbers #311

Open
solardiz opened this issue Feb 25, 2024 · 0 comments
Open

Net: Include more message numbers #311

solardiz opened this issue Feb 25, 2024 · 0 comments
Labels
enhancement New feature or request

Comments

@solardiz
Copy link
Contributor

Nov 10, 2022

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).

@solardiz solardiz added the enhancement New feature or request label Feb 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant