SAFE Network - Test 12b (Network offline, end of test)

Development Updates
1

Test 12 gave us a lot of valuable information and exposed several bugs. We addressed the following issues, both to fix the problems we knew about and to improve the usefulness of the logs, and are starting an updated test network today: Test 12b.

  • We reduced the amount of log messages, as they were far too detailed and created several gigabytes of log files over the course of just one day. In particular, Test 12 was logging every single message that was being sent.
  • On the other hand, we added a bit more information to the logs in some places, to get a closer look at the points where we still suspect issues. For example, there were several UnexpectedState errors and we now print what state that peer is actually in (connected to us, through a tunnel or not, in the routing table or not, etc.). Similarly, when we receive a message from an “unknown peer”, we now print the message itself. And in addition to the node’s name, every line contains the current section’s prefix.
  • The hole punching mechanism is creating lots of sockets and can reach the file descriptor limit of the operating system. We disabled it completely and send only static information (IP and port) to the other peer for now. This is just a temporary change, of course, to help us debug other parts of the system that are unrelated to hole punching problems.
  • Because of that and since we saw a lot of tunnelling in the logs, indicating that a lot of nodes had failed to establish direct connections, this network will reject any nodes that do not accept direct TCP connections from the outside. These connections can be direct, port forwarded or obtained via UPnP.
  • We improved the logging for resource proof on both sides: It now indicates more clearly if you were not able to join because of ongoing churn, as opposed to failing the challenge. And the nodes themselves print the status of their current candidate periodically every 60 seconds. The log level for rejecting candidates was lowered.
  • More logging was added for the routing table recovery mechanism that periodically restores consensus in every section about the network’s structure.
  • The timeout for retrying if you failed to join was increased to five minutes.
  • The network now tries to balance itself: if one part of the network already consists of much more sections than another part, it won’t accept new nodes until the other part catches up. That further limits the number of vaults that can join per minute, but it should increase the network’s stability.
  • In some cases, SectionSplit events were not passed to vaults. That didn’t have any consequences but printed an error message every time.

Test 12b will be a quick test network. We’ve taken our best guess to try to address the problems with Test 12, but it’s possible that there might still be issues with Test 12b. If this is the case, then we’ll have a much better idea about what caused the issue, since we improved the logs in places where we suspect issues might happen. If it turns out that the problem is fixed, then we’ll continue to let Test 12b run, at least until we release the next set of updates.

Also, lots of people who were able to join Test 12 (with SAFE Vault) might not be able to join Test 12b. The burden of relaying on other nodes was bringing the overall performance down, so we made changes in Crust to block nodes from joining if they do not accept direct TCP connections from the outside. As hole punching / further protocol support gets added in Crust, the number of people “directly connectable” will increase vastly. For now, with this updated network, only people who either have a TCP port forwarded and specify it in their Crust config file OR people who have UPnP enabled will be able to participate as a vault.

1806×705 66.5 KB

If you see this message, it’s because the network is not able to reach you. You’ll need to forward a TCP port or enable UPnP on your router.

If you forwarded a TCP port on your router (see this website for more information on how to do this), you need to specify the port in the safe_vault.crust.config file (which is located in the same directory as the safe_vault binary) in the tcp_acceptor_port field.

Here are the download links for Test 12b:

51 Likes
2

Uploading files now :grinning:

6 Likes
3

Yay for once I’m home for it. :tada:

9 Likes
5

Chunks stored: Immutable: 0, Structured: 1, Appendable: 0. Total stored: 246 bytes.

edit: Chunks stored: Immutable: 14, Structured: 11, Appendable: 0. Total stored: 4904924 bytes.

5 Likes
6

In case it’s useful to have traffic downloading too
safe://hello
safe://wall.knot/ @ ~19MB
safe://fear.knot/ @ ~19MB

7 Likes
7

Edit: working now - I had VPN on… without that its trying to check speed now… likely not fast enough though.

1 Like
8

I’m out too. At work, and so don’t have control of the router at all. :unamused:

Adding content to the network though. safe://portlandspirit/

EDIT: OK, I can’t stand it. I went ahead and installed it on my Linode server. Online, with Routing Table size: 52 :sunglasses:

8 Likes
9

No luck here with the Vault. I enabled UPnP on my router:

I disconnected power from my router for 15 sec. After that I restarted my Win64-machine but still no luck:

Bootstrapping(7e11d3..) Listener started on port 5483.
ERROR 21:44:06.344250100 [crust::main::bootstrap mod.rs:184] Failed to Bootstrap: (FailedExternalReachability) Bootstrapee node could not establish connection to us.
INFO 21:44:06.344250100 [routing::states::bootstrapping bootstrapping.rs:201] Bootstrapping(7e11d3..) Failed to bootstrap. Terminating.
DEBUG 21:44:06.344250100 [routing::state_machine state_machine.rs:267] State::Bootstrapping(7e11d3..) Terminating state machine

I also tried to open a port on my router, but even that didn’t work. Had this problem earlier, I read on forums that it has to do with my provider and IPv4 and IPv6 settings. I know I do all the right settings but open port website keeps telling me the port is closed.

I disabled both my virus checker and windows firewall for 15 minutes but no luck either.

EDIT: fixed > WAN unblocked and then opened port 5483

2 Likes
10

Maybe your router has a built-in firewall? If so, try adding an exception for one of the bootstrap nodes (e.g. 178.62.23.138) or for the forwarded port.

1 Like
11

Thanks, but this was the problem: EDIT: fixed > WAN unblocked and then opened port 5483

The WAN is the public/internet facing side of your router. Most routers block all traffic that originates from the internet into your WAN for security reasons, including ping (icmp), your router’s GUI (port 80), etc. When you enable port forwarding, you’re OPENING one or more of those ports on the WAN and forwarding the traffic to any internal ip address on your home network (LAN).

7 Likes
12

My minisampler is back up:

safe://sample.aenemic

4 Likes
13

I see it, but can’t hear anything. I assume I’m supposed to click on the squares, but no audio. I like the picture though!

14

click the corresponding keyboard key, doesnt register mouse clicks. (the tag of the drumsound is not accurate for most, i got bored browsing samples)

15

Ahhh! Cool!
20 Characters

16

Vault works for me with UPnP: now 82 Mb on chunks stored.
No messages with warning or error in output or Node.log. I guess the ‘… routes/failed: [1283]/43’ messages are normal.
To compensate for the temporarily missing hole punching: safe://ophole.draw

EDIT: to be correct 3 ‘Connection reset by peer’ error messages. I assume that is to be expected.

6 Likes
17

Have a like for One Punch Man

5 Likes
18

safe://alien
safe://tetris.alien
safe://forex.alien

3 Likes
19

safe://safewallet.wow (with English, Spanish, Chinese and Japanese translations)
safe://safefaucet.wow (instructions)

13 Likes
20

Filling up 500 PUTS with private data. Upload at 220 KB/sec. Most of the time.

748×558 44.9 KB

6 Likes
21

Things are getting exciting now! Fine tuning of logic to run the network???

3 Likes