Hook up neighbors screen to new api from Michal

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 @ttk2 about which one it is.

@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.

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

1 Like

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.

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.

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?

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.

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

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

Once again expected because no payments. That was ā€˜finishedā€™ but never really rolled out. So nothing is ever incoming.

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