You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
No description provided.
The text was updated successfully, but these errors were encountered: