Agreed.
Iād add though that the spend/payment/wallet bugs are critically important to fix with priority because you can expect people to convert from Maid to autonomy token in October when the wallet can get corrupted and lose all funds or people will lose money even if payment doesnāt go through.
Itās a question of strategy and hiring the appropriate resources for the chosen strategy. I hope that makes sense. Iāve avoided commenting on the strategy months ago so Iāll keep trying to do that. I personally still believe that there was likely a much simpler path, like not doing these maidsafe-managed leaderboards in the first place. And if you must have a leaderboard, how about having participants voluntarily send in their earnings to be counted towards beta rewards. That wouldāve avoided, e.g., spending so much time on earnings being forwarded and the issues that created to be constantly wrangled with for correct tabulations, etc. But like I said, it doesnāt matter as long as the network can get finally launched. But it seems now that these things are actually getting in the way of getting to launch.
It leads to NAT-keep alive traffic (such as NAT punching, NAT traversal mechanisms etc) on end-usersā local network as well as on the CGNAT device itself.
Which in theory could affect battery life on end-user devices.
Increased link utilisation/CPU cycles on the CGNAT device.
Some end-user applications will simply refuse to work or fail miserably like Xbox Networking (P2P Gaming services), Torrent clients etc.
If you have a valid reason and need to opt-out of CGNAT you can call our technical support staff
āIām running 500 nodes with 500 peersāā¦is not going to cut itā¦
Static IP:
So we rent an IPv4 address for AUD$5 @ month which results in us bypassing the CGNAT infrastructure. Because Iām on FTTC, the protocol dictates DHCP for the WAN portā¦so no action required by the customer.
The clincher:
I could never get port forwarding to workā¦I was a reluctant --home-network runner
No longer! I now get moar chunks and a healthy peer listā¦but hereās the kickerā¦
I have NO Port Forwarding rules set on the router
NO --home-network
NO --upnp
I do specify udp port ranges, which is probably best practice.
Internet performance is also improved
The node machines Ethernet graph appears more āburstyā
Summary
I donāt know how this is working without port forwarding, but could be a big plus for network/ router performance if we can get most node runners on Static IP.
Iām sure it would benefit ISPās to have node runners bypass CGNAT alsoā¦at scale it has to affect their other customers.
I wonder if Digital Ocean have similar NAT config that impacts performance.
Iirc @neo explained to me that the client pays the node that stores the chunk directlyā¦ So it establishes a connection to your node from outside, sends you the nanos and tells your node the receive string to executeā¦ That mechanism simply canāt work without port forwarding
Tbh it sounds to me a bit glued together if payments take a different (shortcut) route than all other dataā¦but that might be a wrong impression based on missing knowledge
Would be interesting to see a metric exposed by the node ālost paymentsā
ā¦ And I wonder how the network would know a chunk has been paid for if the spend is not registered in the system and redeemable by the node that (should have) received the payment
Shouldnāt a wallet Re-sync from the network bring the balance ā¦? Since I donāt really see a chance to create a valid send without registering it at the DAG?
@chrisfostertv Yes when I forgot to open ports on my firewall the nodes would all work fine and keep going. BUT no quotes done and no earnings. When i remembered to open the ports in the firewall earnings were not far behind.
With 500 nodes you should see earnings within hours. So if rank shows nothing in 5 hours then its unlikely to ever earn.
EXPLANATION - hopefully the explanations for a single node run on PC makes sense
When starting the node reads the peers file supplied by Maidsafe and then it sends packets to to all those peers to find a few things (more peers to contact, how far away each peer is in xor space)
The packets travel through the router
the router makes note of the return port and the remote IP address and stores it in its NAT table
then the router sends the packet through the WAN
when the peer replies it comes in on the WAN port
the router inspects the header and sees that the IP address matches one of the NAT table entries, and then checks the destination port number and sees that the PC used that port
then the router sends the packet to your PC
this is normal operations for all routers. Its how responses from web sites get back through your router to your browser. Also by using the table the return packets get sent off to the right PCs on your local network
this is repeated across all the peers the node has traffic with.
It is the reason you get churning chunks and the peers can obtain chunks from the node
BUT when a client wants a quote and send a chunk this happens
client asks peers it connects to for the nodes closest to the chunk it wants to upload
when it tracks down your nodeās ID it sends a request for quote packet to your node
your router receives the packet from the WAN port
It inspects the header and does not see an entry in the NAT table corresponding to the clientās IP address and the destination port
And the router just drops the packet.
Your node does not get any indication that the client tried to get to it
This means clients cannot contact you
Now how do we get the router to let in these unsolicited packets from clients???
This is where port forwarding comes in.
the packet from the client comes in and the router sees the destination port number matches the port forwarding rule and so it sends the packet to the PC specified in the port forwarding rule
--upnp allows routers to temporarily do port-forwarding if an application tells the router.
--home-network uses relay nodes to have another node that has ports open to act as an intermediary to setup the connection so the router can set it into its NAT table.
I just note that I use bridge mode, which opens one port of the operatorās router to a certain computer, and all other ports and wifi are separated in a separate network with a separate IP. I also donāt forward ports on the router, just point the ports in the node manager.
Not sure of what router you use but usually bridge mode means there is only one IP address to use and you either connect another router to it or have just one device talking to the bridged router. IE direct connect to internet and the device has the public IP address as its IP address
Have you more than one public IP address for that internet connection?
Yes, there are 2 real static IPs. One for the bridged device and second for the router itself.
There is another internet provider that gives 5 real IPs to 1 router as each port has a separate IP, in a week I will be able to test his service to see how it will behave with the nodes.
Excellent update, many thanks to the team, moderators and community for the relentless pace of development!
I understand that if you are using Safenode Manager for Windows, you need to download and install the specified update file from Git-hub?
I have been testing the hardware and Internet connection for some time now, sequentially eliminating any potential problems with earning, because I noticed that I happen to disconnect my computer from the network. @happybeing have you experienced any noticeable problems with your mobile broadband Internet connection that make it difficult for nodes to connect to Autonomiās network?
Iām using LTE+ and reported the problem to Orange, they stated initially that my location indicates network congestion, Iām wondering if anyone else has had this problem and if it could affect the lack of earnings?
I turned on 5 nodes tonight and within 6 hours the transfer was about 15 GB, which means that if the nodes worked all the time, in a month the transfer would be 1.8 TB of data, and Iām still not getting any nanos. After the latest update, has anyone noticed a noticeable change in earning?
Iāve not been running nodes over mobile b/b although I was intending to, Iāve just been too busy working around issues with my app, which in the end the out not to be related to my connection.
The new update, at least through vdash, seems to be working great except for nanos on my nodes from home.
Everything looks great, even, steady.
I only have 15 nodes, but I get thousands of records, equal store cost, average ram usage. Peers are what they should be too. And, drumroll please, just a hand full of shuns.
This is the first time, since the update, my home nodes have not had like 50 shuns each.
The max is 4 shuns after a whole week.
All of this data tells me the updated nodes are working very well from home. Just no nanos for the first time ever. I have never failed to earn nanos until now. Beta is fun.
More nodes than one allows people to have more than the 2GB of storage to offer the network
The 2GB size maybe increased to 8GB or 16GB, but its a fixed maximum size to allow a fixed number of records to be stored. The close node mechanism relies on each node to be a fixed maximum number of records.