[GNUnet-developers] addHostWithSKEY fux0red?

[Igor Wronsky]

Hello all. I kept receiving 

WARNING: key exchange failed: addHostWithSKEY returned SYSERR

announcements. This is because keeping CONNECTION_buffer_ as e.g. 
64 slots doesn't guarantee 64 hosts at this point, because not 
even the 10 or so current hostids distribute evenly in the used
hostid->slotid hashing scheme. There is collisions. :( The main 
problem with this is the warnings that confuse the user without
any hint what might be wrong or what could be done. Technically,
one option would be to keep overflow lists and keep track 
with variables that the amount of connections is not exceeded.

Note that in the long run this is not a problem, because if/when 
the global host amount exceeds the buffer size, it will
eventually begin to be possible to get all slots filled.

Actually, the problem is something else. While 
examining this and looking at sessionkey.c/addHostWithSKEY(),
I couldn't help but wonder at its operation (look
at the code while reading this):

suppose lookforhost(hostId) returns NULL. This
means addHost(hostId) will be called. This cannot fail. 
The next if(be == NULL) will never evaluate as true. 
Also, the !hostIdentityEquals() check later on is 
redundant because both addHost and lookForHost keep
sure of this. This means only "be->created > created" 
will matter. Now, this is the phase that causes the 
warning mentioned above. This is a bit odd, because 
be->created is related to the old host, because "be"
was *only partly* written over by addHost(). Why
compare "created" of two different hosts? Besides,
now returning at this phase with SYSERR leaves the "be" 
record partly rewritten by the new host! Isn't
the entry now inconsistent?

Another question is, why we allow addHost to overwrite 
the old host at all? Suppose lookForHost failed because
the host in the slot didn't have same identity, not
because the slot was empty. The old host in that slot
might be perfectly fine. Why are we overwriting it? Won't
the overwritten old host now rewrite this host once
it sends an SKEY? how harmful this oscillation is?

I might be wrong, but my nose sends me signals of anomalies. 


Igor