Support actors listening on multiple ports

[juli4n]

Today we only support actors listening on port 80. This is hard-coded in atenet (

substrate/cmd/atenet/internal/router/extproc.go

Line 162 in 00a90a8

targetAddr := net.JoinHostPort(workerIP, "80")

).

This task is to allow actor containers to listen on multiple ports.

I guess one open question is how the router deals with? Will it add listeners dynamically as actor templates are created? Will the DNS names be extended to include the port in the name (some sandboxing tools do this).

[BenTheElder]

See also: #240 (it's also hardcoded in ateom at the moment, but I think we can/should lift that part)

[rogeroger-yu]

One concrete design that fits this issue is to encode the target actor port in the left-most DNS label, while preserving the existing host format as the default-port path.

Proposed routing format:

<actor-id>.actors.resources.substrate.ate.dev            -> <worker-ip>:80
<port>-<actor-id>.actors.resources.substrate.ate.dev     -> <worker-ip>:<port>

Examples:

my-actor.actors.resources.substrate.ate.dev        -> my-actor on port 80
8080-my-actor.actors.resources.substrate.ate.dev   -> my-actor on port 8080
49983-sbx1.actors.resources.substrate.ate.dev      -> sbx1 on port 49983

Why this shape:

• It does not require dynamic listener creation in Envoy or atenet.
• It should work with the existing wildcard DNS shape because the host still ends in actors.resources.substrate.ate.dev.
• It is backwards compatible: hosts without a numeric prefix keep routing to port 80.
• It matches the convention used by several sandbox systems where a sandbox service port is encoded in the hostname.
• It enables generic multi-service actors, not just one specific SDK or compatibility layer.

Implementation sketch:

1. Extend the actor-host parsing helper in cmd/atenet/internal/router/extproc_in.go so it returns both actorID and port.
2. If the left-most label matches ^(\d+)-(.+)$, parse the leading digits as the port and the remainder as the actor ID.
3. If there is no numeric prefix, keep the existing behavior and default the port to 80.
4. Validate the parsed port is in 1..65535; invalid ports should fail routing rather than falling back silently.
5. In cmd/atenet/internal/router/extproc.go, replace the hardcoded net.JoinHostPort(workerIP, "80") with net.JoinHostPort(workerIP, parsedPort).
6. Add unit tests for default-port routing, prefixed-port routing, invalid ports, and ambiguous labels.

The main ambiguity is actor IDs that themselves start with <digits>-, since DNS-1123 allows that. I think the router should use a simple deterministic rule: if the first label matches ^(\d+)-(.+)$, it is treated as a port-prefixed actor host. Clients or higher-level tools that generate actor IDs for multi-port access can avoid IDs beginning with <digits>-. Existing actor IDs that do start with digits still work on the default route as long as the label does not start with <digits>-; if they do, callers can use the default unprefixed host only.

This would also support higher-level sandbox runtimes that expose multiple in-actor services, for example command/filesystem API, code execution API, VNC/noVNC, user HTTP servers, or debugging endpoints, without requiring every actor image to run an extra in-actor reverse proxy just to multiplex ports.

[bowei]

Couple of notes:

• I see you mentioned this is common pattern for some of the sandbox providers -- any references? I am a bit concerned if we don't allow for dynamic ports this will be significant friction for users. If this actually well-supported, then doing this through DNS is less of a concern.
• Would it make more sense to extend the dns name vs adding it to the ID label? So the name would be: port-<port>.<actor id>.actors.resources.substrate.ate.dev:
  • It still allows for the full DNS label for the actors ID.
  • No interference between port and id and we could support direct access to the port on the current actor dns name as well.
• There are workarounds for port handling -- we can use transparent port rewriting (outside Envoy) used by meshes and have Envoy read the original port, so this is less of a concern re: dynamic updates to the router component.

[thockin]

It is backwards compatible: hosts without a numeric prefix keep routing to port 80.

Unfortunately, it seems ambiguous, unless I am missing something. Specifically, I can create an actor named "foo" or "80-foo" or "8080-80-88-foo" and those are all valid actor names. How then do you parse out the port number? In fact, I can create an actor named "80" which is weird, IMO, but is a valid DNS label.

I think Bowei Du (@bowei) is right - something like 80.<actor>.actors... is needed. At some point we will need to revisit the overall domain, but in the meantime...

Do we want to encode this as <portnum>.<actor>.actors... (implying the only prefix is a port number) or more generally like port-<portnum>.<actor>.actors..., which is more verbose but allows potentially other metadata?

[bowei]

One more thing IMO is super important -- this is very much a user friction, interop story where we should check whether or not someone can bring their framework with no or minor modifications and use it with Substrate.