SAFE Network Dev Update - April 9, 2020

Aha - that’s it. Thanks @danda

4 Likes

OK - that chimes with this error


but if I try
willie@gagarin:/tmp$ safe files get safe://cdn/css/southside.css
[00:00:00] [########################################] 236B/236B (2.84KB/s, 0s) Transfer
Done. Retrieved 1 files to .

then it works fine

2 Likes

I have contemplated extending safe files get to work with immutabledata urls also, however the other subcommands of safe files all work with FilesContainer data, so it breaks the paradigm a little. anyway, It might gain that capability in the future.

6 Likes

@tfa @jlpell is correct here.

Success of command depends on which node sends the information last

This is most likely a limitation of the sans-parsec baby-fleming network. We’re already looking at a few things to be solving this without the need for a slow consensus step so hopefully will get it sorted in a fresh iteration.

We should get this noted and clarified on the latest baby-fleming network page’s known limitations. Thanks for diving in and the detail @tfa! :bowing_man:

5 Likes

Thanks.

I understand this is the answer for the second problem. And what about the first problem? (objects not duplicated on new vaults)

1 Like

That part?

As I understand it that’s likely the same issue. Only that vault having the key balance in the initial… We dont have inter-vault gossip enabled yet (and without parsec it’s not being shared in that fashion. Though not the person on this so not 100% sure TBH. @lionel.faber may be able to shed more light).

2 Likes

Any specific tests you would like run to assist in nailing this? @joshuef @tfa @lionel.faber @bochaco

1 Like

for the issues @tfa notes, there’s not much to be done at the mo in terms of testing. We’re working on some things to reenable consensus and gossip so will get sorted in another testnet iteration :+1: once we’ve that in. Thanks though @Southside!

2 Likes

Even without PARSEC, the objects (Data structs, balances etc.) should be present in all the vaults. I suspect that the vaults might not have formed a section correctly. Although looking at the commands that you have run, everything seems right.

Could you please confirm that in the vaults logs the routing table size is 7?
One more thing to look out for is the port number being used. I see that you have mentioned a port number for the genesis vault. Could you please check if the other vaults are using separate and different ports?
Thanks!

4 Likes

Yes, I confirm the routing table size is 7 and that the port numbers are all different. You can see them by scrolling the log excerpts in my post to the right: Response from: V4(192.168.1.68:NNNNN).

Okay thanks. Is it possible that you might’ve sent the create account request before the other vaults were started?

Could you try creating a fresh account and see if the same issue persists?

Was there no way to just make PARSEC faster?

The procure is exactly as described in my post. Only at the last step I try to create an account (after all 7 vaults were created).

For each vault I waited for the right routing table size to appear, plus some margin until no messages are exchanged anymore.

2 Likes

So you are facing the same issue when creating fresh accounts as well?
If that’s the case then it’s definitely a bug. Because once a section is setup, the client will declare an account successfully created only if it receives a success response from all the vaults.
Edit: The client only looks at the last response.

But on the other hand, if a 3 vaults return success and 4 return failure, then the client will return a failure but the account’s existence is inconsistent between vaults in the section and this is indeed a known limitation of the current testnet.

1 Like

Yes, anytime I tried to create a new account. This was last Sunday. But now I have restarted a new network directly with 7 vaults which doesn’t exhibit this problem. And I don’t want to lose this configuration so I cannot make new tests.

You can see from the logs that the client always received one success response and 6 error responses.

If the success response was the last to be received then the command was successful.

If an error response was the last then the command failed.

Good to know!

Ah yes. Sorry my bad. The client just looks at the last response. I’ll edit my message :+1:

Would you like a fix to be implemented for this?
Client says Success if only all vaults return success? This might bring up some other inconsistencies but it’s definitely an improvement.

1 Like

Ok, client only looking at the last response explains the second problem.

Once again what about the first problem? It shouldn’t have happened according to your remark:

In fact I would like more a fix for this one because if it is corrected in the first place, then the second problem won’t occur.

It may well be possible. But it seems if we don’t need to have strict order on some things then we can lighten the load of what we do need to parsec for (which should speed things up).

6 Likes

Agreed, good idea. Just spitballing here, but have you looked into whether the strict ordering in PARSEC could be relaxed ( as an option depending on use case)?

For example rather than saying ‘this sequence of individual events happened in order’ it would be ‘this sequence of event sets happened in order’.
An ‘event set’ would just be a bag/group of unique unordered events. Perhaps the move to larger and larger blockchain block size is a good analogy?

2 Likes

Thank you for the heavy work team MaidSafe! I add the translation into Bulgarian in the first post :dragon:

10 Likes