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
