Following the success of the first Crust Test a couple of weeks ago we can now continue along the path toward the SAFE-FLEMING milestone, with the second iteration of the crust p2p test. This incorporate the following improvements to the networking libraries:
- Enable direct connections
- Improve dashboard performance
- Enhance dashboard filtering to include:
- AND/OR between the connection types: Direct, TCP HP, UTP HP
- Filter by user (Public Key & option ‘name’)
After your fantastic support during the last test, we would like to get your involvement once again - by running this new test you can play your part in making history!
This tutorial will guide you through the following:
- Before Running the test
- Running the test
- Visit the Dashboard to see the results
- Privacy Policy
- Cookie Policy
- Giving Feedback
- Frequently Asked Questions
As results arrive and issues are logged new versions of the apps will be released to continue to improve these findings. We’ll let you know and ask you to run again.
If you’d like to hear more about the Crust test and a lot more @fergish from SAFE Crossroads has been speaking to @nbaksalyar about the Crust Test in
SAFE Crossroads #45, Approaches to SAFE-Fleming (Alpha-3).
Before running the test
There are a few steps that you have to follow before being able to connect to the test network.
- If you don’t already have one then you’ll need a SAFE Network Forum account.
- Once you have registered the account you’ll need to have reached Basic Trust Level 1.
- You’ll need to then register your IP address to get an invite to the test.
Note: if you were registered for the 1st test you’ll still need to do this step as we’re starting afresh - Now we’re ready to download the test.
- Choose your operating system (see supported platforms)
- download the ZIP file (using Chrome browser?)
- then unzip it.
That’s it!
Running the test
The test is a simple application that lets you connect to other peers running the test. To run it all you need to do is:
-
Run the
clientexecutable. (MacOS users Read this first). -
Enter a name - this can be real or made-up (optional) and will be visible to others on the dashboard. I’ve entered “DGeddes”. Pressing the
Enterkey will allow the client to start looking for peers to connect to.
-
… that’s it - you are connecting to peers and participating in the test!
-
Leave the client running for as long as you are comfortable with. The longer it runs the more peers it will find and connect to.
The application then collects your NAT (router) type, operating system, confirms what protocols are supported and then starts to look for other available peers to connect to.
If others are participating in the test at the same time, you will see connection attempts being made, whether these are successful and the type of connection made e.g. TCP-HP, UDP-HP or direct.
The app will notify you when all known peers are connected to, and then will check for new peers every 10 seconds.
When the test is concluded the client app will say so.
The Crust Dashboard
The Crust Dashboard shows you the results of the test so far and displays the peer-to-peer connections that have taken place. You’ll see the number of connections and their success rate.
There are 3 main sections to the dashboard:
- Filter - controls what results are displayed on the chart and the table, options are:
- NAT Type
- Operating System
- Country
- User (inc. yourself)
- Chart - shows the percentage of successful connection attempts for each protocol
- Table - shows connection attempts in more detail based on the filter
Please note the dashboard is designed to be viewed on desktop computers and viewing on lower resolutions (tablet/mobile) may result in a less than perfect experience.
What’s shown on the table?
The table on the dashboard shows the following content for each attempted connection:
| # | TCP HP | UDP HP | NAT Type | Operating System | Country |
|---|---|---|---|---|---|
| Unique identifer | Connection attempt result | Connection attempt result | EDM / EIM | Linux / MacOS / Windows | Geographic location (derived from IP Address) |
What do these terms mean?
| Term | Description |
|---|---|
| TCP HP | Hole punching via Transmission Control Protocol (TCP) |
| UDP HP | Hole punching via User Datagram Protocol (UDP) |
| NAT Type | Network Address Translation enables a device to connect to the internet (through your router). Types available are: EDM & EIM. |
| EDM | Endpoint-Dependent Mapping (EDM) involves our external address changing depending on the remote endpoint we are talking to. Most routers have a fixed offset they use when changing the address so can be predicted. |
| EIM | Endpoint-Independent Mapping (EIM) allows the device to accept incoming traffic to a mapped public port from ANY external endpoint on the public network. |
Showing MY results only
Using the “Filter By User” option we can narrow the dashboard results down to our own connections only. When text is entered into the include filter box we’ll see a dropdown of available IDs appear and we can select ourselves.
Note the Public ID is displayed in brackets after the public name - this is the same as displayed in the test client.
Showing results for multiple specified users
It’s possible to specify more than one user to view the results of. All we have to do is add them, one at a time, into the “Include” box. Here I’ve shown the results of myself and 3 other lucky souls.
Duplicate results
If multiple clients are run from the exact same environments (same IP Address, Operating System, NAT Type, TCP HP Result, UDP HP Result & Direct Result) then the results will be considered a duplicate and the results will be ignored (i.e. not recorded). This is also true if the peer_requester and peer_responder have been swapped.
If the clients have any differences in their environments (e.g. NAT Types) then the results will not be considered duplicates and will be recorded on the dashboard.
Privacy Policy
For the test we record the currently active IP address of your login in order to avoid spamming attempts.
When running the test application client you’ll see your end-point info (IP address and port number) and the end-point info of any peers you are directly connected to.
The dashboard also uses the IP address to determine the country the client is connecting from via the geolocation service ipapi.co who store the IP address for 6 months from the start of the programme.
If you would like to learn more then please see maidsafe.net’s Privacy Policy.
Cookie Policy
The invite server (crusttest.maidsafe.net) creates a single cookie once the user has been authenticated using their Forum account. The cookie contains the following information:
Session ID
If you would like to learn more then please see maidsafe.net’s Cookie Policy.
Giving Feedback
As always, we’re keen to hear from you so if you have any feedback on the client application, dashboard or overall test process please just reply to this post. Also, if anything isn’t as clear to follow as you’d like it to be, or you have run into a problem, then let us know below.
Frequently Asked Questions
How long is the test scheduled to run for?
This is another exciting bit… we don’t really know! The test will be running for only as long as it takes to get the results we need in order to see the effectiveness of using different methods across protocols. This is where you can really make a difference by getting involved - imagine being able to say:
“I was part of the test programme that shaped the future of the internet!”
Don’t wait around - get involved while you can and run the test.
What is the Client Application?
An executable which users download and enables two peers to connect to each other, via the proxy node. The proxy node is the hard-coded contact which all peers bootstrap to, and it also receives the connection attempt results from the peers in the test.
What operating systems are supported?
The client application is supported on the following operating systems:
- MacOS 10.13 (or higher)
- Windows 10 x64
- Most up to date Linux distributions
Why is there a warning downloading the zip using Chrome browser?
If you are using Google’s Chrome browser you might see a warning message when downloading the zip. The message states that the zip “is not commonly downloaded and may be dangerous” and you’ll be given the option to Discard or to Keep. Just click Keep to allow the download to complete.
We’ve seen this on Windows and on MacOs and are looking into it to see if we can avoid this in future.
Why do I see ‘“Client” can’t be opened because the identity of the developer cannot be confirmed"’ on MacOS
On MacOS you can expect to see a pop up that warns that the client executable “can’t be opened because the identity of the developer cannot be confirmed”.
The software has in fact been signed but because the client is a Unix executable rather than a packaged Mac app it is flagged by the system. To resolve this:
- In the Finder, go to where you downloaded and unzipped the client.
- Control-click the client icon
- Choose Open from the shortcut menu.
The app is now saved as an exception to your security settings, and you can open it in the future by double-clicking it just as you can any registered app.
To confirm the executable has been signed by MaidSafe you can open a terminal and in the same folder as the executable run:
$ codesign -dvvv client
We provide the checksum for all our zip files so users can be assured that they are approved by MaidSafe.
We’ll be looking to see if we can improve on this as we move forward.
What data is captured by the Client application?
- IP address and port number
- NAT type
- Operating System
- Protocol method
- Time to successful connection
- UPnP support check
NAT type, OS, protocol method along with connection attempt results are sent to the dashboard for display. More granular data, such as successful connection time and UPnP check, is logged for detailed debugging, but is not publicly accessible.
How long should I leave the client running?
The longer the client is running the more peers it can connect with but it’s completely up to you how long you want to run the test for. MaidSafe will have peers running for the duration of the test.
Why do I need an Invite?
By registering your IP address at the start of the process, your IP address is recorded by the hard coded contact (the proxy node). Then when you run the client application, your IP address is matched with that on the proxy and you are authorised to the test. This is how we prevent spamming attempts.
What is the Crust Dashboard?
The Crust Dashboard allows anyone to view the crust connection results in a meaningful way. It does not display all data received link to ‘what data is captured by the client application’
What database is used?
A MongoDB database is used to store the connection results received from the test.
What’s in the ZIP File?
There are 4 files included in the downloaded ZIP file:
- client: This is the client application that the user runs to connect to others in the test.
- client.crust.config: This is the main configuration file which defines some essential parameters for the client application including the hard-coded contact.
- log.toml: This file configures the output content and format of the log file.
- p2p-config: Additional configuration file which lists some hard coded contacts and hole-punching and rendezvous options.
An additional 2 files are created when the client runs. - client-##########.log: This is the log file which collects all connection activity (such as attempted, successful and failed results).
- client.bootstrap.cache: This is for future use when we connect with multiple proxies (currently there is only one proxy).
What is my end-point info?
When your node connects directly to another node you can see their end-point info within the console app. The end-point info is:
- IP Address
- Port number
. Will leave it up and running this was just the first 2 mins.
