Crust Test v2 (concluded)

[Vort]

@anon40006692

TCP is used for Chats and Messengers and UTP for Videos and Streams etc.

Streams in SAFE network? That would be great.

[dask]

Would love a bit more insight here as well. TCP vs UTP is easy. UTP you just blast data at a target by handing it to the network layer and you are both responsible for figuring out what got through, TCP includes piece numbering, checksums and acknowledgements so is more reliable but has a lot of potentially redundant back and forth. I assume that a direct connection is a transport protocol like TCP or UDP, but using a different combination of features…

[Vort]

It looks like for now the goal is just to transport data with whatever method is possible. UDP can be enhanced in a way that it will have the same features as TCP (μTP is an example, it have 100% reliability), so both of them will be reliable. Using specific features of UDP (low delay, for example), I guess, is a task for far future.

[fiee]

I’m late, it’s sunday and the network is quite quiet:

14/0 on my Mac (OSX 10.9.5)
10/4 on Windows (Win 7 pro); had to open the Windows firewall
1/1 on Linux (Ubuntu 18.04)
according to dashboard – clients showed more (successful) connections, also locally between my clients.

All at the same network switch; Win/Lin running on my dual boot laptop

Dashboard needed a while until my “other” (Win/Lin) data was available, and it’s still not complete.

Wondering if I should also try my (headless) servers…

Edit: 14/0 means 14 successful, 0 failed (others would have written 14/14). Dashboard stopped updating in the middle of my tests, I guess.

[fiee]

Update:
Connection with Miguelo from Finland failed on my Mac, but succeeded on Linux (same network switch). The Mac connection attempt was recorded on the dashboard (user fiee), the Linux one (user fiee_Ubuntu) wasn’t, like most of the others. Both clients are still running.

[Sascha]

@fiee

according to dashboard – clients showed more (successful) connections

The dashboard doesn’t seem to work right. I get strange results too.

[Toivo]

@drehb

Why one occasion I was able to connect to a user and then on other occasion, after restarting the client, the connection to this same user fails?

Was there an answer to this? I’m also interested in understanding why this happens.

No, there hasn’t been any answer.

I just a minute ago launhced the test and got success/fail 8/0.
Then a minute after that I got 0/1.

I don’t think that suddenly all of those eight went offline.

Edit: It seems that dashboard gives different results from client, like @Sascha said above.

[ustulation]

Ah i think you typo-ed uTP is micro-transport-protocol meant to add reliability and congestion control on top of UDP. So UDP is unreliable and has no-congestion control built in. For video/audio etc. UDP would normally be fine as a loss of a few frames/samples here and there should be acceptable for those data. TCP and uTP is where you require reliability and congestion control.

Normally you wouldn’t use raw UDP as you at-least want some congestion control or some re-ordering detection, but that’s use-case related.

[anon40006692]

UDP you are right! Edited my post

[ustulation]

You are correct though. Even if you restarted, unless you connected to someone you did not connect to before or changed your OS or IP or something else, you will normally not be reflected again on the dash. That’s the naive uniqueness filter we have on the dash. This is to prevent skewing of the results and prevent bias. Otherwise if someone who failed made 100 attempts and (likely) failed in all of them, or similarly someone succeeding restarted several times and (likely) succeeded each time, they would bias the results.

[futuretrack]

Have tested using an OSX VM running on a mac laptop. Got 19 successful connections an 3 failed. TCP didn’t work, but UDP and direct connections were fine.

Ended up with this message on a loop :

Symmetric NAT with non-uniformly changing port mapping detected. No logic for Tcp external address prediction for these circumstances!

The test eventually finished with a message about connection failure to the rendezvous server - I suspect that’s because my internet connection has a tendency to drop from time to time.

Given the configuration was Internet <-> Router 1 <-NAT-> Router 2 <-NAT-> Laptop <-NAT-> VM, I think that’s a fairly impressive result from what I’ve understood to be the difficulties of hole punching and NAT traversal.

[loziniak]

Hi all! Running the test now, interesting to see connecting you guys

One thing makes me wonder - a "hard_coded_contacts" line in client.crust.config file. Does the crust test imitate the way we will connect our nodes in future? Having to connect to a particular IP does not seem much distributed…

[Mendrit]

Same error here.

I restarted app lots of times, but it never run too long.
It is same also on second PC at home.

TRACE 09:08:40.616970400 [client client.rs:851] Sending GetPeerReq
TRACE 09:08:40.662973100 [client client.rs:913] Received GetPeerResp(None)
DEBUG 09:08:50.663545100 [client client.rs:997] Map conn 407c8a… <-> 584
DEBUG 09:08:58.664002700 [p2p::udp::hole_punch mod.rs:181] Timeout for UDP Rendezvous
DEBUG 09:08:58.664002700 [p2p::udp::hole_punch mod.rs:218] Terminating due to: UdpRendezvousFailed
DEBUG 09:08:58.664002700 [p2p::hole_punch hole_punch.rs:609] Extracted results after time out for UDP Rendezvous reached
DEBUG 09:08:58.664002700 [p2p::tcp::hole_punch mod.rs:252] Timeout for TCP Rendezvous
DEBUG 09:08:58.664002700 [p2p::tcp::hole_punch mod.rs:261] Terminating due to: TcpRendezvousFailed
ERROR 09:08:58.664002700 [client client.rs:308] Failed to get our connection info: Rendezvous with server failed for both Tcp and Udp - could not obtain our external address
DEBUG 09:08:58.664002700 [p2p::hole_punch hole_punch.rs:401] Terminating due to: RendezvousFailed

[povilasb]

@loziniak, in real life Crust will use hard coded contacts to make connections with very first nodes which then announce about other nodes on the network. Then when Crust will connect with those other nodes, they will be cached in so called “bootstrap cache”. This bootstrap cache is dynamic and updated automatically by Crust. Then you can kill hard coded contacts, but Crust will still be able to bootstrap to the network because of cached previous connections

[krnelson]

@Mendrit

I restarted app lots of times, but it never run too long.

Same thing here (PM’d log to @nbaksalyar earlier today). Did not have the problem in Crust Test v1 if that helps…

[Dimitar]

@krnelson

Same thing here (PM’d log to @nbaksalyar earlier today). Did not have the problem in Crust Test v1 if that helps…

For me the program goes now fourth day without restarting…

[Stark]

Mine has a 100% success rate but closes after an hour or so. I’m happy it’s doing well but the shut down is a little disappointing.

[fiee]

Trying to run Crust on my bread cutter. Doesn’t work.

[riddim]

Hmhmm - to me that happened only when my provider did a 24h forced disconnect with ip reassignment (resulting in me not having a registered ip… )

[jeremyjpj0916]

@povilasb

Crust will use hard coded contacts to make connections with very first nodes which then announce about other nodes on the network. Then when Crust will connect with those other nodes, they will be cached in so called “bootstrap cache”. This bootstrap cache is dynamic and updated automatically by Crust. Then you can kill hard coded contacts, but Crust will still be able to bootstrap to the network because of cached previous connections

With hard coded contacts does that not make them targets for attack? Also will MaidSafe ensure a way to configure those via some application UI so others can update them easily if one ever becomes “compromised” or offline? And yeah I get its only on first run but still probably would be good to enable configuring adding/deleting from the pool of hosts for bootstrap as needed.