Fleming Testnet v2 Release - * OFFLINE - V3 RELEASED *

[Michael_Hills]

Its an inexplicable feeling, a rush, a collective rush of productivity.

We can Accomplish Anything Leveraging Collective Energy. Its a place of cyber ZEN.

[Sascha]

@dirvine

much more relaxed, but much faster work rate, weirdly.

Not weird at all. I done told y’all:

@Sascha

Eat well, sleep, take breaks.

This is fun!

[Shu]

I am grateful for your team to push out a V2 testnet iteration in such a short time.

Just to share some more feedback comparing V2 vs V1 testnet from my end:

Not only did all the CLI commands I tested on V1 finally succeed (minus the safe wallet balance), it was great to finally see my home node join the testnet and store a single chunk successfully!

Using a re-playable container deployment has helped me vet out that the existing locked down network configuration in my dev lab is still allowing safe cli commands to succeed in their communication workflow.

Thank you Maidsafe team! You made my day!

[dask]

Amazing, pls share container methodology with community if you can. Having container best practices known before launch will greatly help adoption.

Team, once again, having this function inside containers (and cross compiled to rPi4 etc.) is a testament to some engineering choices made over the last few years. Thank you for the unwavering dedication.

[jlpell]

@Vort

It may be Windows specific problem by the way.

Yes, windows is the problem.

For the next testnet can we organise the comments by platform (Linux, Mac, Windows)?

@Shu

Thank you Maidsafe team! You made my day!

Mine too! Cheers all.

[Toivo]

@happybeing

I’ve now done safe node killall and safe node join and letting it run again.

I did not do killall, and then I was accepted on the first try. How did it go with you? I wonder if my acceptance was just luck or maybe somehow related to attempts before…

[Toivo]

@davidpbrown

Bug hunting is fun
You put them out there, we’ll find them.

Yes, it’s nice to be able to contribute in this way.

If the pace of iterations really is this fast, I wonder if it would make sense to make a steady rhythm to them. For example every Tuesday and Thursday - and then skip a beat if there is more work to do.

Oh, but that sounds like order everything and we are supposed to go full async

[Vort]

@dirvine

If you install rust, grab the repo and just do cargo build

Nice build system. No need to hunt for dependencies for hours.

This is how stack problem can be fixed (source1, source2):
(Note the differences between 0x800000 and 8000000)

diff --git a/.cargo/config.toml b/.cargo/config.toml
new file mode 100644
index 0000000..0bdfed5
--- /dev/null
+++ b/.cargo/config.toml
@@ -0,0 +1,2 @@
+[target.x86_64-pc-windows-msvc]
+rustflags = ["-C", "link-arg=/STACK:0x800000"]

[joshuef]

Nice one @Vort !

[Racket]

What does this mean?

Error: Failed to connect: ConnectionError: Failed to connect to the SAFE Network: QuicP2p(UnresolvedPublicIp) topic:34430

[JPL]

[Racket]

Haven’t seen that I am sorry

[happybeing]

@Toivo

I did not do killall, and then I was accepted on the first try. How did it go with you?

My node was never accepted for test 2.

[happybeing]

@maidsafe

The simple fix for this was to only allow a node to be promoted to Elder if we can establish a connection to it, otherwise it will remain as an Adult regardless of its node age.

What if nodes try to lock up sections by refusing to respond only when they are Elders, but do respond when Adult. I think this would result in the same behaviour and only need two such Elders to kill a section. (ICYMI: @dirvine)

N.B. Credit to Redditor varikonniemi for spotting this.

[Traktion]

Maybe just demote them permanently, by adding them to a permanent adult only list.

Edit: You could also drop their age to 1, kick them off the network, etc. I suppose it depends how severe the punishment should be.

[happybeing]

I think we just need a selection mechanism that’s a bit more random. So choose one of the top five candidate Adults, or top ten etc so the odds are sufficiently difficult to game.

[tfa]

@dirvine

If so then the build for this testnet has missed the updates on connectivity or we are not setting the connectable flag correctly

Or maybe not and this is the problem.

How do you launch the nodes after the genesis?

If you launch them without specifying --local-adr then a random port will be chosen. I guess you haven’t opened all the ports in the firewall which means that a node won’t accept an unsolicited connection from a new node, though it will accept requests from nodes for which it is the initiator of the connection which are those in the hardcoded list.

This is how I think communication works but I am not a network specialist and I may be wrong.

EDIT: I was unclear. What I propose is that Maidsafe and anybody else adding nodes to the network use --local-adr parameter and ensure that the specified port is opened in the firewal.

[jlpell]

@tfa

I guess you haven’t opened all the ports in the firewall which means that a node won’t accept an unsolicited connection from a new node, though it will accept requests from nodes for which it is the initiator of the connection which are those in the hardcoded list.

That sounds about right for a typical firewall.

[Vort]

I saw hangs earlier when was using the same port over and over.
Maybe 3 minutes delay will help with this problem however.
Also I saw answer that random port may be useful to fight with censorship.

[dirvine]

@tfa

If you launch them without specifying --local-adr then a random port will be chosen. I guess you haven’t opened all the ports in the firewall which means that a node won’t accept an unsolicited connection from a new node, though it will accept requests from nodes for which it is the initiator of the connection which are those in the hardcoded list.

This reachable test is what we are on right now. It’s a bit subtle, but your firewall point is well made and it is true. So we have

1. Direct connected machines
2. Those through IGD
3. Full cone Nat (unrestricted)
   These should all work as reachable. Quic gives us this cool ability where a single endpoint will multiplex many connections through. So when you go out that connection to other nodes and they see your IP:Port they can come back to you (connect backwards on a new endpoint). That is a reachable node (there are caveats, there are always caveats in networking)

Sometimes though, NIC and routers will also multiplex such connections. So you get an incoming connection from 1.1.1.1:80 and then connect back from another local endpoint (same IP, same NIC) and the NIC will see there is a connection to that IP and jump on it and use it, so you think you went back on another port, but in fact did not. Routers can do that same thing.

So many STUN/TURN etc. can use 2 NICs for such tests to try and ensure different IP + hardware + ports.

So we are checking a couple of mechanisms here to ensure we can tell for sure a node is connectable (and can therefore become and Elder), but also a node killer that will allow Adults to report an Elder as not reachable and we kill him, same goes for Elders failing DKG, we also slaughter them for now. We can optimise later, but now it’s just blind murder we do, or will do to start with.