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
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
Strange. I cloned and built but it won’t connect to SN (0.10.1 is fine though). The browser starts up but I’m getting Core error: Unexpected: Could not connect to the SAFE Network when I try to log in.
Linux 64 bit
nodejs 8.0.0
I did yarn run build && yarn run package
Trying yarn run burnthemall I’m getting some warnings (didn’t see these earlier)…
warning appdmg@0.4.5: The platform "linux" is incompatible with this module.
warning fsevents@1.1.3: The platform "linux" is incompatible with this module.
[1/2] ⢀ electron
[2/2] ⢀ fs-xattr: spawn args '-Goutput_dir=.' ]
[-/2] ⢀ waiting...
[-/2] ⢀ waiting...
warning Error running install script for optional dependency: "/home/mrh/.cache/yarn/v1/npm-fs-xattr-0.1.17-ee943483c6fe9704a8f0e1476e8145a9886f8b0f: Command failed.\nExit code: 1\nCommand: sh\nArguments: -c node-gyp rebuild\nDirectory: /home/mrh/.cache/yarn/v1/npm-fs-xattr-0.1.17-ee943483c6fe9704a8f0e1476e8145a9886f8b0f\nOutput:\ngyp info it worked if it ends with ok\ngyp info using node-gyp@3.6.1\ngyp info using node@8.0.0 | linux | x64\ngyp info spawn /usr/bin/python2\ngyp info spawn args [ '/home/mrh/.nvm/versions/node/v8.0.0/lib/node_modules/npm/node_modules/node-gyp/gyp/gyp_main.py',\ngyp info spawn args 'binding.gyp',\ngyp info spawn args '-f',\ngyp info spawn args 'make',\ngyp info spawn args '-I',\ngyp info spawn args '/home/mrh/.cache/yarn/v1/npm-fs-xattr-0.1.17-ee943483c6fe9704a8f0e1476e8145a9886f8b0f/build/config.gypi',\ngyp info spawn args '-I',\ngyp info spawn args '/home/mrh/.nvm/versions/node/v8.0.0/lib/node_modules/npm/node_modules/node-gyp/addon.gypi',\ngyp info spawn args '-I',\ngyp info spawn args '/home/mrh/.node-gyp/8.0.0/include/node/common.gypi',\ngyp info spawn args '-Dlibrary=shared_library',\ngyp info spawn args '-Dvisibility=default',\ngyp info spawn args '-Dnode_root_dir=/home/mrh/.node-gyp/8.0.0',\ngyp info spawn args '-Dnode_gyp_dir=/home/mrh/.nvm/versions/node/v8.0.0/lib/node_modules/npm/node_modules/node-gyp',\ngyp info spawn args '-Dnode_lib_file=node.lib',\ngyp info spawn args '-Dmodule_root_dir=/home/mrh/.cache/yarn/v1/npm-fs-xattr-0.1.17-ee943483c6fe9704a8f0e1476e8145a9886f8b0f',\ngyp info spawn args '-Dnode_engine=v8',\ngyp info spawn args '--depth=.',\ngyp info spawn args '--no-parallel',\ngyp info spawn args '--generator-output',\ngyp info spawn args 'build',\ngyp info spawn args '-Goutput_dir=.' ]\nmodule.js:487\n throw err;\n ^\n\nError: Cannot find module 'nan'\n at Function.Module._resolveFilename (module.js:485:15)\n at Function.Module._load (module.js:437:25)\n at Module.require (module.js:513:17)\n at require (internal/module.js:11:18)\n at [eval]:1:1\n at ContextifyScript.Script.runInThisContext (vm.js:44:33)\n at Object.runInThisContext (vm.js:116:38)\n at Object.<anonymous> ([eval]-wrapper:6:22)\n at Module._compile (module.js:569:30)\n at evalScript (bootstrap_node.js:432:27)\ngyp: Call to 'node -e \"require('nan')\"' returned exit status 1 while in binding.gyp. while trying to load binding.gyp\ngyp ERR! configure error \ngyp ERR! stack Error: `gyp` failed with exit code: 1\ngyp ERR! stack at ChildProcess.onCpExit (/home/mrh/.nvm/versions/node/v8.0.0/lib/node_modules/npm/node_module
The build completes but still won’t connect when I try to log in.
You must be just missing the crust.config file, you can copy from v0.10.1 or you can also find a copy under ./build/SAFE Browser.crust.config and you need to copy over as ./dist/safe-browser-v0.10.1-linux-x64/safe-browser.crust.config. You may want to also copy the log.toml file onto the same folder.
