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

Technical questions about the Ripple API, the protocol, etc.
Google [Bot] like(s) this thread.

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

Postby csquan_2015 » Fri Dec 02, 2016 7:01 am

in rippled source code,I can fnd "jump...",what that mean,how did it work?
csquan_2015
 
Posts: 140
Joined: Tue May 24, 2016 10:10 am

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

Postby JoelKatz » Sun Dec 04, 2016 8:13 pm

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.
User avatar
JoelKatz
Ripple
Ripple
 
Posts: 1859
Joined: Sun Dec 23, 2012 3:45 pm
Location: Oakland, CA

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

Postby csquan_2015 » Thu May 04, 2017 10:23 am

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?
csquan_2015
 
Posts: 140
Joined: Tue May 24, 2016 10:10 am

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

Postby JoelKatz » Thu May 04, 2017 4:46 pm

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.
User avatar
JoelKatz
Ripple
Ripple
 
Posts: 1859
Joined: Sun Dec 23, 2012 3:45 pm
Location: Oakland, CA

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

Postby csquan_2015 » Fri May 05, 2017 2:52 am

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?
csquan_2015
 
Posts: 140
Joined: Tue May 24, 2016 10:10 am

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

Postby JoelKatz » Fri May 05, 2017 10:38 am

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.)
User avatar
JoelKatz
Ripple
Ripple
 
Posts: 1859
Joined: Sun Dec 23, 2012 3:45 pm
Location: Oakland, CA


Return to Developers

Who is online

Users browsing this forum: No registered users and 9 guests
cron