net: transport abstraction #28165

[rajarshimaitra]

Session Details

• Date: 07-09-2023
• Time: IST 20:00 (UTC 14:30)
• PR: net: transport abstraction bitcoin/bitcoin#28165
• Context: [net][p2p]
• Difficulty: Moderate
• Language: [c++]
• Notes and Questions: Coming Soon

Summary

This PR furthers the P2P message serialization/deserialization abstraction introduced in bitcoin/bitcoin#16202 and bitcoin/bitcoin#16562, in preparation for teaching the BIP324 v2 transport (making this part of bitcoin/bitcoin#27634). However, nothing in this PR is BIP324-specific, and it contains a number of independently useful improvements.

Learning

• P2P message handling.
• in-depth into netprocessing.cpp.

Note: Drop your PR and review related questions below

[stratospher]

Notes

• Bitcoin nodes communicate by exchanging lots of different P2P messages. P2P messages get converted into wire bytes which are then sent over.

• P2P messages -> wire bytes and wire bytes -> P2P messages conversion is now handled by a single Transport class which does both sending and receiving.

• Currently, the P2P messages are unencrypted and any passive observer with access to the wire bytes can figure out the P2P messages exchanged between nodes. We'll refer to this P2P transport protocol as v1 P2P here.

• v1 P2P starts with version handshake where the initiator node sends a "version" P2P message and expects a "verack" P2P message back.

• wire bytes format for V1 P2P message:
  

• BIP 324 introduces a new P2P protocol which can send encrypted P2P messages. We'll refer to this P2P transport protocol as v2 P2P here.

• wire bytes format for V2 P2P message:
  

• v2 P2P starts with a DH key negotiation phase to compute the encryption keys and then carries on with the version handshake.

• This PR merges the TransportDeserializer(receiving side) and TransportSerializer(sending side) classes into a single Transport class in preparation for V2Transport. This is done because sending side and receiving side are dependent on each other during the DH key negotiation in V2Transport.

Questions

1. Did you review the PR? Concept ACK, approach ACK, tested ACK, or NACK? What was your review approach?
2. What are the different net threads? what do they do?
   • HINT: https://github.com/bitcoin/bitcoin/blob/d2ccca253f4294b8f480e1d192913f4985a1af08/doc/developer-notes.md#threads
     
3. What's the difference between net and net processing? HINT: notes in https://bitcoincore.reviews/20721
4. How has the sending logic changed for v1 P2P?
   • HINT: in SocketSendData(), notice usage of SetMessageToSend, GetBytesToSend and MarkBytesSent. Previously, SocketSendData() did not use these. What advantages do using these new functions provide?
   • V1 message checksum calculation now happens in SetMessageToSend guarded by cs_vSend lock at it's call site in SocketSendData(). Previously, it happened in prepareForTransport() in PushMessage() which wasn't guarded by this lock.
   • what are optimistic/non-optimistic sends?
5. what does PushMessage() and SocketSendData() do? where does the actual sending happen?
   • HINT: PushMessage() before vs now, SocketSendData() before vs now

[stratospher]

call graph for SocketHandlerConnected() in net thread:

before	now