Deleted

[patterniha]

when using "AsIs" mode, golang controls how to connect to a "domain" address.

currently, golang use RFC-6555 to connect to the domains, although it is obsolete, but it is better than nothing. it solve the problem when one IP-type is unreachable. but regardless of the IP type, some IPs may not be available, thus RFC 8305 was created #4473 (comment)

RFC 6555 is obsoleted by RFC 8305, and python use RFC-8305 from v3.8.

///

anyway, It doesn't matter what RFC is implemented for the "AsIs" mode, because we should use built-in-dns to bypass GFW DNS spoofing,
and for "useIP/forceIP" mode, we don't even have RFC-6555, and only one random IP is selected.

even Xray-core cannot detect user network and for IPv4-only network, an IPv6 can be chosen!(we can use forceIPv4v6 for this problem but this makes IPv4 always a priority)

and also Iran-GFW blocked some range-IPs of meta(facebook, instagram,...) and some not, so with happy-eyeballs iranian-users can access instagram without using any server.(in 99% cases)

as a result, I implemented Happy Eyeballs RFC-8305 for "forceIP/useIP" mode.

///

because happy eyeballs only applies when sockopt-domainStrategy is "forceIP/useIP" and this options are in "sockopt" settings, so i put "happyEyeballs" settings in "sockopt" settings.

///

we can use happy eyeballs for all type of proxy: freedom, vless, ...

///

"streamSettings": {
  "sockopt": {
    "domainStrategy": "forceIP",
      "happyEyeballs": { 
              "enabled": true,
              "prioritizeIPv6": true, 
              "maxConcurrentTry": 4,
              "tryDelayMs": 250,
              "interleave": 1
       }
     }
   } 

///

enabled (bool): enable/disable happy eyeballs, default is false (but i think it should be enabled by default later)

prioritizeIPv6 ( bool): indicate "First Address Family" in RFC-8305, default is false

interleave (uint32): indicate "First Address Family count" in RFC-8305, default is 1

maxConcurrentTry (uint32): maximum concurrent attempt (this is only maximum and in most cases our concurrent attempts is less, unless all connection fail to connect) also we can always have a maximum of concurrent-attempt as many IPs as we have, and this option is useful when the number of IPs is too high, and we want to control the number of concurrent-attempts, default is 4.

tryDelayMs: delay time between each attempt, RFC-8305 recommend 250ms, so the default is 250ms

///

for example suppose our IP-list is [ip4-1, ip4-2, ip4-3, ip4-4, ip6-1, ip6-2, ip6-3, ip6-4]

when interleave is 1 and prioritizeIPv6 is false, the sorted-ip-list is:
[ip4-1, ip6-1, ip4-2, ip6-2, ip4-3, ip6-3, ip4-4, ip6-4]

and when for example interleave is 2 and prioritizeIPv6 is true:
[ip6-1, ip6-2, ip4-1, ip4-2, ip6-3, ip6-4, ip4-3, ip4-4]

then delay 250ms for each attempt until first connection is established.

the first-stablished-connection is winner connection and selected for sending/receiving data.

[xqzr]

它是否适用于 QUIC？

[patterniha]

Does it work with QUIC?

No, it is implemented in dialer layer, and only TCP can be use it.
Because quic is udp and udp is connection less.

For quic we need to implement it at higher level.(and just for non-freedom outbounds)

Anyway, Happy eyeballs has two important algorithms, sort-IP algorithm and Race algorithm, both of them can be reused for QUIC.

[patterniha]

@RPRX

Happy eyeballs is just two simple algorithms sort-IP algorithm and race algorithm, It's very easy to check them.

Also, You forgot to return error for ForceIP mode when no ip is found, and wrongly, ForceIP mode had no difference with useIP mode.(for sockopt-domainStrategy)

In addition, you forgot to return error when user misspelled the outbound-tag-name in dialerProxy.(wrongly, you ignore dialerProxy in such a situation and the user mistakenly thought everything was working properly).

///

That's all I did in this PR. I don't know why it took so long to merge.

[RPRX]

You

印象中你提到的这两处代码应该不是我写的，如果可以的话，能否拆分 PR

That's all I did in this PR. I don't know why it took so long to merge.

只是最近时间少，合理的 PR 最终都会 merge

[patterniha]

If possible, can you split the PR?

@RPRX

They are dependent on each other and cannot be separated because the second PR must be based on the first PR, not based on XTLS:main.

[patterniha]

@RPRX

Ok, I open this PR after "sockopt-dialerProxy" and "sockopt-forceIP" bugs are fixed in #4661