Stable Droplet Test Network

I guess you mean “bootstrap” node. “tunnel” node has a different meaning in the network(its a node thats relaying messages to a given other node for the source since it’s not able to connect to the destination directly itself).

In this case, here’s the source. Looks like the client has lost its connection to its bootstrap/proxy node(could be cos of multiple reasons, bootstrap node went offline(not likely). client connection terminated cos of local network fluctuating, …).

This above message indicates a message such as this should have also got logged before in the log.

I don’t think its you being impatient :smiley: and yes this would be fatal to the upload and would lead to the same issue you raised in GitHub I think. At this point, if the Put requests went through past the proxy node before its connection to your client terminated, then the network could have very well stored the chunks but not been able to indicate success to the client and thereby the metadata/directory listings for the file might not be updated accordingly(or even only part chunks could have been uploaded) and the rollback / recovery process isnt in place to just resume on retry right now.

Thats not something that happens for Clients. For clients the expected behaviour with such failure is for Launcher to have received a “Disconnected” event and indicate to the user that they would need to reconnect to the network and Login again to resume their operations. For vaults its simpler as they just restart and create a new identity currently.

@davidpbrown If you still have the log file from that session and you don’t see a message such as Lost connection to last proxy node in your client log file, that would point to an issue where your node hasn’t realised it and informed launcher of the same.

3 Likes

Actually I meant tunnel because that’s what a proxy does, right? I’ve seen the proxy error many times, and it’s usually because the hard-coded contact is offline.

I know it doesn’t happen, I was just saying, they should handle it as gracefully as vaults do.

It should not do that, it by default has to be directly accessible, to bootstrap from :wink: Tunnel is more like a network level proxy between network nodes, not client → bootstrap nodes. In this case proxy is “acting on behalf of” a tunnel node is “relaying for” if that makes sense.

2 Likes

OK, thanks for the clarification, that there’s two meanings of proxy. It was the relay definition I already had, but the proxy error I was seeing (with client vaults joining by trying to connect to an offline vault in the config).

1 Like

grep suggests none of the log files in /safe_launcher/ now have that message. However, I wasn’t being careful and started up another account - restarting the launcher; so, I wonder then the logs have been refreshed. I can’t see the error logged either.

If logs are refreshed each new session, perhaps we backup logs where new errors occur.

and just for completeness, I went back in now and retried the upload and it worked fine. The previous had left a 0 byte file, so I just deleted it and retried the upload. Clearly then just a connection issue but a clean one.

1 Like

Thu 09 Jun 2016 UTC 18:27:24 and all is well :slight_smile:
http://dir.random.safenet
=>
http://ar.udhr.safenet
http://maidsafeman.whiteoutmashupz.safenet
http://ko.udhr.safenet
http://mystats.safenet
http://frabrunelle.safenet
http://example.ghost07.safenet
http://marble.play.safenet
http://web.chunky101.safenet
http://yvette.safenet
http://polpolrene.safenet
http://bible.safenet
http://en.udhr.safenet
http://dir.random.safenet
http://oldhold.southside.safenet
http://zh.udhr.safenet
http://wof.savage1.safenet
http://music.safenet
http://hello.safenet
http://explorer.safenet
http://me.too.safenet
http://app.ghost07.safenet
http://frostbyte.safenet
http://the.teapot.safenet
http://heaven.safenet
http://blog.riddim.safenet
http://pirate.savage1.safenet
http://pacman.safenet
http://eye.eye.safenet
http://a.random.safenet
http://ithanium.safenet
http://this.is.safenet
http://the.best.safenet

5 Likes

Looking good on the sites!!!

I need to get off my butt and get Mario Bros. back up there! :wink:

4 Likes

Does this include the newest SafeAppStore testnet link?

2 Likes

Wasn’t aware of it but expect you’re suggesting http://safeapps2.w0mm.safenet so that’s on the list for future.

3 Likes

btw - your appStore looks pretty! i like where this is going :slight_smile:

2 Likes

Thank you very much! The main things we are able to work on at this point in the SAFE Network’s development are the UI and organization, so a lot of work has gone into making our brand image etc.

We wanted something unique to us and independent from MaidSafe etc as our brand should be, and have made many layouts and images for this, and have somewhat gravitated towards those that depict our company’s roots in San Francisco.

However we are still finishing some of the other designs and will release them very shortly, and most likely have an ASDGC vote to decide

4 Likes

Got a fun mario clone back up.

A to run and for actions
Arrows to move/jump

cheers http://play.marioclone.safenet

3 Likes

Hey guys,

Sorry, there was an issue with the tcp mapper servers(not the actual vaults) and we needed to restart them. Data stored in the network is intact. However we do need to update launchers config file without which we will be getting stuck when started with “Trying to connect” in launchers UI.

Updated zip packages are added to the same GitHub SAFE Launcher v0.4.5 release.

For those of you who wish to make the update by editing the launcher’s crust.config file manually, we’ll need to change:

Linux and Win:
safe_launcher.crust.config file next to the launcher binary.

OSX (bit tricky): safe_launcher Helper.crust.config file which will be inside the launcher app package: safe_launcher.app/Contents/Frameworks/safe_launcher Helper.app/Contents/MacOS

In the config file we need to change:

“tcp_mapper_servers”: [
“162.243.228.81:39590”,
“128.199.185.249:44473”,
“178.62.82.189:46782”
],

to

“tcp_mapper_servers”: [
“139.59.178.41:33448”
],

That should get us bootstrapped fine to the network again. Sorry about this issue. It’s going to be another thing thats removed with the mio version of crust as we wouldn’t need such endpoints anymore in the config file :slight_smile:

13 Likes

Sorry I didn’t this comment till now! I don’t think it’s really objections so much as a general skepticism about the project—basically, whether or not it will work. Though I think this is mainly coming from people looking at the charts as opposed to the dev updates.

Is this network down? This is the first time we have had an issue connecting to it.

Was supposed to be our go-to, reliable network for development :stuck_out_tongue:

I know the other networks were recently taken down, and we’re waiting for a new one to begin, but now this Stable Droplet Test net is also down, correct?

I remember seeing recently they planned to update the software running the stable droplet test network but can’t find the exact place it does.

1 Like

Mentioned here, it refers to client test network which I thought was 6 but I’m sure its the droplet test network.

2 Likes

Thanks very much for this

1 Like

Maybe the droplets evaporated in the hot weather. :stuck_out_tongue_winking_eye:

1 Like