Expose RemoteAddress on IChannel

[erwan-joly]

Summary

• Adds RemoteAddress to IChannel / NetworkChannel so hosts can read the peer IP of a session without reaching into SuperSocket internals.
• Bumps the package to 7.2.0.

Test plan

• dotnet build green on NosCore.Networking.sln
• Downstream consumer (NosCore WebApi NosMall endpoint) verifies the new property returns the expected IP once the new version ships.

Summary by CodeRabbit

• New Features
  • Network connections now expose the remote peer's IP address, allowing access to this information when the connection is established. The remote address returns null if the endpoint is unavailable.

[coderabbitai]

Walkthrough

A new RemoteAddress property is added to the IChannel interface and implemented in NetworkChannel to expose the remote peer's IP address. The property derives the IP from the underlying session's RemoteEndPoint, returning null when unavailable. The NuGet package version is incremented to 7.2.0.

Changes

Cohort / File(s)	Summary
RemoteAddress Property Addition src/NosCore.Networking/IChannel.cs, src/NosCore.Networking/NetworkChannel.cs	Adds nullable RemoteAddress property to interface and implements it in NetworkChannel to expose remote peer IP address derived from session's RemoteEndPoint with null-safety handling.
Package Version Update src/NosCore.Networking/NosCore.Networking.csproj	Increments NuGet package version from 7.1.0 to 7.2.0.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~5 minutes

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'Expose RemoteAddress on IChannel' directly and accurately summarizes the main change: adding a RemoteAddress property to the IChannel interface.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feature/expose-remote-address

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@src/NosCore.Networking/NosCore.Networking.csproj`:
- Line 15: The package version in NosCore.Networking.csproj must be bumped to
8.0.0 to reflect the breaking change: update the <Version> element from 7.2.0 to
8.0.0 and ensure callers are aware; additionally, update all public
implementations of the IChannel interface to implement the new required
RemoteAddress property (or add a default implementation to IChannel if you
intend to avoid a major bump) so consumers compile; reference the IChannel
interface and its RemoteAddress property when making these code changes.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: b854b43c-0b47-4213-bd48-1c4d46135af2

📥 Commits

Reviewing files that changed from the base of the PR and between bbd4302 and afbd08b.

📒 Files selected for processing (3)

• src/NosCore.Networking/IChannel.cs
• src/NosCore.Networking/NetworkChannel.cs
• src/NosCore.Networking/NosCore.Networking.csproj

[coderabbitai]

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🌐 Web query:

In C#/.NET, is adding a new property without a default implementation to a public interface considered a breaking change for existing external implementers?

💡 Result:

Yes, adding a new property without a default implementation to a public interface in C#/.NET is considered a breaking change for existing external implementers. Existing classes implementing the interface will fail to compile because they must provide an implementation for all members, including the new abstract property. This requires recompilation and updates to those classes. Microsoft's official .NET library compatibility guidelines classify "Adding a member to an interface" as requiring judgment, noting potential compile failures without default implementations (DIMs, introduced in C# 8.0/.NET Core 3.0). The .NET SDK's APICompat analyzer explicitly validates and warns against adding members to interfaces (PR #18834), treating it as a breaking change. Runtime guidelines disallow "Adding an abstract method to an interface". Default interface methods (C# 8+) allow non-breaking additions by providing implementations, but without them, it's breaking. Pre-C# 8, interfaces were immutable post-release to avoid breaks.

Citations:

• 1: https://learn.microsoft.com/en-us/dotnet/core/compatibility/library-change-rules
• 2: https://github.com/dotnet/docs/blob/main/docs/core/compatibility/library-change-rules.md
• 3: [API Compat] Add rule to validate members are not added to interfaces dotnet/sdk#18834
• 4: https://github.com/dotnet/runtime/blob/main/docs/coding-guidelines/breaking-change-rules.md
• 5: https://essentialcsharp.com/interface-versioning-in-c-8-0-or-later
• 6: https://learn.microsoft.com/en-us/dotnet/csharp/advanced-topics/interface-implementation/default-interface-methods-versions

---

🏁 Script executed:

#!/bin/bash
# Find the IChannel interface definition
find . -type f -name "*.cs" | xargs grep -l "interface IChannel" | head -5

Repository: NosCoreIO/NosCore.Networking

Length of output: 108

---

🏁 Script executed:

#!/bin/bash
# Search for IChannel and RemoteAddress in the codebase
rg "interface IChannel" -A 20 -B 2

Repository: NosCoreIO/NosCore.Networking

Length of output: 1641

---

🏁 Script executed:

#!/bin/bash
# Check the csproj file to see current version context
cat -n src/NosCore.Networking/NosCore.Networking.csproj | head -25

Repository: NosCoreIO/NosCore.Networking

Length of output: 1354

---

🏁 Script executed:

cat -n src/NosCore.Networking/IChannel.cs

Repository: NosCoreIO/NosCore.Networking

Length of output: 1639

---

🏁 Script executed:

git diff HEAD~1 src/NosCore.Networking/IChannel.cs

Repository: NosCoreIO/NosCore.Networking

Length of output: 260

---

🏁 Script executed:

git log --oneline -5

Repository: NosCoreIO/NosCore.Networking

Length of output: 137

---

🏁 Script executed:

git show --stat

Repository: NosCoreIO/NosCore.Networking

Length of output: 4712

---

🏁 Script executed:

git show src/NosCore.Networking/IChannel.cs

Repository: NosCoreIO/NosCore.Networking

Length of output: 2114

---

Bump version to 8.0.0 for this breaking interface change.

IChannel is a public interface with a new required property RemoteAddress that lacks a default implementation. All external implementations must be updated to compile. This breaking change requires a major version bump per SemVer; 7.2.0 understates the compatibility impact.

Suggested fix

-		<Version>7.2.0</Version>
+		<Version>8.0.0</Version>

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/NosCore.Networking/NosCore.Networking.csproj` at line 15, The package
version in NosCore.Networking.csproj must be bumped to 8.0.0 to reflect the
breaking change: update the <Version> element from 7.2.0 to 8.0.0 and ensure
callers are aware; additionally, update all public implementations of the
IChannel interface to implement the new required RemoteAddress property (or add
a default implementation to IChannel if you intend to avoid a major bump) so
consumers compile; reference the IChannel interface and its RemoteAddress
property when making these code changes.