Module serve 

The serving loops behind microvm tunnel and microvm port-forward, and behind the SDKs’ tunnel and port-forward handles (#263).

Each loop accepts a local connection, serves it on a task of its own, and counts how it ended. The three things the CLI used to own are parameters: a stop future (the CLI’s Ctrl-C, a handle’s stop()), a limit on how many connections to accept, and a callback that hears about each connection’s end, so a caller can print a warning or keep a list. A connection that fails never ends the loop; only the stop, the limit, or a listener that stops accepting does. The report’s counts are computed here, once, for every surface.

Every connection gets a task, both loops alike

One WebSocket per tunnel connection matches the daemon’s no-multiplexing decision, and one task per forwarded connection means a slow request (a long poll, a first compile) doesn’t hold the browser’s next one behind it, which the CLI’s port-forward used to do. When the loop stops accepting, it waits for the connections already open to end: a task still relaying holds bytes the local client is waiting for, and dropping it would cut them short. Only an SDK handle cuts them, when its caller’s stop gives a grace that runs out or the handle is dropped.

A direct session serves too

A session with no proxy credential reaches the daemon without the endpoint proxy. The tunnel then offers no proxy subprotocols, and the daemon’s bearer check is the gate; the forwarder mints no proxy headers and sends each request to the endpoint’s host at the guest port (super::forward::direct_url), since there is no proxy to route it by header.

Structs

ConnectionEnd

One connection that didn’t end clean. A clean end is only counted, so a long-lived handle’s report grows with its failures, not with its traffic.

ForwardReport

What a port-forward loop did.

ForwardSummary

What a port-forward handle did: the loop’s report, and each connection that didn’t end clean.

ServeLimits

When a loop stops on its own, besides its caller’s stop.

Serving

A serving loop on a background task: the SDKs’ tunnel and port-forward handles.

TunnelConnection

How one tunnel connection ended.

TunnelReport

What a tunnel loop did.

TunnelSummary

What a tunnel handle did: the loop’s report, and each connection that didn’t end clean.

TunnelTarget

What a tunnel reaches: the daemon, the guest port, and the credentials to present.

Enums

EndKind

How a connection that didn’t end clean ended, as a handle’s report lists it.

ForwardNotice

Something one forwarded connection did, for a caller’s warnings.

StopReason

Why a loop stopped accepting.

Constants

DEFAULT_BIND

The shared listener default, retained at its existing public path.

Functions

bind_address

A local address to listen on: bind when given, DEFAULT_BIND otherwise.

serve_forward

Serves listener as an HTTP and WebSocket forward to spec’s guest port until stop resolves, the limit is reached, or the listener fails, then waits for the open connections to end.

serve_tunnel

Serves listener as a TCP tunnel to target until stop resolves, the limit is reached, or the listener fails, then waits for the open connections to end.

start_forward

Binds bind and starts a port-forward to guest_port behind endpoint on the current tokio runtime: the SDKs’ Session.port_forward. auth is None for a direct session.

start_tunnel

Binds bind and starts a tunnel to target on the current tokio runtime: the SDKs’ Session.tunnel.