mirror of
https://gitlab.freedesktop.org/xorg/lib/libxcb.git
synced 2026-05-26 07:28:12 +02:00
4f25ee1644
When a system is completely offline (no interface has an IP address but 'lo'),
xcb could not connect to localhost via TCP, e.g. connections with
DISPLAY=127.0.0.1:0 fail.
AI_ADDRCONFIG will only return IPv4 addresses if the system has an IPv4
address configured (likewise for IPv6). This also takes place when
resolving localhost (or 127.0.0.0/8 or ::1). Also, as per RFC 3493,
loopback addresses are not considered as valid addresses when
determining whether to return IPv4 or IPv6 addresses.
As per mailing-list discussion on the xcb list started with message
20110813215405.5818a0c1@x200, the AI_ADDRCONFIG flag is there for historical
reasons:
In the old days, the "default on-link" assumption in IPv6 made the flag vey
much indispensable for dual-stack hosts on IPv4-only networks. Without it,
there would be long timeouts trying non-existent IPv6 connectivity. Nowadays,
this assumption has been flagged as historic bad practice by IETF, and hosts
should have been updated to not make it anymore.
Then AI_ADDRCONFIG became mostly cosmetic: it avoids phony "Protocol family
not supported" or "Host unreachable" errors while trying to connect to a dual-
stack mode from a host with no support for source address selection.
Nowadays, on up-to-date systems, this flag is completely useless. Then again,
I understood only the very latest MacOS release is "up-to-date" with this
definition.
|
||
|---|---|---|
| .. | ||
| .gitignore | ||
| c_client.py | ||
| Makefile.am | ||
| xcb.h | ||
| xcb_auth.c | ||
| xcb_conn.c | ||
| xcb_ext.c | ||
| xcb_in.c | ||
| xcb_list.c | ||
| xcb_out.c | ||
| xcb_util.c | ||
| xcb_windefs.h | ||
| xcb_xid.c | ||
| xcbext.h | ||
| xcbint.h | ||