Fleming Testnet v1 Release - *NOW OFFLINE IN PREPARATION FOR TESTNET V2*

[drehb]

@neo

Does the node continue to retry to join or is it a try once only and need to rerun the command?

Fleming Testnet Stupid Question Thread

According to the documentation, this is what you get if the network currently has enough space and is rejecting new nodes, so all is good on your end. This from @wydileie is currently the best available join command, attempting to join as a node every x seconds until it works: until grep -q "Handling NodeDuty" ~/.safe/node/local-node/sn_node.log; do safe node join; sleep 30; done

[davidpbrown]

@neo

a try once only and need to rerun the command

above suggested yes - could do with suggested halted or node stopped in the log to make this more obvious.

[Dwieluns2]

Could you provide a link to the user guide?

[neo]

@Fleming Testnet Stupid Question Thread

According to the documentation, this is what you get if the network currently has enough space and is rejecting new nodes, so all is good on your end.

Thanks. First time I had UPnP turned off, and assumed the error was due to that. Then turned it on and got same error, so I read the info in the OP. That is why I questioned it.

And thanks for letting me know its a one attempt at joining. That shell loop is something I was thinking of doing. Although I was thinking of a while loop. Until is prob better.

[Sascha]

sascha@sascha-Librem-15-v3:~$ until grep -q "Handling NodeDuty" ~/.safe/node/local-node/sn_node.log; do safe node join; sleep 30; done

Joining network with contacts {138.68.154.164:44520, 138.68.142.76:38701, 46.101.1.135:58214, 188.166.146.65:36220, 138.68.139.28:40613, 138.68.142.144:55064, 138.68.141.132:36390, 46.101.48.69:55130, 138.68.146.110:58306, 138.68.152.156:51182, 188.166.146.115:41339, 138.68.139.58:38972, 46.101.55.62:53141, 46.101.78.184:41244, 138.68.131.228:40591, 138.68.139.187:33546, 138.68.138.179:51519, 138.68.138.75:59177, 138.68.131.119:50694, 139.59.181.74:12000, 178.62.80.163:57378, 138.68.154.35:49429, 46.101.17.63:38981, 188.166.169.192:47334, 138.68.137.76:34625, 178.62.101.46:59428, 138.68.137.198:43750, 138.68.133.17:37599, 138.68.146.15:34651, 178.62.58.241:42766, 46.101.72.229:52737, 46.101.93.86:56133, 138.68.131.218:57691} ...
Storing nodes' generated data at /home/sascha/.safe/node/local-node
Starting a node to join a Safe network...
Launching with node executable from: /home/sascha/.safe/node/sn_node
Version: sn_node 0.35.1
Using RUST_LOG 'sn_node=debug'
Node to be started with contact(s): ["138.68.154.164:44520","138.68.142.76:38701","46.101.1.135:58214","188.166.146.65:36220","138.68.139.28:40613","138.68.142.144:55064","138.68.141.132:36390","46.101.48.69:55130","138.68.146.110:58306","138.68.152.156:51182","188.166.146.115:41339","138.68.139.58:38972","46.101.55.62:53141","46.101.78.184:41244","138.68.131.228:40591","138.68.139.187:33546","138.68.138.179:51519","138.68.138.75:59177","138.68.131.119:50694","139.59.181.74:12000","178.62.80.163:57378","138.68.154.35:49429","46.101.17.63:38981","188.166.169.192:47334","138.68.137.76:34625","178.62.101.46:59428","138.68.137.198:43750","138.68.133.17:37599","138.68.146.15:34651","178.62.58.241:42766","46.101.72.229:52737","46.101.93.86:56133","138.68.131.218:57691"]
Launching node...
Node logs are being stored at: /home/sascha/.safe/node/local-node/sn_node.log

[Teknick]

I have been silently watching this project for a few years now, but I want to say well done all. This is very exciting and I will have a go at setting up a node at the weekend. Rather exciting to watch

[dirvine]

@tfa

opening a single port number in the firewall

Do you mean port forwarding here? (i.e. nodes need incoming connections to be able to work, otherwise they will fail)

@tfa

• dedicating the same port number for all my nodes (in the past maidsafe used to use 5483)

Yes, this is a wee bit dangerous really. It allows traffic snoopers to find Safe nodes a bit easier, if they are random then it helps us hide a wee bit more. This one may also suffer linger and port reuse issues in the OS.

5483 though was a fallback, find me port, not really meant for general use, but used as a way to reconnect nodes on total loss? (i.e. fine any of these ports on a network to try connector as Safe nodes). 5483 was LIVE in the telephone keypad (it was my joke for the network wants to live )

[dirvine]

@neo

That shell loop is something I was thinking of doing.

That requirement won’t exist in next iter. Nodes will join a queue, stay connected and be selected at random (based on the hash of the lost or full node message, so ungamable)

[Michael_Hills]

@Traktion

The network has tested a pile of stuff and much like Elon’s recent rockets, it still needs work. Let’s judge on the successes and give the team time to work on the failures, that’s all I’m suggesting.

I agree, the difference being the test net has yet to fully crash, in fact, it is still flying. This was never a speed test, it was a test to see whether it would fly. Its flying, It worked. Its stable. It will fly higher soon, much higher. The hard part is over, the team has given it wings.

Yes, we need to test it, be critical, try hard to break it, and I thank the community for that, but let us rejoice for now! It worked!

Also I found the easiest way to join the test-net was to download the CLI binary from github, for those having issues with terminal on MAC OS, cheers. Great work team!

[tfa]

@dirvine

@tfa

opening a single port number in the firewall

Do you mean port forwarding here? (i.e. nodes need incoming connections to be able to work, otherwise they will fail)

No, I really meant open a port in firewall, for example ufw allow 5483/udp with ufw.

[dirvine]

@tfa

for example ufw allow 5483/udp

Oh I see in your local firewall on your local computer? That makes more sense and yea a valid use case I would say.

[dask]

@Michael_Hills

agree, the difference being the test net has yet to fully crash, in fact, it is still flying

I’ll go right out there and say that starting an account and writing data to the network and transferring tokens on my first try is a huge win. The software just works (as far as setup), and that is not a small feat for a distributed network.

[happybeing]

@dirvine

Nodes will join a queue, stay connected and be selected at random (based on the hash of the lost or full node message, so ungamable

This requires storage of the queue, and updating it if nodes go away, and handling if it gets too big. Might it be prone to spamming in order you get more nodes in the queue that someone else? I guess repeated join requests (with no queue) are also open to this kind of attack.

A way to limit this effect might be to have more do some work for each join attempt, but that work needs to be something that can’t be done faster with more CPU, maybe something more like you have to route N messages before you get to join.

I guess you’ve been around these houses a few times already, but I’m not saying how a queue works unless it is off limited length and nodes are doing something useful and measurable in order to remain in the queue. Even then, you get the issue of the queue itself being spammed with join-the-queue requests, just like the network so I’m not seeing how to solve this!

[Southside]

Killed both the nodes I had running to exercise churn - so ~120Mb and ~70Mb of chunks just went phut. Recover from that, pal…

Now trying to connect again with @happybeing 's bash loop on the big box

[Southside]

I have your script running with sleep 2

Tell me if this is OK/Not OK

Away out for an hour or so on a WifelyCommand to purchase black crepe ribbons for the Great Mourning.

Back soon

PS Todays sound track is Sydney Devine - Crying Time - YouTube on repeat.

[Traktion]

@happybeing

A way to limit this effect might be to have more do some work for each join attempt, but that work needs to be something that can’t be done faster with more CPU, maybe something more like you have to route N messages before you get to join.

A task which is randomly hard would be good. It would shuffle then pack of joiners, not just based on capacity, but also based on luck. Perhaps completing it would align with network requirements or not. Just need to stop folks with lots of hardware and nodes from loading the pack.

Edit: I say just… much more to consider, but you get the idea!

[happybeing]

Ok, I’ve got my shiny new battery installed so it’s time to set up a nice in the cloud and dust off my Odroids and Raspberry Pi!

Anyone fancy taking four 28Kg batteries to the tip for me? BTW, those lead filled Trojans have been replaced by a single 14Kg Lithium which will charge in about half the time (cost almost identical).

[lionel.faber]

A valid use case indeed. The PR looked good and is now merged too Thanks @tfa

[happybeing]

@Traktion

A task which is randomly hard would be good.

I don’t think that’s enough. What we need to defeat is the ability to stack the odds in your favour by applying to join many more times than someone else, and from many different machines (eg in the cloud). I think this is a hard one to solve. In fact it isn’t soluble, but we need to make doing so as costly as possible compared to someone with a single low powered device. I confess I’m stumped.

[davidpbrown]

… If it’s not to be a free for all, then it has to be fair in some other way.

If a body of nodes are required to boot the final network, the sense of where those are could be based on a previous testnet?.. only the elders from that testnet get preferred option to be the strong setup for the network and before others at random?

The other idea that makes no sense perhaps is to disadvantage new nodes, hobble the advantage, until the network has many nodes and can free up activity to all. So, make it treacle like at first, redundant work on the junior nodes to keep them busy… and that way the network requires more nodes for the same amount of work… and relaxes that over time. It would be expensive in the work nodes are doing but if it’s short term perhaps not controversial.