psi-plus
Psi+ всегда предпочитает IPv6 даже если TCP стек сконфигурён предпочитать IPv4, это плохо с туннелем
Original issue 594 created by psi-plus on 2014-09-30T23:40:54.000Z:
Шаги по воспроизведению проблемы:
- Запускаем Psi+ видим, что лезет на сервер по IPv6
Каков ожидаемый результат? Лезет согласно предпочтениям, выставленным в TCP стеке, если там предпочитать IPv4, то делать так же. В винде стоит предпочитать IPv4, как видно из:
netsh interface ipv6 show prefix Querying active state...
Precedence Label Prefix
50 0 ::ffff:0:0/96
40 1 ::1/128
30 2 ::/0
20 3 2002::/16
10 4 ::/96
5 5 2001::/32
И все программы это понимают, кроме Psi+.
Что Вы видите вместо этого? Лезет всегда по IPv6
Какую версию Psi+ / ОС Вы используете? 0.16.361 Win7 Ultimate SP1
Дополнительная информация по проблеме: На IPv6 стоит туннель, оно коннектица и работает, но едет долго через Америку и Германию, вместо того, чтобы ехать короче по IPv4 без туннеля. Кроме того, передача файлов едет медленно через файловый прокси вместо напрямую, поскольку другая сторона обычно без IPv6.
Способа не нужно. Если задано предпочтение, список адресов getaddrinfo() автоматически сортируется согласно нему, в соотв. с https://datatracker.ietf.org/doc/rfc6724/?include_text=1 Задача Psi+ просто пройти по списку до первого успеха, не занимаясь самодеятельностью.
Это как минимум для *nix и, наверное, макоси, потому что там стек от BSD. Под windows таблица предпочтений выглядит как в RFC, получить её можно через
netsh interface ipv6 show prefix
а вот есть ли там getaddrinfo() или как называется его аналог - не знаю. Но что-то есть, поскольку предпочтение работает при коннекте на dual-stack сайты (не из Psi+).
так уж сложилось что мы не используем getaddrinfo. у нас есть свой резолвер. почему свой? думаю потому что оригинальным разработчикам хотелось что-то прикрутить для dns на маке (avahi like). настоящих причин не знаю.
на данный момент добавлен алгоритм happy eyeballs, который из-за выших задержек по ipv6 таки может подключить вас по ipv4. но как бы там не было happy eyeballs решает другую проблему.
getaddrinfo думаю есть везде.
Тут есть 2 решения, правильное и радикальное. Правильное - имплементировать в своём резолвере RFC 6724, но тут кроссплатформенного способа точно нет и не будет, везде придётся по-разному. Радикальное - выкинуть свой резолвер и юзать getaddrinfo(). Всё (и не только это) заработает автоматом, да и стремительно стареющего неподдерживаемого кода меньше будет.
ну меня были примерно те же выводы. впрочем скоро перелазим на qt5 и там наш резолвер по больше части не понадобится.
Кста, вот какая ситуация получается как следствие, c File Transfer на машине dual-stack. Если сервер jabber.ru, коннекция к нему идёт по ipv6 потому что см. всё выше и он тоже dual-stack. Так вот, в XML запроса выходящего файл трансфёра передаётся тоже только этот ipv6 адрес. А с другой стороны машина ipv4. Она обламывается, о чём диагностика про невозможность подключиться к NAT что-то, c двух сторон. Лечится прописыванием ipv4-only dynamic dns в поле "Внешний адрес для передачи данных", но это костыли. Оно тогда сначала всё равно с той стороны лезет на ipv6, обламывается и потом на указанный ipv4 dynamic dns (он передаётся вторым почему-то). Всех просить прописать proxy.jabber.ru невозможно, многие клиенты просто не умеют, и оно бывает не работает само по себе.
Собственно, оно могло бы использовать STUN, который у меня прописан и получить само адрес ipv4 который можно выдавать для File Transfer.
@Neustradamus we use qt resolver now. But still our own HappyEyesballs which prefers IPv6. Even so I tried to connect both ipv4 and 6 almost parallel.
Wrt using STUN for file transfer, we use it with WebRTC datachannels. But AFAIK only Psi supports it, so transferring to other clients may still be problematic. Using STUN with socks5 will probably force us to use socks5 only in UDP mode.