-
Notifications
You must be signed in to change notification settings - Fork 293
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Connectivity graph #17
Comments
This adds snapshot and restore methods to state and uses the snapshot one to save a copy of the state when shutting down. Right now, this is not used for anything else. Some lines performing a migration, but this is only an idea of how it could work. License: MIT Signed-off-by: Hector Sanjuan <hector@protocol.ai>
This adds snapshot and restore methods to state and uses the snapshot one to save a copy of the state when shutting down. Right now, this is not used for anything else. Some lines performing a migration, but this is only an idea of how it could work. License: MIT Signed-off-by: Hector Sanjuan <hector@protocol.ai>
This adds snapshot and restore methods to state and uses the snapshot one to save a copy of the state when shutting down. Right now, this is not used for anything else. Some lines performing a migration, but this is only an idea of how it could work. License: MIT Signed-off-by: Hector Sanjuan <hector@protocol.ai>
This adds snapshot and restore methods to state and uses the snapshot one to save a copy of the state when shutting down. Right now, this is not used for anything else. Some lines performing a migration, but this is only an idea of how it could work. License: MIT Signed-off-by: Hector Sanjuan <hector@protocol.ai>
This adds snapshot and restore methods to state and uses the snapshot one to save a copy of the state when shutting down. Right now, this is not used for anything else. Some lines performing a migration, but this is only an idea of how it could work. License: MIT Signed-off-by: Hector Sanjuan <hector@protocol.ai>
This adds snapshot and restore methods to state and uses the snapshot one to save a copy of the state when shutting down. Right now, this is not used for anything else. Some lines performing a migration, but this is only an idea of how it could work. License: MIT Signed-off-by: Hector Sanjuan <hector@protocol.ai>
@hsanjuan @dgrisham Below is a proposal of one way this could be done. @hsanjuan I know you have been thinking about this for a relatively long time so I am interested to hear your thoughts and suggestions for improvement. Send me your feedback! Drawing out the full connectivity graph in ascii art of a varying number of cluster and ipfs nodes is difficult. I propose that the connectivity display instead show very simple responses in the case where everything is healthy. Then in the case where nodes are unexpectedly disconnected it should show the connectivity graphs and broken links for each of these nodes one at a time. Furthermore I propose breaking down the prompts into describing cluster node and then ipfs node connectivity. For example in the case where everything is connected:
And in the case where nodes are disconnected:
The command could further take a peer id as an argument e.g. Note that the general approach above could also just list out connected peers and disconnected peers in a table, but I think that visually showing connections and links leads to smoother processing of the information. |
As I see this, the command should generate a DOT file (https://en.wikipedia.org/wiki/DOT_(graph_description_language)). This format can then be used by existing programs (graphviz suite) to print the graph in whatever format is appropiate. For example, once you have the graph definition with all existing connections you can do something like a 'complement' operation to see which paths are missing. Probably it makes sense to provide 3 graphs :
I am not sure how much of this is server-side work or ctl side (the server could provide the necessary lists of connections). Implementing yourself an ascii graph representation might be a greater time sink than this issue deserves... |
Thanks for the feedback, I see your point of view and will ease up on a full blown ascii graph in favor of making a dot file. I'll be working on branch: https://github.com/ipfs/ipfs-cluster/tree/feat/connectivity-graph if anyone is interested in taking a look. |
#291 fixes this |
Need an easy way to list all libp2p nodes involved in cluster (members and IPFS) and see what's connected to what (ideally everything is connected to everything).
The text was updated successfully, but these errors were encountered: