Hook up neighbors screen to new api from Michal

[Jehan]

The neighbors screen has some little dollar amounts which can be hooked up to one of the pieces of data in the new debts endpoint. Brainstorm with @jkilpatr about which one it is.

[jkilpatr]

@Adam_Soltys ok added some fixes for displaying a perfect route when we couldnt connect at all. Also the values should be normalized, even when things ‘work’ it shows a very bad connection where it’s actually ok.

In general I suggest removing ‘connection to internet’ and replacing it with ‘connection to exit’ and finding some way to identify exits and not display that part for them. Generally anyone who provides no route to the exit (u16 max route quality which means infinitely bad) is an exit. I don’t think we actually have a better way to tell beyond asking the configured exits page, even the manual peers bit isn’t quite correct.

[Adam_Soltys]

Started working on this here: https://github.com/asoltys/althea-dash/tree/debts-endpoint

[Adam_Soltys]

I’m thinking it might be nice to display the price per GB that each neighbor is currently charging. Would it make sense to add that to the debts endpoint? Also, how do y’all feel about continually polling the /debts endpoint here so that the numbers are updated in real time as bandwidth is used up without having to refresh the page.

[Adam_Soltys]

It might also be nice to display the total up/down bandwidth in GB for each neighbor and perhaps allow users to see a graph of their bandwidth usage and billing data over various time ranges.

[Jehan]

There is no reason to display exits on the neighbors screen. They are not neighbors, even though we break that abstraction in our underlying implementation. Please filter exits out of the neighbors screen. Ttk2- opinions?

[Adam_Soltys]

I’ve implemented polling now so the front end is updated with new numbers from the /debts and /neighbors endpoints every 10 seconds. Now I have some questions and observations.

My current setup that I’m testing with consists of an edgerouter X gateway plugged into my ISP modem, an n750 downstream from that, and a glb1300 downstream from the n750.

ISP -> erx (gateway) -> n750 -> glb1300

So far I’ve been looking at the Neighbors page from the perspective of the n750. It has 1 neighbor upstream of it, the erx gateway, and one neighbor downstream, the glb1300.

I’ve come to understand that debts between neighbors are settled every 5 seconds as they reach their payment thresholds. I’ve noticed that from the perspective of the n750, however, that the glb1300 downstream of it is accumulating an ever-increasing debt and doesn’t ever seem to be making payments to settle it. Its debt starts at 0 when the modem boots up and just continues to grow as time goes on.

On the other hand, I can see that the exit node I’ve selected, borked, has a debt value that does seem to get settled and reset to 0 continuously. It will jump up to say 96000 or 140000 and then go back to 0 repeatedly depending on when I happen to randomly hit the endpoint.

I’ve noticed that the “total_payment_received” value for all the n750’s neighbors is always zero. I would have expected the n750 to be receiving payments from the glb1300 and have that number steadily increasing but as mentioned before it seems to not be making payments and is just accumulating debt forever. The “incoming_payments” field is also always zero for all neighbors. I’m not clear yet on the significance of that field and whether or how it should be displayed to the end user.

The “total_payment_sent” value is increasing for both the edgerouter X gateway and the exit. I assumed that the n750 would only be sending payments to the gateway, which would be charging enough to cover its own fee plus the exit’s fee and then making its own payments to the exit as it forwards on traffic from the n750 so it surprises me to see the n750 paying the exit directly as well.

The existing Neighbors page code was reporting “currentDebt” (now just “debt”) with units of cents/GB. However, if the debt is being constantly settled back to zero then I don’t think it makes sense to use the number that way. If we want to determine and report a rate of payment, I think we would need to look at the average difference between successive values of total_payment_sent or total_payment_received over time.

Anyways just wanted to get some of this written down and thrown out there for now. I plan to investigate all these payments numbers a bit more by digging into the backend code and looking at how they change when I’m looking at them from the perspective of the gateway and the glb1300.

[jkilpatr]

@Adam_Soltys

I’ve come to understand that debts between neighbors are settled every 5 seconds as they reach their payment thresholds. I’ve noticed that from the perspective of the n750, however, that the glb1300 downstream of it is accumulating an ever-increasing debt and doesn’t ever seem to be making payments to settle it. Its debt starts at 0 when the modem boots up and just continues to grow as time goes on.

Yes, right now there are no payments, so no debt is settled.

@Adam_Soltys

On the other hand, I can see that the exit node I’ve selected, borked, has a debt value that does seem to get settled and reset to 0 continuously. It will jump up to say 96000 or 140000 and then go back to 0 repeatedly depending on when I happen to randomly hit the endpoint.

Ok that’s odd, I’ll look into exit debt later, it’s managed by a different system since it’s computed differently.

@Adam_Soltys

I’ve noticed that the “total_payment_received” value for all the n750’s neighbors is always zero. I would have expected the n750 to be receiving payments from the glb1300 and have that number steadily increasing but as mentioned before it seems to not be making payments and is just accumulating debt forever. The “incoming_payments” field is also always zero for all neighbors. I’m not clear yet on the significance of that field and whether or how it should be displayed to the end user.

Once again expected because no payments. That was ‘finished’ but never really rolled out. So nothing is ever incoming.

@Adam_Soltys

The existing Neighbors page code was reporting “currentDebt” (now just “debt”) with units of cents/GB. However, if the debt is being constantly settled back to zero then I don’t think it makes sense to use the number that way. If we want to determine and report a rate of payment, I think we would need to look at the average difference between successive values of total_payment_sent or total_payment_received over time.

now this is wrong, debt is in units of wei (1*10^-18 eth) and should be displayed accordingly.