Page 1 of 1

what mean is "jump"?How did that do?

PostPosted: Fri Dec 02, 2016 7:01 am
by csquan_2015
in rippled source code,I can fnd "jump...",what that mean,how did it work?

Re: what mean is "jump"?How did that do?

PostPosted: Sun Dec 04, 2016 8:13 pm
by JoelKatz
A "jump" is when the server switches which ledger it considers to be the last closed ledger by a process other than consensus. When the server is first starting up, it may need to jump several times until it gets in sync with the network. If it loses sync, it will usually need to jump its ledger to get back in sync.

We have some servers that lose sync on average once every 20,000 ledgers and some that lose sync on average once every 4,000 ledgers. Loss of sync is most commonly caused by some momentary loss of performance, typically a bubble of network, I/O, or CPU latency.

Re: what mean is "jump"?How did that do?

PostPosted: Thu May 04, 2017 10:23 am
by csquan_2015
suppose there are several nodes,A-G,ABC connected to each other and form a ripple network.DEFG connected to each other and form another ripple network.two network were seperate.
in some case,two network connected ,what will happen?

Re: what mean is "jump"?How did that do?

PostPosted: Thu May 04, 2017 4:46 pm
by JoelKatz
csquan_2015 wrote:suppose there are several nodes,A-G,ABC connected to each other and form a ripple network.DEFG connected to each other and form another ripple network.two network were seperate.
in some case,two network connected ,what will happen?

Assuming the two sides are on different ledgers, the network will avalanche to a single ledger that has the last fully-validated ledger in its history.

Re: what mean is "jump"?How did that do?

PostPosted: Fri May 05, 2017 2:52 am
by csquan_2015
Assuming the two sides are on different ledgers, the network will avalanche to a single ledger that has the last fully-validated ledger in its history.

last fully-validated ledger in its history.which sides?
how to decide ledger in which side?base what?

Re: what mean is "jump"?How did that do?

PostPosted: Fri May 05, 2017 10:38 am
by JoelKatz
csquan_2015 wrote:
Assuming the two sides are on different ledgers, the network will avalanche to a single ledger that has the last fully-validated ledger in its history.

last fully-validated ledger in its history.which sides?
how to decide ledger in which side?base what?

There will be a last fully-validated ledger on each side. If those are different, then:
1) If they have the same sequence number, the network has forked and broken.
2) If the one with the higher sequence number does not have the one with the lower sequence number in its history, the network has forked and broken.
3) Otherwise, the one with the higher sequence will be avalanched to.

Cases 1 and 2 are nearly impossible (so improbable we don't have to worry about them) unless the network UNL topology is badly defective.

We can actually improve this to make it even less likely by considering, for fork protection purposes, a ledger that's "nearly fully validated" as if it was fully validated. There can only be one such ledger on the network at a time, because it would still require significantly more than 50% validation. But this would protect against the (almost impossible) case where a ledger is seen by a large number of validators as very nearly fully validated right at the time the network splits.

We're continuing the simulate the behavior of consensus to understand these cases better to ensure we can stay far, far away from the zones in which these problems can happen. Our technique is to take a healthy network and stress it with network splits and delays. Then we start making the network less and less healthy (primarily by reducing UNL overlap). Then we test to see at what point we can actually get a fork and, more importantly, what the early signs are of a deficient topology long before it forks. (So we can look for those on the live network.)