Comments (10)
This certainly requires a unit test in that rs file for sure.
from crust.
Looks like the code is doing the right thing, overwriting the cache file if it can't read/parse it.
An extra ,
after the last element should not be provided (it fails parse).
Just connected crust_peer to droplets using the same file (removed ,
after last element of vector)
prakash@machine:~/rust/crust (master)$ cargo run --example crust_peer
Running `target/debug/examples/crust_peer`
Listening for new connections on Tcp(5483), and listening for UDP broadcast on port 9999.
Bootstrapped to Tcp(V4(178.62.7.96:5483))
Connected to peer at Tcp(V4(178.62.7.96:5483))
1 connected node: Tcp(V4(178.62.7.96:5483))
Enter command (stop | connect <endpoint> | send <endpoint> <message>)>
Received from Tcp(V4(178.62.7.96:5483)) message: non-UTF-8 message of 6 bytes
Enter command (stop | connect <endpoint> | send <endpoint> <message>)>
Connected to peer at Tcp(V4(45.55.207.180:5483))
2 connected nodes: Tcp(V4(178.62.7.96:5483)) Tcp(V4(45.55.207.180:5483))
Enter command (stop | connect <endpoint> | send <endpoint> <message>)>
Enter command (stop | connect <endpoint> | send <endpoint> <message>)>
Received from Tcp(V4(45.55.207.180:5483)) message: non-UTF-8 message of 6 bytes
Enter command (stop | connect <endpoint> | send <endpoint> <message>)>
from crust.
I will add a log statement to say its fails to read the file. Also there is a test already to write and read the file.
from crust.
Valid bootstrap cache file
{
"preferred_port": {
"variant": "Tcp",
"fields": [
5483
]
},
"hard_coded_contacts": [
{
"endpoint": "45.55.207.180:5483"
},
{
"endpoint": "178.62.7.96:5483"
},
{
"endpoint": "128.199.199.210:5483"
},
{
"endpoint": "37.59.98.1:5483"
},
{
"endpoint": "45.79.93.11:5483"
},
{
"endpoint": "45.79.2.52:5483"
}
],
"contacts": [
{
"endpoint": "45.55.207.180:5483"
},
{
"endpoint": "178.62.7.96:5483"
},
{
"endpoint": "128.199.199.210:5483"
},
{
"endpoint": "37.59.98.1:5483"
},
{
"endpoint": "45.79.93.11:5483"
},
{
"endpoint": "45.79.2.52:5483"
}
]
}
from crust.
I have re-opend this issue as I think the app should exit with a message stating the file is invalid, allowing the user to fix or delete it. The return code should indicate invalid boostrap-cache file
from crust.
Are you talking about Crust invoking something like std::process::exit
? If so, it seems a bit ferocious to me! I guess the issue is that the bootstrap process could still succeed via the beacon despite the bootstrap file being corrupted.
I suppose for our normal use (i.e. where we're not tinkering around with the file for testing purposes) it would be unlikely that the file would be corrupted, and such a problem is maybe serious enough to warrant termination. But I'm not sure if that should be forced on all users of Crust.
Maybe a middle ground of abandoning the bootstrap process by returning an Err
would be best?
from crust.
Yes it's normal for a process with a config file to abort on file read error. Apache, ftp servers, mail servers etc. all would do that as it means the user may have been trying to set something and did it wrong. So I think it's an expected thing to happen. Personally I would go for exit with a negative return code as we cannot tell if a user is trying to alter the file or if it's actually corrupted, or they have just made a mistake. We could add an option to start again with over-write etc. but then again maybe that's just taking it to far.
from crust.
It may be the file needs split, a config part where we would exit and purely cache part where we would over-write.
from crust.
+1 for the split between config and cache. I will detail a task to address this.
from crust.
Added JIRA task to address this issue.
https://maidsafe.atlassian.net/browse/MAID-1149
from crust.
Related Issues (20)
- Generate Crust ID ourselves
- Dynamic connections manager
- Remove message priorities HOT 1
- Report about dropped messages HOT 2
- Solve head of line blocking HOT 1
- Simplify bootstrap cache
- External reachability test should not make a connection attempt fail
- Unable to connect to local peer on localhost in example HOT 3
- Connection attempt fails HOT 6
- Message Splitting HOT 1
- Remove CrustUser
- Remove PrivConnectionInfo
- Rename prepare_connection_info
- Remove (dis)connect API and make the Send API take peer-information
- Connection Pool
- Is there a method to obtain a peer port. (Q&A)
- Exhaustively Document the nat traversal techniques used.
- Example Code HOT 1
- Fix dyn issues on 1.37
- Is moving to futures and async/await being considered?
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from crust.