Skip to content

IPv6 support #317

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

Merged
merged 14 commits into from
Jan 11, 2018
Merged

IPv6 support #317

merged 14 commits into from
Jan 11, 2018

Conversation

lutovich
Copy link
Contributor

PR makes driver able to connect to Neo4j databases that listen on IPv6 addresses. Routing driver will now be able to receive IPv6 addresses in routing procedure responses and resolve host names to IPv6 addresses.

Parsing of URLs was the biggest piece here. New dependency on url-parse is added for this.

@lutovich lutovich requested a review from ali-ince December 29, 2017 11:09
@lutovich
Copy link
Contributor Author

@oskarhane could you please take a look at this PR?

It adds a new runtime dependency, which I assume is fine and will not cause any problems for users. Driver will use it's own copy of url-parse. Is my understanding correct?

When this change is merged and released we should consider using it in neo4j-browser.

@lutovich lutovich requested a review from oskarhane December 29, 2017 11:12
@lutovich lutovich force-pushed the 1.5-ipv6 branch 5 times, most recently from 65aa100 to dfaccb6 Compare January 2, 2018 10:27
It supports host names, IPv4 and IPv6 addresses. Existing regex-based
parsing does not allow IPv6.
This commit adds a new runtime dependency on url-parse library which
replaces previously written parsing code. Library is most likely less
fragile and requires less maintenance. All unit tests remain and pass.
To be able to run tests in IE. It's currently not part of the main
build but useful for testing things locally.
It is used as connection identifier i routing table and connection pool.
This commit makes driver use previously introduced parser that supports
host names, IPv4 and IPv6 addresses. Previously used regex-based parsing
is now removed. Driver is now able to connect to IPv6 addresses and
supports resolution of host names to IPv6 addresses. Routing procedure
responses can now safely contain IPv6 as well.

Bolt URL with IPv6 always requires address in square brackets like:
`bolt://[ff02::2:ff00:0]` or `bolt+routing://[ff02::2:ff00:0]:8080`.

Renamed `url.js` to `url-util.js` and it's functions to better
represent what they do.
Added tests to verify that driver can connect to real single-instance
database using localhost IPv6 address. Added test to check that driver
can receive IPv6 addresses in routing procedure response (using stub
server). Introduced convenience method to read server version using
given driver instance.
WebSocket in IE and Edge does not understand IPv6 addresses because they
contain ':'. Which is an invalid symbol for UNC
https://en.wikipedia.org/wiki/IPv6_address#Literal_IPv6_addresses_in_UNC_path_names.
This caused `new WebSocket()` call to throw `SyntaxError` for all given
IPv6 addresses.

Following URL rewriting is needed to make WebSocket work with IPv6:
  1) replace all ':' with '-'
  2) replace '%' with 's' for link-local addresses
  3) append magic '.ipv6-literal.net' suffix

After such changes WebSocket in IE and Edge can connect to an IPv6
address.

This commit makes `WebSocketChannel` catch `SyntaxError` and rewrite
IPv6 address. It chooses not to detect browser/OS and things like this
upfront because it seems hard. User-agent string changes often and
differs for different versions of IE.

See following links for more details:
https://social.msdn.microsoft.com/Forums/ie/en-US/06cca73b-63c2-4bf9-899b-b229c50449ff/whether-ie10-websocket-support-ipv6?forum=iewebdevelopment
https://www.itdojo.com/ipv6-addresses-and-unc-path-names-overcoming-illegal/
https://en.wikipedia.org/wiki/IPv6_address#Literal_IPv6_addresses_in_UNC_path_names
Connection timeout limits amount of time connection spends waiting for
the remote side to respond. It makes connect not hang forever if remote
side does not respond. Configured positive values define the actual
timeout. Zero and negative values mean infinite timeout.

Previously configured value was not correctly interpreted and thus it
was not possible to disable the timeout. Zero and negative values
resulted in a default value of 5 seconds to be used.

This commit fixes the problem so that zero and negative values mean
no timeout.
`WebSocketChannel` is built on top of a `WebSocket` and contains
property that references it. `WebSocket` connection timeout is
enforced by a separate setTimeout timer that closes the socket
after configured amount of time. Previously this timeout has
only been cleared when connection is established. It has not
been cleared when channel is closed, resulting in potential
existence of stray timers.

This commit makes `WebSocketChannel` clear the connection timeout timer
when it's closed. So connect timeout timer is removed even if channel
is closed before connection is established.
Copy link
Contributor

@ali-ince ali-ince left a comment

Choose a reason for hiding this comment

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

Looks good!

@ali-ince ali-ince merged commit 25dc55b into neo4j:1.5 Jan 11, 2018
@lutovich lutovich deleted the 1.5-ipv6 branch January 11, 2018 13:59
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.

2 participants