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

Support for IPv6 in redis 2.8, updated tests to 2.8, make it work also on an IPv6-only host #50

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

MarkMartinec
Copy link

Now that redis server 2.8 finally supports IPv6, some updates are needed on the client side too. The old IO::Socket::INET perl module does not support IPv6, but there are two Perl CPAN socket modules that do support both protocol families: an oldish IO::Socket::INET6, and a modern and actively maintained IO::Socket::IP.

The proposed change to Redis.pm choses one of the available IO::Socket::* modules and updates $self->{server} to an arrayref of IP or Unix socket specifications to be tried in order, the first one that succeeds will be used.

The list is needed to choose a suitable default IP server specification, as it is not known in advance on which protocol family the server listens on a loopback interface (e.g. on an IPv6-only host the loopback interface does not have address 127.0.0.1, only the ::1 ). Once we settle for a list for a choice of servers, it can be handy to let a caller specify alternative server choices too.

The change also updates several tests, as the 2.8 redis server has changed some error types or error strings.

The SpawnRedisServer.pm is modified to let it chose between 127.0.0.1 and ::1 for the test server based on availability of protocol families support. This makes it possible for tests to auto-detect an IPv6-only or IPv4-only or dual-stack host. It may appear that using 'localhost' instead of testing IP addresses would be a cleaner solution, but that only works in a 'bind' config of a 2.8 server, and the older IO::Socket::INET6 module does not try multiple IP addresses resolved from 'localhost', so hard-coded IP addresses seem to be the more reliable choice.

@mgregr mgregr mentioned this pull request Jun 12, 2016
@dams dams force-pushed the master branch 2 times, most recently from e5ccb43 to 0dfcf02 Compare August 17, 2020 08:16
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.

1 participant