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

Projects
None yet
2 participants
@jcpetruzza
Contributor

jcpetruzza commented May 10, 2016

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.
Make getSocket{Family}TCP try all addr candidates
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.

@snoyberg snoyberg merged commit ce46b1e into fpco:master May 11, 2016

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
@snoyberg

This comment has been minimized.

Show comment
Hide comment
@snoyberg

snoyberg May 11, 2016

Member

Thanks!

Member

snoyberg commented May 11, 2016

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