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

Avoid queueing redundant commands (like GET requests, NonceReports, etc.) #1482

Open
AlCalzone opened this issue Jan 23, 2021 · 1 comment
Open
Assignees
Projects

Comments

@AlCalzone
Copy link
Member

No description provided.

@LordMike
Copy link
Contributor

Thought: One way of doing this would be to let each command implement some GetHashcode or similar, which would return a unique string identifying the contents. If two commands have identical hashes, they will yield the same response from a node.

The queue can then, when it decides to, compute the hash of all messages for some node, and only keep the last or the first message for each unique hash.

Example: Two GET's, for different values, could produce two unique outputs for GetHashcode. The queue will then know that they should not be deduplicated.

Example: Two GET's for the same value, or two NOOP's, will all return the same Hashcode, and therefore the queue can deduplicate them.

Example: Two SET's for the same value, but with different payloads could yield the same Hash, and thereby let the last message win.. This would help in cases where a user rapidly sets many different values f.ex. for a multilevel switch (dragging some slider for brightness).. In these cases, only the last message is really important, and since they all supersede each other ..

It may get tricky with multilevel up/downs, or other messages that aren't "Set to N value" as these could come out of sequence....

E.g., user submits: Multilevel up, Multilevel down, Multilevel up, Multilevel down. If the queue is emptied after the first message, it may deduplicate the two Multilevel down's, but keep the Up. The end result is that the Multilevel up is the last message sent...

In theory, maybe these messages should have the same Hashcode, and then keep the last inserted message. Since they supersede each other.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
No open projects
Triage
Backlog
Development

No branches or pull requests

2 participants