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

Add IPv6 support to StatusServer and related classes. #119

Open
wants to merge 8 commits into
base: master
Choose a base branch
from

Conversation

moodyjon
Copy link
Contributor

@moodyjon moodyjon commented Dec 28, 2022

Fixes #117
Update: Fixes #121

Not sure whether this is complete. I think I need help with this part in hub/env.py:

        if result == 'localhost':
            # 'localhost' resolves to ::1 (ipv6) on many systems, which fails on default setup of
            # docker, using 127.0.0.1 instead forces ipv4
            result = '127.0.0.1'

If I allow the cs_host() to be localhost instead of 127.0.0.1, then it will start TCP servers on both v4/v6 sockets.

What is the problem with docker and this behavior?

@moodyjon moodyjon requested a review from jackrobison December 28, 2022 23:07
@jackrobison jackrobison added area: herald type: new feature New functionality that does not exist yet labels Dec 29, 2022
@moodyjon moodyjon marked this pull request as draft January 13, 2023 15:32
@moodyjon
Copy link
Contributor Author

Just saw a new EADDRINUSE problem when running lbry-sdk tests against this hub branch.

https://github.com/moodyjon/lbry-sdk/actions/runs/3911989925/jobs/6686050669

Converting this to draft status while investigating.

@moodyjon
Copy link
Contributor Author

I did some work on StatusServer.start() to make it retry to overcome transient EADDRINUSE. It got a bit more complicated in order to handle cases like HOST=::,0.0.0.0, HOST=0.0.0.0,::, HOST=myserver1,myserver2, etc. I imported resolve_host() from my moodyjon/lbry-sdk:ipv6 branch to do name resolution.

@moodyjon
Copy link
Contributor Author

Have not seen EADDRINUSE since that one occurrence. Not sure what the root cause of that was. Possible infrastructure?

@moodyjon moodyjon marked this pull request as ready for review January 17, 2023 15:53
Comment on lines +242 to +245
# Because dualstack / IPv4 mapped address behavior on an IPv6 socket
# differs based on system config, create the socket with IPV6_V6ONLY.
# This disables the IPv4 mapped feature, so we don't need to consider
# when an IPv6 socket may interfere with IPv4 binding / traffic.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I don't disable IPv4 mapping, then the IPv6 port will sometimes seize (or try to seize) responsibility for IPv4. The bad effect is seen when starting the server with HOST=::,0.0.0.0 or HOST=0.0.0.0,::. I forget which one fails, but 1 of these two orderings has persistent EADDRINUSE errors.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The bad ordering (on my machine) is HOST=::,0.0.0.0:

2023-01-17 10:14:49,962 - hub.herald.udp - WARNING - started udp6 status server on ('::', 50002)
2023-01-17 10:14:49,963 - hub.herald.udp - ERROR - UDP status server failed to listen on (0.0.0.0:50002) : [Errno 48] Address already in use
2023-01-17 10:14:52,965 - hub.herald.udp - WARNING - started udp6 status server on ('::', 50002)
2023-01-17 10:14:52,966 - hub.herald.udp - ERROR - UDP status server failed to listen on (0.0.0.0:50002) : [Errno 48] Address already in use

HOST=0.0.0.0,:: works fine.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: herald type: new feature New functionality that does not exist yet
Projects
None yet
2 participants