Hi Zihan, Thanks for the detailed audit and for pointing out the missing IPv6 support in the Go and Node.js clients.
You are very welcome to submit PRs to bring both clients to parity. Since they are maintained in separate repositories, I think one focused PR per client would be easier to review and merge. It would be great to follow the same approach as #18162, including [ipv6]:port parsing and formatting, wildcard-address filtering where applicable, malformed-input tests, and IPv6 loopback coverage. Thanks for helping improve the client-side IPv6 support! Best regards, Haonan Hou On 2026/07/22 13:09:42 Zh D wrote: > Hi Haonan, > > Nice work on #18162 -- centralizing the [ipv6]:port formatting/parsing in > UrlUtils and adding the wildcard-address filtering across the Java, Python, > and C++ clients closes a real gap, and the malformed-input tests > ([::1]6667, [::1]:, [::1:6667, ...) are a good touch. > > While auditing the Go and Node.js clients recently for the session pool / > redirection work, I noticed those two weren't in #18162's scope and still > parse node URLs with a naive colon split, so they can't accept an IPv6 > node URL: > > - Node.js (iotdb-client-nodejs, parseNodeUrls): splits on ":" and requires > exactly two parts, so "[::1]:6667" (and the legacy "::1:6667" form) is > rejected up front with "Invalid nodeUrl format". > > - Go (iotdb-client-go, cluster node URL handling): takes > strings.Split(nodeUrl, ":")[0] as host and [1] as port, so "[::1]:6667" > silently parses to host "[" and an empty port rather than raising -- and > interestingly the same client already uses net.JoinHostPort on the output > side, so it's internally inconsistent. > > Both are the same class of issue #18162 fixed on the other clients. I'd be > happy to bring the Go and Node.js clients to parity -- mirroring the shared > [ipv6]:port parse/format plus the wildcard-address (0.0.0.0 / :: / [::]) > filtering on the redirection paths, with the same malformed-input and > IPv6-loopback test coverage. > > Before I open anything: is client-side IPv6 parity something you'd like to > track under the same effort, and do you have a preference on shape -- one > combined discussion/issue for both clients, or a small PR per client > mirroring #18162's approach? Happy to go whichever way keeps it consistent > with what you just landed. > > Thanks, > Zihan Dai > > On Mon, Jul 13, 2026 07:46 PM, Haonan Hou <[email protected]> wrote: > > > Hi all, > > > > I would like to introduce the IPv6 endpoint support improvement in PR > > #18162: > > https://github.com/apache/iotdb/pull/18162 > > > > This work standardizes IPv6 endpoints as `[ipv6]:port` and improves IPv6 > > address handling across IoTDB. It also prevents wildcard addresses such as > > `0.0.0.0` and `::` from being treated as connectable remote endpoints. > > > > The changes cover shared endpoint utilities, Ratis peer addresses, node > > discovery and redirection, Java Session/JDBC, Python and C++ clients, > > AINode, and Pipe. > > > > Integration tests verify: > > > > - JDBC, Session, and TableSession connections through IPv6 > > - Internal communication in a 1 ConfigNode + 3 DataNode cluster > > - SchemaRegion Ratis and DataRegion IoTConsensus over IPv6 > > - Pipe transmission over IPv6 > > - REST and MQTT services over IPv6 > > > > Comments and suggestions are welcome. > > > > > > 大家好， > > > > 我想介绍一下 PR #18162 中对 IoTDB IPv6 端点支持的完善： > > https://github.com/apache/iotdb/pull/18162 > > > > 本次改动统一使用 `[ipv6]:port` 表示带端口的 IPv6 地址，并完善了 IoTDB 各模块对 IPv6 > > 地址的处理。同时，客户端在节点发现和重定向时，不再将 `0.0.0.0`、`::` 等通配监听地址当作可连接的远端地址。 > > > > 改动覆盖公共端点工具、Ratis 节点地址、节点发现与重定向、Java Session/JDBC、Python 和 C++ 客户端、AINode > > 以及 Pipe。 > > > > 新增的集成测试验证了： > > > > - JDBC、Session 和 TableSession 通过 IPv6 连接 > > - 1 个 ConfigNode 和 3 个 DataNode 集群的内部 IPv6 通信 > > - SchemaRegion Ratis 和 DataRegion IoTConsensus 的 IPv6 通信 > > - Pipe 通过 IPv6 传输数据 > > - REST 和 MQTT 服务通过 IPv6 访问 > > > > 欢迎大家提出意见和建议。 > > > > Best regards, > > Haonan Hou > > >
