Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make getSocket{Family}TCP try all addr candidates #32

Merged
merged 1 commit into from
May 11, 2016

Conversation

jcpetruzza
Copy link
Contributor

Fixes #31.

Some hostnames can resolve to more than one address. A common example is "localhost", that on many (but not all) platforms resolves to 127.0.0.1 (ipv4) and ::1 (ipv6). When one uses getaddrinfo in such address, and doesn't specify if one is looking for an ipv4 or ipv6 address (e.g., because one doesn't know and/or don't care and wants to support both), one will get more than one result. The right way of handling this is trying to connect to each of the provided addresses, in order, one by one. However, in the previous implementation, a function such as runTCPClient would only attempt to use the first address.

Two things two note:

  • One of the tests in Data.Streaming.NetworkSpec was using runTCPClient to connect to "127.0.0.1"; if one were to change that by "localhost", it would fail on Debian, OS X and others.
  • bindPortTCP (via bindPortGen) was already trying all given addresses until one succeeded.

Fixes fpco#31.

Some hostnames can resolve to more than one address.
A common example is "localhost", that on many (but not all)
platforms resolves to 127.0.0.1 (ipv4) and ::1 (ipv6). When
one uses `getaddrinfo` in such address, and doesn't specify
if one is looking for an ipv4 or ipv6 address (e.g., because
one doesn't know and/or don't care and wants to support both),
one will get more than one result. The right way of handling
this is trying to connect to each of the provided addresses,
in order, one by one. However, in the previous implementation,
a function such as runTCPClient would only attempt to use
the first address.

Two things two note:

  - One of the tests in Data.Streaming.NetworkSpec was using
    runTCPClient to connect to "127.0.0.1"; if one were to
    change that by "localhost", it would fail on Debian,
    OS X and others.

  - bindPortTCP (via bindPortGen) was already trying all
    given addresses until one succeeded.
@snoyberg snoyberg merged commit ce46b1e into fpco:master May 11, 2016
@snoyberg
Copy link
Member

Thanks!

snoyberg added a commit that referenced this pull request May 11, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

getSocketTCP ought to try connecting to all possible addresses
2 participants