LEARN. PRACTICE. GROW.Locate the failing phase
Organize the timeline into address preparation, connection attempt, application acceptance, authentication and business response. In the lab, connect can finish before the server calls accept for that connection. The observation shows neither authentication nor persistence. In a fictional positions service, a health check that only connects to the socket may remain green while the application leaves work unaccepted. Do not conclude this happened in production without metrics, but use the mechanism to choose the next observation: connection, acceptance, reading and outcome are different milestones.
Record each candidate and the selected one
The script reserves and releases a local IPv6 port to create a refused attempt, then tries the known IPv4 listener. It explicitly checks ECONNREFUSED and the FALLBACK-OK response. Because another application could reuse the released port, the script fails if the expected observation does not occur; it does not assume permanent reservation. Record the candidate list, family, address, error and final outcome. One failed attempt does not prove total unavailability when another completes the exchange. Nor does it establish host-wide IPv6 failure: the same experiment’s other IPv6 groups work.
Bound cost and understand the algorithm
The next attempt receives only time remaining from the initial two-second budget. Failed sockets are closed, and no new candidate should start after the deadline. The experiment uses a supplied list and strictly sequential attempts. Happy Eyeballs, described in RFC 8305, includes resolution, ordering and staggered asynchronous attempts that can overlap. Do not present the teaching loop as a complete implementation of that algorithm. In a real client, identify the library and effective policy before promising fallback latency or replacing selection with a fixed address taken from a log.
Compare the context that actually fails
A host test and an application in a network namespace can have different routes, devices and rules. iproute2 documentation describes that isolation and context-specific configuration management. In this block, Linux cases are document-based analysis; no namespaces were created and no Linux commands were executed. To investigate the fictional case, request resolved candidates, source, effective route and error inside the application’s authorized context. Do not copy host routes merely because its test works. Even an explicitly bound source does not establish which gateway was selected or whether return traffic works.
Write a useful English message
Fill the worksheet below for two events: rejection of a name under numeric flags and connection refusal at a numeric candidate. Write what was observed, the impact, the open hypothesis and the next action. Use getnameinfo with numeric flags when collection should retain address and port without requesting reverse names. Keep the originally requested name in a separate field. This is a proposed learner exercise, without a performed human workshop. Shift handover should locate the phase and endpoint; the generic phrase connection failed is insufficient for assigning technical responsibility.
Accept what the evidence demonstrates
The ten groups demonstrate local address, binding, selection and correlation mechanisms. They do not measure real DNS, external paths, NAT, proxies, PMTU, TLS, load or persistence. A quick::1 response does not establish an inter-data-centre SLA. For fictional service acceptance, define a matrix by family, authorized source, endpoint, dependencies and business result. Assign owners to missing exercises and record runtime versions and effective options. When reproducing on another operating system, compare properties without requiring identical internal constant values, ephemeral ports or local indices.
PROPOSED ENDPOINT HANDOVER WORKSHEET
Requested name/configuration:
Runtime, host and network context:
Candidate list: family | transport | address | port | order
Attempt: phase | local endpoint | remote endpoint | elapsed | exact error
Selected candidate and complete application response:
Observed facts:
Business impact and unresolved hypotheses:
Next authorized collection, owner and next update:
Acceptance matrix: family | source | endpoint | dependency | expected result
Example: Numeric-only address preparation rejected a hostname before connect.
Example: One IPv6 candidate was refused; the IPv4 candidate returned FALLBACK-OK.
Scope: local synthetic observations, not external-path acceptance.
No human workshop has been performed.
Simulation: the IPv6 candidate is refused and IPv4 returns FALLBACK-OK. Write an update explaining partial availability and requesting evidence needed to investigate the degraded candidate.
Common pitfalls
Calling every error a timeout, concluding total failure after the first candidate, confusing sequential fallback with Happy Eyeballs or validating an application using only a host test.
Related topics: Addresses, prefixes, and scope · Routes and next-hop resolution · Diagnosis in the application context
Diagnosis follows phase, candidate and context. Recovery should respect the budget, and approval needs representative-path evidence.
Reference: Happy Eyeballs Version 2 · BigSavant TCP/IP 2026-09; TCP RFC 9293; IPv6 RFC 8200 with RFC 9673 update; Linux socket and iproute2 guidance