ReconRqstPoly issues with SKS

Bug #1203624 reported by Casey Marshall on 2013-07-22
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Casey Marshall

Bug Description

When the key database grows large enough for ReconRqstPoly, I'm noticing some backwards behavior -- Hockeypuck is requesting the keys that the SKS peer doesn't have -- from itself.

Something seems backwards here...

Casey Marshall (cmars) wrote :

Latest suspect is a defect in the leveldb ptree implementation. Let's just use a real database (postgres).

Casey Marshall (cmars) wrote :

Need to confirm fixed/invalid by reconciling two Hockeypucks.

Casey Marshall (cmars) on 2013-08-13
Changed in hockeypuck:
status: Triaged → Fix Committed
Casey Marshall (cmars) wrote :

Reproduced this issue by recreating a ReconRqstPoly scenario, between SKS and Hockeypuck, Hockeypuck did not converge. However, Hockeypuck *did* converge a poly sync with another Hockeypuck.

Turned out to be a difference between the conflux byte ordering of Zp's and SKS ZZp. This difference crept into other parts of conflux, where byte strings were reversed to match some of my blackbox SKS examples.

Matching the conflux Zp and untangling the compensation mess fixed the issue, and greatly simplified the code and usage. Demonstrated convergence between Hockeypuck and SKS in a poly scenario.

This is what a convergent poly reconcile looks like in Hockeypuck's log:

hockeypuck2013/08/12 23:36:11 gossip.go:214: gossip: Reconcile [1 1 1 1 1 1] [0 530512889551602322505127520352579437338 1 530512889551602322505127520352579437337 2 530512889551602322505127520352579437336] 0
hockeypuck2013/08/12 23:36:11 gossip.go:205: gossip: solved: localSet= {} remote Set= {}

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers