[vim/vim] Improve IPv6/IPv4 fallback in ch_open() (PR #19233)

[thinca]

Summary

This PR implements a simplified version of Happy Eyeballs (RFC 8305) to improve connection fallback behavior when IPv6 is unavailable or slow.

Problem

When ch_open() tries to connect to a hostname that resolves to multiple addresses (e.g., both IPv6 and IPv4), the current implementation:

1. Uses a single waittime for all connection attempts
2. If the first IPv6 connection attempt times out, it consumes almost all of the waittime
3. This leaves insufficient time (often just 1ms) for the IPv4 attempt to succeed
4. Results in connection failures even when IPv4 is available

This is particularly problematic in environments where:

• IPv6 is configured but not actually available for external connections
• IPv6 DNS resolution succeeds but connection attempts fail or timeout

Solution

Distribute the waittime across multiple addresses using a strategy based on RFC 8305:

• First address: use up to 250ms (RFC 8305 Connection Attempt Delay) or half of the total waittime, whichever is smaller
• Middle addresses: divide remaining time equally
• Last address: use all remaining time

This ensures that IPv4 fallback has sufficient time to succeed even when IPv6 connection attempts fail or timeout.

Changes

• Modified channel_open() in src/channel.c to:
  • Count the number of addresses before attempting connections
  • Calculate individual timeout for each address based on its position
  • Track consumed time and update the overall waittime accordingly
  • Stop early if time runs out

Testing

• Existing tests in src/testdir/test_channel.vim pass, particularly Test_connect_waittime() which verifies basic timeout behavior
• Manually tested in environments where IPv6 is unavailable
• The fix ensures connections succeed within the specified waittime

Notes

• This implementation follows the spirit of RFC 8305 (Happy Eyeballs Version 2) but is simplified to fit Vim's existing synchronous connection model
• No breaking changes to the API or behavior; existing code continues to work as before
• The change improves connection reliability in dual-stack environments

---

AI Disclosure: This contribution was developed with assistance from Claude Code (Claude Sonnet 4.5). All code follows the Vim coding style guidelines and has been tested for correctness.

---

You can view, comment on, or merge this pull request online at:

  https://github.com/vim/vim/pull/19233

Commit Summary

• 5568cdd patch: improve IPv6/IPv4 fallback in ch_open()

File Changes

(1 file)

• M src/channel.c (60)

Patch Links:

• https://github.com/vim/vim/pull/19233.patch
• https://github.com/vim/vim/pull/19233.diff

—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/pull/19233@github.com>

[Christian Brabandt]

chrisbra left a comment (vim/vim#19233)

Thanks, can you think of a test for this? I'll move this to after the 9.2 release however.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/pull/19233/c3780757790@github.com>

[thinca]

thinca left a comment (vim/vim#19233)

Thank you for your review! I (with Claude Code) can add tests, but first let me explain the issue.

Current Coverage

The existing Test_connect_waittime() verifies that waittime is respected during connection attempts. This ensures that the timeout distribution logic does not compromise basic behavior.

The Challenge

To specifically test IPv6→IPv4 fallback, we need:

• Hostnames that resolve to both IPv6 and IPv4
• IPv6 that resolves but has delayed/unreachable responses
• Timing measurements across multiple connection attempts

Reproducibility is difficult to ensure in the CI environment (due to IPv6 availability fluctuations, timing dependencies, etc.).

Options

1. Approval of existing test coverage - Test_connect_waittime() verifies the core mechanism
2. Skip/Add Manual Tests - Document behavior but do not automate execution
3. Build Dual-Stack Emulation Server - Implementable if value justified by complexity

Which approach is preferable? Implement Option 3 if deemed important, but want to confirm before adding significant test infrastructure.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/pull/19233/c3782009502@github.com>