Testing I'm getting connection problems - any current SN issues?

happybeing · March 22, 2018, 5:38pm

I’m getting connection issues using safeApp.connect().

I’ve only recently started using them rather than safeApp.connectAuthorised(), so not sure if this has always had problems or if my app is buggy, or if perhaps there are temporary issues with the SN or my connection.

Is anyone aware of issues while using live alpha2 apps currently?

I have this issue with both peruse 0.51 and SAFE Browser 0.07, console output looks like this…

I 18-03-22 17:28:24.414664 Bootstrapping(3aef61..) Connection failed: The chosen proxy node already has connections to the maximum number of clients allowed per proxy.
I 18-03-22 17:28:24.416186 Bootstrapping(3aef61..) Lost connection to proxy PublicId(name: 23b02a..).
I 18-03-22 17:28:25.663707 Failed to Bootstrap with 138.68.189.36:5483: (ClientNotWhitelisted) Our Client is not whitelisted
I 18-03-22 17:28:25.665491 Failed to Bootstrap with 138.68.189.31:5483: (ClientNotWhitelisted) Our Client is not whitelisted
I 18-03-22 17:28:25.667213 Failed to Bootstrap with 138.68.181.182:5483: (ClientNotWhitelisted) Our Client is not whitelisted
I 18-03-22 17:28:25.668637 Failed to Bootstrap with 138.68.189.15:5483: (ClientNotWhitelisted) Our Client is not whitelisted
I 18-03-22 17:28:25.670003 Failed to Bootstrap with 138.68.181.243:5483: (ClientNotWhitelisted) Our Client is not whitelisted
I 18-03-22 17:28:25.671495 Failed to Bootstrap with 138.68.181.179:5483: (ClientNotWhitelisted) Our Client is not whitelisted
I 18-03-22 17:28:25.672826 Failed to Bootstrap with 138.68.181.249:5483: (ClientNotWhitelisted) Our Client is not whitelisted
I 18-03-22 17:28:25.691388 Failed to Bootstrap with 138.68.189.17:5483: (ClientNotWhitelisted) Our Client is not whitelisted
I 18-03-22 17:28:25.692913 Failed to Bootstrap with 138.68.181.242:5483: (ClientNotWhitelisted) Our Client is not whitelisted
I 18-03-22 17:28:25.694244 Failed to Bootstrap with 138.68.189.14:5483: (ClientNotWhitelisted) Our Client is not whitelisted
I 18-03-22 17:28:25.695997 Failed to Bootstrap with 138.68.189.19:5483: (ClientNotWhitelisted) Our Client is not whitelisted
I 18-03-22 17:28:25.697522 Failed to Bootstrap with 138.68.189.38:5483: (ClientNotWhitelisted) Our Client is not whitelisted
I 18-03-22 17:28:25.755882 Failed to Bootstrap with 138.68.189.18:5483: (ClientNotWhitelisted) Our Client is not whitelisted
I 18-03-22 17:28:25.757473 Failed to Bootstrap with 46.101.5.179:5483: (ClientNotWhitelisted) Our Client is not whitelisted
I 18-03-22 17:28:34.404650 Bootstrapping(3aef61..) Failed to bootstrap. Terminating.

Browser console error is this…

WARNING:  +20s Error: Unexpected (probably a logic error): Could not connect to the SAFE Network
    at module.exports (/home/user/safe-releases/2017-09-21_Alpha_2/safe-browser-v0.7.0-linux-x64/resources/app/node_modules/@maidsafe/safe-node-app/src/native/_error.js:19:10)
    at /home/user/safe-releases/2017-09-21_Alpha_2/safe-browser-v0.7.0-linux-x64/resources/app/node_modules/@maidsafe/safe-node-app/src/native/_app.js:28:22
    at /home/user/safe-releases/2017-09-21_Alpha_2/safe-browser-v0.7.0-linux-x64/resources/app/node_modules/ffi/lib/callback.js:66:25
    at Function.proxy (/home/user/safe-releases/2017-09-21_Alpha_2/safe-browser-v0.7.0-linux-x64/resources/app/node_modules/ffi/lib/_foreign_function.js:59:14)
    at Promise (/home/user/safe-releases/2017-09-21_Alpha_2/safe-browser-v0.7.0-linux-x64/resources/app/node_modules/@maidsafe/safe-node-app/src/native/_app.js:37:14)
    at Promise (<anonymous>)
    at Object.app_unregistered (/home/user/safe-releases/2017-09-21_Alpha_2/safe-browser-v0.7.0-linux-x64/resources/app/node_modules/@maidsafe/safe-node-app/src/native/_app.js:22:16)
    at lib.decode_ipc_msg.then (/home/user/safe-releases/2017-09-21_Alpha_2/safe-browser-v0.7.0-linux-x64/resources/app/node_modules/@maidsafe/safe-node-app/src/api/auth.js:302:22)
    at <anonymous>

bochaco · March 22, 2018, 5:47pm

As per the error it seems you have exceeded the allowed maximum number of client connections. Can you please try with latest versions of the browsers?

Edit: I don’t think the version of the browser (or actually the safe_client_libs used within it) should matter actually as the limit is enforced by the proxies, but please give it a try. Unless you can confirm you do have a large number of client connections?

happybeing · March 22, 2018, 6:15pm

I’m getting the same issue with SB 0.10. @bochaco Please can you try visiting safe://plumetest/

Note: clicking INITIALISE STORAGE won’t work for you because it requires access to the plumetest publicid, but just loading the page I’m getting these errors.

In the browser console you can see the call to initReadOnly() which is what is trying to connect. This seems to work fine with mock.

Thanks

Viv · March 22, 2018, 6:25pm

Hey Mark,

I am able to visit the site just now:

some of the proxy nodes are offline right now though (5 out of 25). Digitalocean have been patching their machines for the last few days for some security patches. @Fraser and @StephenC have been managing the process there to bring the network nodes back online after their maintenance windows but it might be a lil while before all proxy nodes are back online. Hopefully they can ping here once they get them all back online. Sorry it wasnt informed already as part of the post krishna made for the invite-manager status

bochaco · March 22, 2018, 6:30pm

I was also able to just loaded, I don’t see any error on the webapp’s console, so it seems it efectively loaded well and fetched all data

happybeing · March 22, 2018, 6:31pm

@Viv Ah, fingers crossed that’s the issue - thanks. I can’t see how I might be causing it, but it is usually my fault

@Viv please can you check the browser console for errors (or not) shortly after it mentions initReadOnly?

I also get the website displaying (as you posted), but the issue is visible in the call to safeApp.connect() failing (error shown in the OP).

Thanks for the speedy responses. I hope digital ocean are back soon so I can test this. :-/

Update: OK @bochaco, thank you. Maybe some connection issue here then. I will try again later.

Thanks again.

bochaco · March 22, 2018, 6:34pm

happybeing · March 22, 2018, 6:35pm

I don’t see how, it’s happening slightly intermittently, but I’ve done very little before it happens. Will bear it in mind.

StephenC · March 22, 2018, 7:44pm

Hey @happybeing, all 25 proxies are now back online after today’s maintenance so hopefully this means you can now connect successfully
If you are still having problems then it may be down to a separate issue, let us know how you get on.

happybeing · March 22, 2018, 8:57pm

No worries everyone - it was probably my (coding) fault all along - but thanks for helping me home in on it. Looks good now so fingers crossed.

happybeing · March 23, 2018, 2:31pm

Re-opening this as I’m still having issues.

I made some changes aimed at freeing appHandles which has helped, but I think the way the Plume app works is part of the problem.

It reloads itself and re-authorises quite frequently, so I suspect I run out of proxy connections if I’m using them up faster than they get released and become re-usable.

First question - does that sound likely?

Second question… is there a way for me to preserve connections/authorisation between reloads (window.location.reload)?

I may be able to streamline this, but I think this will be a general problem for multi page apps, so would like to know if there are any ways to help with this.

Thanks.

StephenC · March 23, 2018, 5:06pm

Just an update on the security patching by our cloud infrastructure provider, which meant we had to bring nodes down over the last few days - this is now complete, and so the Alpha 2 network is now back up to full capacity.

happybeing · March 23, 2018, 5:14pm

Wasn’t that already the case here?

Do you know the answers to my questions, thanks?

StephenC · March 23, 2018, 5:24pm

Hey @happybeing, my previous message that you linked to was only regarding the 25 proxy nodes, the last 5 of those were patched and put back online at that time. There was a suspicion that having 5 proxy nodes offline at one time could have been causing your issue (but unfortunately it was unavoidable). There were still a load of standard nodes which were in the process of being patched/to be patched at that time, but all are now complete and the network is again at full capacity.

I’m afraid I don’t know the answers to your questions, I’ll need to leave that to the experts to respond to.

bochaco · March 23, 2018, 6:52pm

…while we wait for the experts to respond…

Yes, this can be the case, at the moment only 8 proxies will have your IP in their whitelist, and each proxy allows up to 1 connection per IP, i.e. up to 8 connections from your IP in total.

Apart from that, I personally prefer single-page apps, I’m sure there must be valid reasons for having a multi-page app in some cases/scenarios, but if not, I would consider changing the design to make it single-page app. If it’s not possible, it’s as you said, and it sounds to me the only option is to locally store the credentials/auth URI, and we know the risks and implications of doing that, that I’d personally add it up to the cons for multi-page apps

happybeing · March 23, 2018, 8:33pm

Thanks expert Gabriel

It would help for me to understand a couple of things better.

Firstly, what uses / releases a connection. How many for different things I do in the app - such as safeApp.initialise() / authorise () / connect() / connectAuthorised() free() etc.

And how long might it take for connections to be released (ball park obvs) if I do safeApp.free(), or after a page reloads for example.

Are those the only things which consume /release a connection?

For example, I assume window.location.reload releases them, but how long might it be before they become available? Obviously they aren’t available soon enough for the app to reuse them, but are we talking 5s, 10s, or much longer?

Your advice is good on single page, but my aim is to make it easy to take an existing Solid app and get it working with SAFE with the least amount of modification. So ideally we would be able to stay with the architecture of the original Solid app.

In fact the app I’m working on is a single page app, but it reloads in a few places.

bochaco · March 23, 2018, 9:09pm

Whenever you successfully connect with connect() / connectAuthorised() is when you consume a connection. But you need to also take into account that the browser uses/consumes:

one connection for the authenticator,
another one for the safe-app plugin, i.e. the connection used to fetch safesites
and a third one for the app which takes care of storing your browsing state, you can just deny authorisation to this app if you don’t want it to be consumed by the browser.

Now, the Beaker browser will take care of releasing the connections taken up by a webapp when the page is reloaded, or when the tab is closed. If the webapp is using several connections it can call safeApp.free() to release them as needed. I don’t think it takes too long to have the connection actually freed in the proxy after the request to do so is sent, it should be almost instant I’d say.

Also, any other desktop/standalone app consumes its own connection ofc.

I’m not 100% sure if this is accurate for Peruse at this precise moment, although I would expect it to be the same, but there has been some refactoring recently and we are exploring ideas of re-using some of the connections, so for the sake of you trying to isolate the problem perhaps is better do it with Beaker browser.

happybeing · March 24, 2018, 5:42pm

Thanks Gabriel, very helpful.

The above does not appear to be the case, unless my issue is not simply about having too many simultaneous connections as I believe I am now freeing existing connections before trying to establish a new one.

So my app should only ever be consuming one or two (one new plus one just freed, and awaiting release).

So let’s see how I go now that the proxies are back to full strength…

Latest - problem persists

Using Safe Browser 0.10.0

Doing some tests I still have the problem, so it is NOT solved by the proxies being back up to strength. The results also contradict our thesis.

TEST: First I used my earlier code and created three new blog posts in succession. On the third the save completes but then I get the connection error when trying safeApp.connectAuthorised().

TEST: I updated some of the code (does more freeing of resources) to compare this with the earlier code. Closed the tab (not the whole browser) and then loaded the new site. At least five minutes passed between closing the tab and loading the updated site, but immediately I try safeApp.connectAuthorised() I got the Could not connect to the SAFE Network error.

So it seems that closing the tab did not free up the connections even after waiting five minutes.

TEST: Keeping the browser open, closing site tab, then I log out and back in… and open the site in a new tab… again I get the error as soon as it tries safeApp.connectAuthorised()

TEST: Restarting the browser, opening the site … I get my lives back

So it looks like connections are not becoming available again even five minutes after closing SAFE Browser 0.10.1 tab. This appears to be the same with Peruse.

bochaco · March 27, 2018, 5:47pm

I’ll try to reproduce it and see what’s happening, I’ll share more info once I do that.

EDIT: @happybeing, I can confirm there is an issue with the mechanism to free the handles when a page is refreshed, the one that is triggered when closing the tab is working fine but it gets affected by the other issue, i.e. when the page is refreshed it’s loosing track of the safeApp instances to free so even if you close that tab afterwards it cannot free them. I raised https://maidsafe.atlassian.net/browse/MAID-2602 to fix it and hopefully have a patch soon.

FYI, in case it’s useful for you, I’m using safe://leak.pp1 and safe://noleak.pp1 for verifying this.

happybeing · March 27, 2018, 7:50pm

That’s great although I’m not sure if explains everything because one of the changes I tried was to call safeApp.free(appHandle) immediately before window.location.reload().

It my explain it if once reload() has been called that also nullifies any subsequent calls to safeApp.free() - ie before the next reload(). Do you think?

Thanks for tracking this down. It would be great to have a fix for this.