reconcilation

[vi...@eq.by]

Hi!

I am wondering what the following means?

INFO[0450] reconcilation done label=gossip :11370
INFO[0450] recovered 773 items label=serve :11370
INFO[0287] reconcilation done label=gossip :11370
INFO[0287] recovered 731 items label=serve :11370
INFO[0454] reconcilation done label=gossip :11370
INFO[0454] recovered 776 items label=serve :11370
INFO[0524] reconcilation done label=gossip :11370
INFO[0524] recovered 763 items label=serve :11370

It is about 6..8 hundred items for each reconciliation during 2 days now. I suspect it means that reconciliation never completes? I thought it should eventually end up syncing several (dosens) keys at a time.

http://sks.eq.by:11371/pks/lookup?op=stats

says that the total number of keys corresponds to average number of keys on other nodes:

https://sks-keyservers.net/status/


Thanks,

Viktar

[Casey Marshall]

It's likely that the server that hockeypuck is syncing with, is interpreting the key material differently. Hockeypuck does some validation and cleanup on packets, filters out invalid ones, etc. This can unfortunately cause the hashes to differ and never reconcile; Hockeypuck discovers hashes it doesn't have over recon, but then never confirms those hashes when it receives the keys for them.

One way I considered improving this would be to have a "max attempts" counter on a given key hash per peer. If the peer keeps sending a weird key, ignore it -- and possibly add the peer's hash it to the ptree so it doesn't cause the same problem on the peer's side. I don't currently have time to implement this, but I'd be happy to review such an improvement and give some pointers on its implementation.

Best,

Casey

--
You received this message because you are subscribed to the Google Groups "hockeypuck-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hockeypuck-dev...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.