fix(sdk): allow hostnames in server address configuration

[felixfaisal]

Which issue does this PR close?

Closes #2882

Rationale

Server address validation previously required a literal socket address, preventing the use of DNS hostnames. This change allows hostnames (e.g., localhost:8080) in addition to IP addresses.

What changed?

Server address validation previously relied on SocketAddr parsing, which only accepts literal IP addresses and rejected DNS hostnames (e.g., localhost:8080). This prevented using hostnames when configuring client connections.

Validation now uses ToSocketAddrs, which performs address resolution and returns the list of socket addresses for a given host. TcpStream::connect(...) already performs this resolution internally and attempts to connect to each resolved address.

Local Execution

• Passed
• Pre-commit hooks ran

AI Usage

If AI tools were used, please answer:

1. Which tools? ChatGPT free version
2. Scope of usage? Write documentations like comments
3. How did you verify the generated code works correctly?

• I built the code using cargo build
• I ran the unit tests under TCPConfigBuilder and added an additional unit test, also modifying another
• I then ran the server and ran the examples

4. Can you explain every line of the code if asked? Yup

[codecov]

Codecov Report

❌ Patch coverage is 98.07692% with 4 lines in your changes missing coverage. Please review.
✅ Project coverage is 70.61%. Comparing base (2284d0f) to head (63e7f62).
⚠️ Report is 1 commits behind head on master.

Files with missing lines	Patch %	Lines
...ebsocket_config/websocket_client_config_builder.rs	0.00%	3 Missing ⚠️
core/common/src/utils/net.rs	99.47%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##             master    #2923      +/-   ##
============================================
+ Coverage     70.60%   70.61%   +0.01%     
  Complexity      943      943              
============================================
  Files          1113     1114       +1     
  Lines         94590    94778     +188     
  Branches      71790    71994     +204     
============================================
+ Hits          66782    66929     +147     
- Misses        25338    25354      +16     
- Partials       2470     2495      +25     

Components	Coverage Δ
Rust Core	70.70% <98.07%> (+0.05%)	⬆️
Java SDK	62.30% <ø> (ø)
C# SDK	69.10% <ø> (-0.31%)	⬇️
Python SDK	81.43% <ø> (ø)
Node SDK	91.44% <ø> (-0.10%)	⬇️
Go SDK	38.97% <ø> (ø)

Files with missing lines	Coverage Δ
...figuration/tcp_config/tcp_client_config_builder.rs	68.04% <100.00%> (+2.44%)	⬆️
core/common/src/utils/net.rs	99.47% <99.47%> (ø)
...ebsocket_config/websocket_client_config_builder.rs	0.00% <0.00%> (ø)

... and 21 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[hubcio]

hey, thanks for the pr! the intent is solid but there's a fundamental issue with the approach.

to_socket_addrs() calls getaddrinfo() under the hood, which is a synchronous blocking dns lookup. doing this inside build() means config construction now requires network access and can block the thread for seconds if dns is slow. config builders hould be pure/deterministic - th quic builder already gets this right by doing zero address validation in build(). we cannot accept this resolution.

validate the format only (valid host:port structure, port is a valid u16) and leave actual dns resolution to connect time. TcpStream::connect already does resolution internally anyway.

[hubcio]

hello @felixfaisal do you plan to continue?

[felixfaisal]

hello @felixfaisal do you plan to continue?

Hey @hubcio Sorry for not paying attention here, I was a bit caught up this week, I plan to address the comments and update the logic by tonight or late tomorrow. I mostly agree with your review and will do the changes.

[hubcio]

@felixfaisal both of these comments are not fixed. do you plan do to so?

[hubcio]

besides that, it seems like quic is not properly validating this:

• QuicClientConfigBuilder::build() and HttpClientConfigBuilder::build() have zero address validation, making them inconsistent with the now-validated tcp/ws builders. http uses a url format so it needs different validation. consider a follow-up to add appropriate validat

[felixfaisal]

Created follow-up issue - #3075