Skip to content

feat(forward): ForwardTracker Protocol for local-forward lifecycle hooks#807

Open
AlexMKX wants to merge 1 commit into
ronf:developfrom
AlexMKX:feat/forward-tracker
Open

feat(forward): ForwardTracker Protocol for local-forward lifecycle hooks#807
AlexMKX wants to merge 1 commit into
ronf:developfrom
AlexMKX:feat/forward-tracker

Conversation

@AlexMKX
Copy link
Copy Markdown

@AlexMKX AlexMKX commented May 21, 2026

Adds optional tracker kwarg to SSHClientConnection.forward_local_port that accepts a ForwardTracker (typing.Protocol) with two hooks:

connection_made(orig_host, orig_port) -> None
connection_lost(orig_host, orig_port, exc) -> None

The hooks fire on every client connect/disconnect on the local listener. Hook exceptions are swallowed so a buggy tracker cannot break the forwarder.

Backward compatible: tracker defaults to None, preserving existing behavior with no overhead.

Use case: passive observation of local-forward activity (idle-based auto-shutdown, byte counters, etc.) without modifying transport code.

Adds optional tracker kwarg to SSHClientConnection.forward_local_port
that accepts a ForwardTracker (typing.Protocol) with two hooks:

  connection_made(orig_host, orig_port) -> None
  connection_lost(orig_host, orig_port, exc) -> None

The hooks fire on every client connect/disconnect on the local
listener. Hook exceptions are swallowed so a buggy tracker cannot
break the forwarder.

Backward compatible: tracker defaults to None, preserving existing
behavior with no overhead.

Use case: passive observation of local-forward activity (idle-based
auto-shutdown, byte counters, etc.) without modifying transport code.
@ronf
Copy link
Copy Markdown
Owner

ronf commented May 23, 2026

Thanks for the PR. Could you say a little more about the use case you have in mind for this? I'm not really seeing how this would be able to do things like byte counts or idle tracking if you are only sending connection_made and connection_lost messages through the tracker.

I'm wondering if some of this could be handled by using the existing accept_handler. It only runs right now on a new client connection coming in, giving you the client IP address and port and even lets you decide based on that whether to allow the forwarded connection or not. It doesn't currently run when a connection closes (either cleanly or with an error), but that could be added as something like an error_handler. In the future, support for a progress_handler could also be added here to report on bytes transferred, much like what exists in AsyncSSH right now for the SFTP/SCP file copy functions.

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