The Cleanup of the Kernel and the Global Callback

[!NOTE] Technical Context: netbase.cpp | Lines 92-98

In lines 92 through 98 of netbase.cpp, we conclude the WrappedGetAddrInfo function and establish the Global Delegate for DNS resolution. This block is a study in Resource Management, Memory Finalization, and the Dependency Injection Pattern.

1. freeaddrinfo(ai_res): Releasing the Kernel's Grip

Line 93 is the most critical line for the long-term health of the node: freeaddrinfo(ai_res);.

The Responsibility of the Caller

As we discussed in Part 039, the getaddrinfo system call allocates memory on the heap. In the C language, the OS "borrows" some of your RAM to store the address results. If you don't explicitly "Return" that memory using freeaddrinfo, it is "Leaked" forever.

A Bitcoin node is designed to run for years without restarting. If it leaked even a few bytes on every peer connection, it would eventually crash the computer. By calling freeaddrinfo immediately after the loop, the architect ensures that the node's Memory Footprint remains constant and lean. It is "Sanitary Engineering" for the internet.

2. The Final Return: resolved_addresses

Line 95 returns the vector: return resolved_addresses;.

This is the transition from "Raw C" to "Safe C++." The memory we just freed was the OS's internal format; the data we are returning is our own, type-safe, and reference-counted CNetAddr objects. The caller of WrappedGetAddrInfo never has to worry about system calls or memory leaks; they simply receive a clean list of addresses to connect to.

3. DNSLookupFn g_dns_lookup: Dependency Injection

Line 98 is a major architectural milestone:

Copy

DNSLookupFn g_dns_lookup{WrappedGetAddrInfo};

What is a Global Delegate?

DNSLookupFn is a function pointer (or a std::function). By assigning WrappedGetAddrInfo to this global variable, the architect is using a pattern called "Dependency Injection."

Instead of other parts of the software calling WrappedGetAddrInfo directly, they call g_dns_lookup.

Why do this?

This allows for Unparalleled Testability. During normal operation, g_dns_lookup points to the real networking logic we just analyzed. But during a "Unit Test," a developer can change g_dns_lookup to point to a "Mock" function that returns fake IP addresses. This allows the developers to test the Bitcoin node's networking logic without ever needing a real internet connection. It is the "Plug-and-Play" architecture of a world-class protocol.

4. Architectural Synthesis: The Completed Resolver

The completion of this function marks the end of the "Discovery Phase" of the network stack.

• The Ingress: Hostnames and IP strings.

• The Processing: The 5-stage getaddrinfo negotiation.

• The Egress: A clean vector of CNetAddr objects.

• The Registry: The global g_dns_lookup delegate.

This is a "Universal Resolver." It is private, resilient, and highly portable. It is the "Eye" of the Bitcoin node, and it is now fully open and functional.

Conclusion: From Resolution to Interaction

Lines 92-98 represent the "Formal Finalization" of the address resolution sub-module. We have cleaned up our resources and registered our capability with the rest of the node.

In Article 0045, we will begin the exploration of the SOCKS5 proxy protocol—the code that allows a Bitcoin node to tunnel its traffic through Tor and other privacy networks.