The Topology of Reachability: Mapping the Global Network

[!NOTE] Technical Context: netbase.cpp | Lines 43-49

In lines 43 through 49 of netbase.cpp, the software begins the implementation of its Address Resolution logic. This block introduces the ReachableNets registry and the WrappedGetAddrInfo function—the "Eyes and Ears" of the node that translate human-readable hostnames into reachable network addresses.

1. ReachableNets g_reachable_nets: The Map of the World

Line 43 defines g_reachable_nets. In Bitcoin Core, a network (like IPv4 or Tor) is only useful if the node can actually "reach" it.

The Concept of Reachability

Not all nodes have access to the full internet.

• A node behind a restrictive firewall might only reach IPv4.

• A node running on a high-security server might only reach Onion (Tor) services.

• A node in a corporate LAN might have zero direct internet access.

ReachableNets is the internal registry that tracks which networks are "Open" for this specific node. This prevents the node from wasting time trying to connect to .onion addresses if Tor is not configured, or attempting to use IPv6 if the ISP doesn't support it. It is the "Topological Map" that guides all routing decisions.

2. WrappedGetAddrInfo: The Controlled Inquiry

Line 45 introduces WrappedGetAddrInfo. This is a "Wrapper" around the standard C library function getaddrinfo().

In standard C, getaddrinfo() is powerful but dangerous. It can perform DNS lookups, which, as we discussed in Part 036, can leak privacy. By "Wrapping" this function, the Bitcoin architect can enforce strict rules on how and when the node is allowed to look up addresses.

The allow_lookup Parameter

The function takes a Boolean allow_lookup. This is the "Safety Pin." If this is false, the wrapper will only return an address if the name is already an IP address (like 192.168.1.1). If the name is a hostname (like google.com), the wrapper will refuse to look it up. This ensures that the node's DNS privacy settings are respected at the lowest possible level of the code.

3. addrinfo ai_hint: Guiding the Search

Line 47 initializes the addrinfo structure: addrinfo ai_hint{};.

This is a "Hint" to the Operating System's networking stack. It tells the OS: "I am looking for a specific kind of address." By initializing it with {} (zero-initialization), the developer ensures that the struct starts in a "Clean State," preventing garbage data from leading to a "Search Error."

4. ai_socktype = SOCK_STREAM: The Streaming Guarantee

Line 49 contains a critical architectural requirement: ai_hint.ai_socktype = SOCK_STREAM;.

Why SOCK_STREAM?

In internet networking, there are two main types of communication: UDP (Datagram) and TCP (Stream).

• UDP is fast but "unreliable" (packets can arrive out of order or go missing).

• TCP is a "Stream" (SOCK_STREAM). It guarantees that data arrives in the exact order it was sent, with no missing bytes.

Bitcoin Core is a High-Precision Financial Protocol. We cannot afford for a single byte of a transaction or a block to go missing. Therefore, the entire Bitcoin network is built on Streams. By hardcoding SOCK_STREAM in the address lookup hints, the architect ensures that the node only finds addresses that support the reliable TCP protocol required for blockchain consensus.

5. Architectural Synthesis: The Filtered Perspective

Lines 43-49 represent the "Filtered Perspective" of the node.

• The Filter: ReachableNets (only look for what we can reach).

• The Guard: allow_lookup (only look up if we have permission).

• The Protocol: SOCK_STREAM (only look for reliable TCP paths).

This is "Precision Engineering" applied to networking. Instead of just "asking the internet for an address," the Bitcoin node carefully defines exactly what it wants, how it wants it, and what risks it is willing to take. This level of control is why Bitcoin is the most resilient P2P network in the world.

Conclusion: The First Step of a Connection

Lines 43-49 are the first step in the journey of a network packet. Before a single bit can be sent, the node must first "Map the World" and find a valid, reliable, and privacy-preserving path to a peer. With the WrappedGetAddrInfo function, we have the "Safe Eyes" needed to begin that journey.

In Article 0038, we will continue the implementation of this wrapper and see how the node handles the results of its network inquiries.