Hi,
On 12/09/2024 13:08, Linus Lüssing wrote:
Hi Antonio,
Thanks for the feedback!
I haven't followed previous discussions, therefore my question may just sound redundant, but if "cache_hash" is for ARP what is the "DAT DHT"? (the A in DAT stands for ARP).
The dht_hash would just store what was pushed to it from remote nodes through the DAT DHT feature. So through a BATADV_P_DAT_DHT_PUT in a batman-adv unicast4addr packet.
And would only be used for responses to a BATADV_P_DAT_DHT_GET.
The cache_hash would store all the other cases. That is local additions learned through bat0. Or the responses this node got to a BATADV_P_DAT_DHT_GET.
Ah I see, so you're entirely splitting the DHT from the local ARP cache. Naming indeed makes sense now.
Moreover, it seems with this approach you are converting the DAT concept into something "type specific" - am I wrong?
You mean to be able to use it for other types than ARP? Like the patchset we had for IPv6 a while ago? Hm, no, that at least wasn't the intention.
nah, I got it wrong. Your explanation above helped me clear the doubt.
Is it truly required just to have a different timeout? Wouldn't a mark on entries be enough to instruct the subsystem about what timeout value to use?
That would work, too, right. I just found a split simpler and less error-prone. With flags I'm always worried about missing potential race conditions when flipping it back and forth. Especially with the two different timeouts involved here.
From what you are saying and (what I understand) this splitting is not only about the timeout, but it's a clear cut between "what we have in the DHT" and what we are collecting locally.
So splitting data structure makes a lot of sense to me.
With a flag, you should assume that a specific entry can either have or not the flag set. With two tables, the same entry could technically exists in both and it'll be up to you decide how to handle the situation (without ambiguity in this case because you know exactly where each entry is coming from).
For instance if I had an entry through a remote node (BATADV_P_DAT_DHT_PUT) and therefore with a flag set. But now got an update for the same address/entry through bat0 (maybe the client device roamed to us? Or some collision / duplicate address usage?). Should I now always unset the flag? Or should I check if its remaining timeout is less than 5min and only if it is then unset the flag?
Should a response to a BATADV_P_DAT_DHT_GET only be to an entry with the flag set? Or independent to what the flag is set to?
I feel you need to answer the above questions even with two tables. No? The difference is that with two tables you have more information and don't need overwrite a DHT entry with a local one (and viceversa).
.oO(Maybe a split could also be useful if one wanted to introduce individual limits for additions? Against remote attackers trying to DoS a node?)
Let me know if you'd still prefer a flag instead of a separate hash table and I could change that.
I think splitting is a good idea, not only because of the timeout, but also because it makes the state more clear.
Regards,
Regards, Linus