Implement signals in P2P network code

[xeroc]

User Story We (node operators) want to be able to build a plugin to analze the performance of the P2P network code. For this, we need to be able to obtain metrics (counter, gauge, historgram, summary) that can then be exported, presented and analyised with seprated software.

Possible software to use for this:

• Prometheus / C++ Library

After a quick discussion, the easiest would (probably) be to integrate fc::signals into the p2p network code (to have minimal impact on production machines) and develop a separate plugin that is not loaded by default but does all the heavy lifting. To get this development started (independetly) all devs need are signals from the p2p network code.

Impacts Describe which portion(s) of BitShares Core may be impacted by your request. Please tick at least one box.

• [ ] API (the application programming interface)
• [ ] Build (the build process or something prior to compiled code)
• [ ] CLI (the command line wallet)
• [ ] Deployment (the deployment process after building such as Docker, Travis, etc.)
• [ ] DEX (the Decentralized EXchange, market engine, etc.)
• [X] P2P (the peer-to-peer network for transaction/block propagation)
• [X] Performance (system or user efficiency, etc.)
• [ ] Protocol (the blockchain logic, consensus, validation, etc.)
• [ ] Security (the security of system or user data, etc.)
• [ ] UX (the User Experience)
• [ ] Other (please add below)

Additional Context (optional) None

CORE TEAM TASK LIST

• [X] Evaluate / Prioritize Feature Request
• [ ] Refine User Stories / Requirements
• [ ] Define Test Cases
• [ ] Design / Develop Solution
• [ ] Perform QA/Testing
• [ ] Update Documentation

[nathanielhourt]

Alright, so initially my focus will be on adding signals to the network code which can be used to receive the timestamp and a reference to a buffer of the data whenever a message is sent or received. Then I'll make a plugin that connects to those signals with a fast handler that copies the buffer only if necessary and schedules further processing so the network code unblocks ASAP. This means the signals only get connected if the plugin is loaded, so on production systems that don't load the plugin, the performance hit should be virtually nonexistent; while on systems that do use the plugin, it will be easy to add tasks to process the data as needed without worrying about significantly delaying the network code.

After that framework is in place, we can figure out the prometheus stuff or whatever @xeroc needs to get his data.

[xeroc]

+1

Another potentially interesting though could be the connected nodes and potential nodes or why nodes have been disconnected etc ... (just thinking out loud)

[nathanielhourt]

Yeah, that's quickly evolving into a whole new networking API, which I could try to do... but realistically that'll probably happen when I make a whole new networking layer. In the meantime, though, the more we have documented about what we want from an ideal API to an ideal networking layer, the faster and easier I'll be able to write it when I get down to it.