Tried to run it at work, but being blocked it seems. I updated the IP so that shouldn’t be the problem:
nullINFO 06:53:46.936122900 [client client.rs:1202] Our public ID: 1bfb7c…
INFO 06:53:46.936122900 [client client.rs:1204] Attempting bootstrap…
ERROR 06:53:56.948829000 [client client.rs:1216]
Could not connect with the proxy.
This probably means that your IP address is not registered. Please follow this link for registration: https://crusttest.maidsafe.net/auth.html
If you have registered your IP address and still getting this error it could mean the proxy is down or not reachable. Please contact us and provide the log file.
Press Enter to continue…
As for the dashboard, it always fails to get the initial data.
Yes it will, you can add your friends bootstrap cache, or IP:PORT combinations as well though. So hard coded is a simple initial bootstrap. There are other ways, like local beacon, shared lists and so on. The initial contacts though are just easy, like bitcoin/torrent network etc. its a thing that always needs looked at and improved.
Your router NAT/firewall should protect you anyway from unsolicited incoming connections. So unless you are a public facing IP you can try the most permissive: iptables --policy INPUT ACCEPT. Keeping OUTPUT to a default policy of accept is also fine unless you suspect there’s something bad in you machine which makes you uncomfortable to do it but at that point you probably have bigger problems. I personally heavily handcraft my INPUT according to my needs but my OUTPUT is always defaulting to accept.
If you are uncomfortable with ACCEPT as a default policy for INPUT (if you have a static IP or your router for some reason has no firewall - tbh IDK if you get one like that and who would use it) then you can set it to REJECT but then have it set to ACCEPT the established and related ones at-least (means that it will accept if it found out there was a prior outgoing). iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT or something like that (haven’t checked if the syntax is right but should be close to correct anyway)
Answering both questions here: I’d say the total percentage of successful connections as a whole is not even as important as its consitutuent parts.
The breakdown on TCP and UDP holepunching results, the availability of UPnP, and success rate of direct connections tell us a bit more interesting story, and from this point of view the results were very valuable for us. With this data we’ll have answers to some of our questions, like e.g how useful is UDP hole punching, how many users will need tunelling, and so forth.
And the current total number of 75% successful connections is a great starting point for sure.
That’s correct. It’s a pure Crust test, without any ties to the SAFE Network (which is also a good thing, showing that Crust can work as an independent module and serve its function for other P2P applications and networks).
It’s possible to cover the other 24-25% by tunneling (i.e. effectively redirecting traffic through other nodes), so yes, 75% is a good figure. But also remember that it’s only a requirement for node-to-node connections: a percentage of working clients will be closer to 99%, i.e. as long as the regular TCP connections and the current Web work for you, you should be able to use SAFEr networks.
No mystery here It’s a reference to the line and a column number in the source code of the client app. It helps us to debug and see where exactly this failure occurs – in this case it’s line 309 here. The ‘panic’ there means that because we were not able to obtain any public connection info, we termianate the running program.
Just a message from the Rust compiler that’s displayed in case of a failure. It helps to debug a problem further by displaying a stack trace, but if it is a known error (as in this case), it wouldn’t help you much.
Still, it’s a mystery that my IP keeps changing… I wonder if those running nodes in future will want to have static IPs… or if there will be some form of persistent UID that can handle IPs as a property of the nodes identity and then not keep defaulting to zero kudos.
(off topic: I’m wondering why the forum insists on replacing double dots with triple dots … double dots is continuity of thought and triple dots looks … odd (and six replaced with three too)… / … ha!)
Is a node that requires tunneling worth having, given it is now a burden on the nodes it’s tunneling to, increasing their bandwidth usage, presumably without compensating them with any SAFEcoins it earns?
Even if the math says we would rather have a node that requires tunneling than not have the node at all, it seems like an effort should be made to make that a last resort, by having a config file that defaulted to “NO_TUNNEL” and a bunch of resources telling people what routers to buy, any router configurations they can try, etc., to try to make the tunneler population as small as possible.
Can we look at Bittorrent’s P2P success, with presumably no tunneling, as an indicator that perhaps people can generally get things working if they are forced to futz with it until it works?
A network boost of 30% surely must be a useful resource. Is there an assumption that all nodes will be equals?.. more natural, would be some solution that sees each play their strengths to the max… and fair reward for the contribution they make.
I suppose it is, but I don’t know. What is most valuable, hard drive space or bandwidth? Probably hard drive space, but for many of us, residential internet upload bandwidth is precious. We don’t have symmetrical bandwidth, with upload bandwidth being greatly reduced compared to download bandwidth.
Also, it won’t be 30% increase if I force them to futz with their configuration, I might get 10% or more of them on the network without resorting to tunneling.
My petrichor node is at 100% so far, that’s great!
Just a reality check: would testing with the various AirVPN exit points I have available help expand the test at all? I am assuming they are all using identical or very similar configurations, so… But if it would, I can do it!
P.S.: Yet again am I very saddened by the fact my country is called Czecha now
Surely, it’s not an either or. The network is the sum of contributions. How it finds its balance, acknowledges; welcomes; and makes use of all that is not truly a drain on the performance, will perhaps necessarily follow from testing and then an iterative load balancing that’s dynamic and responsive. I wonder that a simple reward for bandwidth or for hard drive, might force the kind of resource provided… and that might be ok if the devs know what is truly key to performance… perhaps hard drive space dominates and bandwidth follows, since the base is to ensure copies exist. Still, it would be nice to reward all contributions made… a welcoming environment for all, rather than some survival of only the ‘fittest’.
Ha - nice! (effectively one hop more then for that farmer so a competition disadvantage but still super awesome that it doesn’t prevent consensus to be found )
Just thought I’d let you know that we’re going to be stopping the Crust test today around lunchtime (UK time). If you haven’t already had a chance to participate (where have you been?) then you’ve only got a couple of hours to go now.
You can see the current results on the dashboard. Note that the dashboard will be unavailable after the test concludes.
I’ll take this opportunity to thank everyone who’s got involved - we’ve really appreciated it.
I had actually considered that then thought I’d go with the more minimal approach then it seemed too sparse so I popped the sign image in there.
Two imaginary votes to zero imaginary votes - I’ll update!
David.
Edit: @TylerAbeoJordan - I’ve updated the post. You’ll note that I’ve not namechecked you there… that’s because I think you’d probably get sick of all the groupies that would be assembling outside your house chanting your name and wanting autographs. It’s nice at the start but gets tiresome - you should see the throng of people I have to fight through just to get into the office in the mornings.
It’s a reference to the line and a column number in the source code of the client app. It helps us to debug and see where exactly this failure occurs – in this case 
