[Issue #50] Uptime Rework

[Hiroshi97]

Resolve #50

[Hiroshi97]

@2ndtlmining Currently I put Not Active for the non-data Node. What is your final decision for that case?

[2ndtlmining]

Morning @Hiroshi97

Great looks fantastic, Look at some of that uptime is amazing. Tested with one or two and the details when it populates looks believeable to me :)

Now for the "Not Active" i think we are missing out on the actual data. If there are benchmarks and apps on it, we really should be getting some data back. Testing it this morning i suspect where we are missing the information is on the IP's that doesnt have UPnP on. Not sure if the below is the most optimized way to deal with it.

Thinking before we set the "Not Active" flag can we just hit the API without the Port to see if we get a value back?

If i look at this guy:

Wallet: t1aJfELWenuTpeNZGLCqfJc1s5pARs8RGsz

I could get the API data back for all of the IP's .

Looking at that, might be easier to just do wallet and pull uptime column from there matching it to the IP? Or am i smoking my socks :)

[Hiroshi97]

@2ndtlmining I've updated the code, please take a look at it to see if it is matching your desire

[2ndtlmining]

Morning @Hiroshi97

Great news, had a quick play and spot check this morning. The non-UPnP nodes working perfectly. Calculation is spot on also:

They check out perfectly.

The only thing i did pickup is that only some UPnP addresses is not working as expected. Here is a working UPnP:

What is nice its both calculating in the same screen. Looking at the calc suspects its incorrect :

Looking at that think should be like 1 day.

http://109.193.114.57:16136/daemon/fluxnode/getnodestatus

But big wallets that has a large mix like this: t1K5txxB6GLmWezHeUANzVVGi8KjLmuvFyH Looks to be calculating nicely.

Just this one thats bit strange: t1XYUvMAghQv5WNjUpZo6iVezMPPtEDQrR1

Looks to be active for a handful of days. Really so close. I will have a look at the code today to see if i spot something, but i suspect whats happening its picking in some cases the 1st value and giving that to the list and not matching IP to the API json index. Purely theory but if i look at this one:

t1Rj4e54vNH8uNJtwaTq5heYNHYC8KbFiq7

Looks to be calculating the correct date based on the 1st node which is 60 days spot on:

http://109.193.114.57:16126/daemon/fluxnode/getnodestatus

But because that IP range is within the same json list dont think it matches the port correctly and as such just returns the 1st value. Like this:

But not sure why is working in some and not in others :) Hopefully makes sense?

[Hiroshi97]

I've changed the condition to get the node with corresponding port. Could you double-check?

[2ndtlmining]

Morning @Hiroshi97

Short summary:

1. Wallet with 0 UpNP = Works perfect: t1aJfELWenuTpeNZGLCqfJc1s5pARs8RGsz
2. Wallet with UPNP + without UPNP = Only the non-UPnP works correctly: t1XYUvMAghQv5WNjUpZo6iVezMPPtEDQrR1
3. Small wallets with 1 UPNP and 1 non-UPNP using same ip range = Not working correctly, duplicates nonUPNP date: t1Rj4e54vNH8uNJtwaTq5heYNHYC8KbFiq7

Thanks again for looking into it. I had a test with: t1XYUvMAghQv5WNjUpZo6iVezMPPtEDQrR1

Think the UPnP ports still coming through as not active, where i think they should be coming through. If i pick the one UPnP node within that wallet as example. Coming up as not active, but if i look at the end user data:

http://176.9.54.136:16186/daemon/fluxnode/getnodestatus

It has a Active since date, and then using the API with this wallet:

https://api.runonflux.io/daemon/viewdeterministiczelnodelist?filter=t1XYUvMAghQv5WNjUpZo6iVezMPPtEDQrR1

Can see there is an Active since value for that specific IP. Suspect could be how we search through this list? I havent looked into the logic with a lot of detail, but what i was thinking is we will get the list of nodes attached to a wallet as per normal, from that list we get the node IP's (with and without UPNP), we then hit the new API (https://api.runonflux.io/daemon/viewdeterministiczelnodelist?filter=) with the wallet provided, and then try to match the node API with the json to retreive the Active since value, but not sure how Js goes through these lists and matches :) Especially if it has the same ip range :) Btw if Js cant do that type of search happy to leave it and work on something later ?

[Hiroshi97]

@2ndtlmining Because the flux nodes that we are fetching and adding to the Nodes Overview only have at most 2 ports and I'm not sure the ports are the same as the ones in the API response. I think the viewdeterministiczelnodelist API is unstable atm. In your screenshots, are the ones you highlighted as same as the display IP + port on the Nodes Overview?

[2ndtlmining]

Morning @Hiroshi97

Thanks coming back. Think i am getting what you are asking. Cant remember what data we use to formulate the list of IP's to start our Node overview selection. But if i have a look at a fairly simple home upnp wallet:t1Q8mx9spcYv1HYKCECdDZe4KDkALZm75NA

In our selection today:

109.30.23.72 109.30.23.72:16177 109.30.23.72:16137 109.30.23.72:16157 109.30.23.72:16187 109.30.23.72:16147 109.30.23.72:16167

If i use the view deterministic API on that wallet

Think we getting the exact same list with the IP's. I might be very wrong, but was thinking we already using the API to pull the Rank number for the nodes thus we already matching them to get the correct data.

But saying that if its inconsistent rather not use it and happy to park it for now can come back later to have a look.

[Hiroshi97]

@2ndtlmining If these ports are the same, then I think the mapping is correct. The API view deterministic API is toggled by the env but since the rank is not correct so we are not going to use it atm. We still used the old API for Nodes Overview.

[2ndtlmining]

Morning @Hiroshi97

Thanks a lot for looking at it. Cool understand now, i remember we used an API with dodgy (think it was more an index) rank just thought this one was the right one as the data seemed to line up, but looking at it a bit closer seems to be off by 1 or two blocks against what we have today:

Not the end of the world, super happy we tried at least, but int he end if we cant really get the correct data back and mapped the the correct IP, might be better of leaving it for now. The only other option would be to make use of the stats api:

https://stats.runonflux.io/fluxinfo?projection=flux,node

But that will be slow as it has got all the nodes details and we probably end up same place, where i think the ip:port (UPnP) is where we run into issues.

Happy to let this one go for now, we can tackle it may be again in the future. Dont want you to spend too much time on it :)