The Protocol Choice and the Family of Addresses

[!NOTE] Technical Context: netbase.cpp | Lines 50-56

In lines 50 through 56 of netbase.cpp, the architect continues the fine-grained configuration of the getaddrinfo wrapper. This block is a study in Protocol Strictness and Address Agnosticism. It defines exactly how the Bitcoin node wants to speak to the internet and how it handles the diversity of modern network protocols.

1. ai_protocol = IPPROTO_TCP: The Sacred Transport

Line 50 explicitly sets the protocol: ai_hint.ai_protocol = IPPROTO_TCP;.

Why hardcode TCP?

As we discussed in Part 037, Bitcoin requires a reliable stream of data. While SOCK_STREAM (the socket type) usually implies TCP, it isn't a guarantee (other stream protocols like SCTP exist).

By explicitly specifying IPPROTO_TCP, the architect is "Double-Locking" the protocol. It ensures that even if the host computer has exotic networking protocols installed, the Bitcoin node will only ever attempt to communicate using the Transmission Control Protocol (TCP). This is the "Industry Standard" of the internet, ensuring maximum compatibility across all routers, firewalls, and ISPs.

2. ai_family = AF_UNSPEC: The Agnostic Search

Line 52 sets the address family: ai_hint.ai_family = AF_UNSPEC;.

IPv4 vs. IPv6

In networking, AF_INET refers to IPv4 (the old 32-bit addresses) and AF_INET6 refers to IPv6 (the new 128-bit addresses).

AF_UNSPEC (Address Family Unspecified) tells the Operating System: "I don't care which one you give me. If the peer has an IPv4 address, give me that. If they have an IPv6 address, give me that too."

This is the "Dual-Stack" philosophy of Bitcoin Core. By remaining agnostic, the node can bridge the gap between the old internet and the new internet. It allows a user on an IPv4-only network to talk to a peer on an IPv6-enabled network through a single, unified interface. It is a commitment to Global Interconnectivity.

3. The AI_ADDRCONFIG Philosophy

Lines 54-56 contain a profound comment about the AI_ADDRCONFIG flag.

What is ADDRCONFIG?

On many computers, the OS might "think" it has IPv6 support, but it doesn't actually have a global IPv6 address. If the node asks for all addresses, the OS might return an IPv6 address that is physically unreachable, leading to a "Connection Timeout" and a bad user experience.

AI_ADDRCONFIG tells the OS: "Only return IPv6 addresses if I actually have a working IPv6 connection on my machine. Otherwise, don't waste my time." This is an Optimization for Real-World Networks. It ensures that the node only attempts connections that have a physical chance of succeeding, based on the node's own local configuration.

4. Architectural Synthesis: The Intelligent Handshake

These lines show that the WrappedGetAddrInfo function is not a passive mirror of the system's getaddrinfo. It is an Active Filter.

• It filters for Reliability (IPPROTO_TCP).

• It filters for Availability (AI_ADDRCONFIG).

• It embraces Diversity (AF_UNSPEC).

This is how you build "Developer-Grade" software for an unpredictable world. You don't just "try everything"; you use the system's own metadata to prune the search space, ensuring that the node's resources are focused on the most likely paths to success.

5. Conclusion: The Protocol Anchor

Lines 50-56 are the "Protocol Anchor" of the network stack. They define the "Physics of the Connection"—the mandatory use of TCP and the intelligent handling of IP versions. By setting these hints correctly, the architect ensures that the Bitcoin node is a "First-Class Citizen" of the internet, capable of navigating the complex topology of global routing with maximum efficiency.

In Article 0039, we will see how the allow_lookup flag is implemented to finalize the privacy-preserving nature of this wrapper.