Show list of peers in debug window #4133

1. 
   laanwj commented at 8:03 am on May 6, 2014: member

   A tab in the debug window that shows the currently connected peers (with their address, port, connect time, starting height, incoming/outgoing, etc…) would be useful.

   n.b.: this information can already be queried through RPC getpeerinfo

2. laanwj added the label GUI on May 6, 2014
3. laanwj added the label Priority Low on May 6, 2014
4. 
   ashleyholman commented at 2:54 pm on May 20, 2014: contributor

   Hi laanwj. I left you a message on IRC but it might be better to track things here.

   I can devote some time to getting this feature implemented, but since I’m new to QT, it would really help me if you could sketch up a really basic design. Just some quick notes in terms of where the model code would go (is a new model class needed?), what GUI widgets to use (QTableView?), and where/when to emit signals to update the GUI.

   I’ve reviewed some previous patches to the debug console, ce14345a (network traffic graph), and 4d3dda5d (button to open debug.log), so I’ve gotten a feel for how the code is structured, but I still feel like I need some design notes for how to best implement this particular feature.

   BTW when I say “design” I just mean the code design, not UI. I’ll just focus on getting the data to appear on a tab at first, then I’ll post screenshots and we could iterate through the UI to get it right.

   Thanks.

5. 
   rebroad commented at 2:57 pm on May 20, 2014: contributor

   It would also be nice if this window could show blocks currently being downloaded by each peer.
6. 
   federicobond commented at 3:43 am on May 21, 2014: contributor

   @ashleyholman I took a look at this issue last week. I wanted to see how far I could go being a complete beginner in C++ and Qt myself, so I dedicated some time to it. I probably won’t be able to finish it, but I can tell you what I found in my quick investigation.

   A new model class is probably needed. I believe you can get it to work using the QStandardItemModel class directly, but subclassing it is probably more elegant and maintainable. UI wise, I guess the best option is to place a QTableView under a new “Connected Peers” tab in the rpcconsole. For updating the view, you can hook initially to the NotifyNumConnectionsChanged() signal and look at the code for getting the peers from the getpeerinfo function in src/rpcnet.cpp. This won’t work for the final implementation though, because peers could change without changing the total number of them. You could modify the code in ThreadSocketHandler from src/net.cpp to also notify when there are any peer changes, regardless of wether the number of connections changed or not.

7. 
   ashleyholman commented at 5:00 am on May 21, 2014: contributor

   @federicobond Thanks for this info. Much appreciated. In regards to updating the view, another option would be to just do a full update of the table every 1 second, by calling the CopyNodeStats() function that the “getpeerinfo” rpc command currently uses. Of course, the calls should only be made while the GUI widget is visible. This may or may not result in less overhead, depending on the amount of socket activity, but at least this would cap the overhead to O(vNodes.size()) per second, and wouldn’t require modifying any of the network handling code to emit signals.
8. 
   laanwj commented at 6:06 am on May 21, 2014: member

   @ashleyholman Thanks for picking this up. You’re on the right track. For polling node statistics it makes sense to just update them at regular intervals. Indeed, to probe every second or so.

   Like the other GUI polling functions we’d want to make this poll optional. Start the timer handler with a TRY_LOCK on cs_vNodes, and if you don’t get the lock, skip this update this time. This avoids hanging the GUI thread on the lock. You can release the lock immediately after copying the data.

   You could use the NotifyNumConnectionsChanged() signal as @federicobond mentions to be notified when new nodes could be added or nodes disconnected instantly. This would introduce a possible DoS risk because a node could connect/disconnect 100s of times per second, updating the table every time.

   (this is always a compromise; at some point with continuous or fast-changing statistics polling is preferable to change notifications; a thermometer that sends a message every time the temperature changes would clog up all bandwidth)

   Just some quick notes in terms of where the model code would go (is a new model class needed?)

   Maybe a PeerTableModel that is part of the ClientModel. It could live in its own cpp/h files.

   what GUI widgets to use (QTableView?)

   What GUI to use is up to you :) In my mind there would be a table that shows the most important statistics for every node, and maybe a details window/pane that can show the nitty gritty details that don’t fit into the table.

   Indeed, using QTableView would be consistent with what is used for the transactions list, address lists, etc. It’s also easiest to get a grid of information that way. @rebroad That would be useful, but I’d prefer if that is handled in a separate pull that adds that information to the RPC first. When first adding this to the GUI let’s show what is in getpeerinfo already, so that the change is manageable.

9. ashleyholman referenced this in commit ef267c49be on May 23, 2014
10. ashleyholman referenced this in commit 1539262709 on May 24, 2014
11. ashleyholman referenced this in commit 9a1da58eda on May 24, 2014
12. ashleyholman referenced this in commit 644d615b2f on May 24, 2014
13. ashleyholman referenced this in commit f0196f66f7 on May 24, 2014
14. ashleyholman referenced this in commit 38ffb1c5c3 on Jun 2, 2014
15. ashleyholman referenced this in commit 65f78a111f on Jun 3, 2014
16. laanwj referenced this in commit 4c097f9669 on Jun 3, 2014
17. laanwj closed this on Jul 4, 2014

    ---

18. MathyV referenced this in commit c726baac02 on Nov 3, 2014
19. wtogami referenced this in commit 1e50e37a94 on Nov 14, 2014
20. wtogami referenced this in commit e7dcdb1ee3 on Dec 23, 2014
21. reddink referenced this in commit f65b572cc3 on Jun 4, 2016
22. reddink referenced this in commit 479a828d0a on Jul 28, 2016
23. reddink referenced this in commit fd1f6e0486 on Aug 4, 2016
24. nextux referenced this in commit 0209925cf3 on Mar 20, 2018
25. nextux referenced this in commit bd96d16663 on Mar 20, 2018
26. MarcoFalke locked this on Sep 8, 2021

Contributors
laanwj ashleyholman rebroad federicobond

Labels
GUI