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.
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.
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.
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?
.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.
Regards, Linus