agent-substrate / agent-substrate/substrate
Enhancing Network Ingress
- 主要语言
- Go
- 星标
- 1.8k
- 派生
- 316
- 平均合并
- 2 天 43 分钟
- 30 天内合并 PR
- 287
描述
Current request flow:
```
Request =>
Router:80 =>
Request handling (routing + scheduling queue + resume on traffic)
=> Actor.
```
Current limitations:
* Only supports one port (port 80) and protocol (HTTP 1.1)
* No policy, most importantly authz.
* Routing by Host header
* Router could become a bandwidth bottleneck
CUJs
* Policy
* Actor exposes services on multiple ports.
External requests should be able to route traffic to those ports. All other ports are blocked.
* Actor A can receive requests from [Actor B1, B2, …] based on ateapi Authz policy.
* Actor A can receive requests from external identity, e.g. sending a request directly to the router from a desktop (curl -H 'Host: ' router-dns') based on ateapi Authz policy.
Enhancements for ease of use. These allow for users to more easily interact with the system:
* (Idea) We should also allow for easy access to an Actor via URL e.g. `http://actors.router.ate.dev///` will route the request to the Actor stripping the `/` prefix.
* (Idea) Configurable vanity hostnames for Actors? Users can define a custom domain that the Router will understand and map to the appropriate Actor. For example, `myactor.foo.com` hostname goes to specific Actor defined by the user. We will need to solve the issue of giving permissions to create hostname mappings as these are substrate global entities.
Backlog for now
* (P2 for now, need actual use case) Actor exposes a port directly, skipping the router. For example, run a test web server that receives traffic from an external probe.
xref:
* [Pluggable Substrate Ingress and Actor-Aware Routing](https://docs.google.com/document/d/1djurA9d7f7UIW2DhSqyX85Ad8JgkpPPyCbpDy7G7HOs/edit?pli=1&tab=t.r12pfwjkq9tf)
贡献指南
评估
这个 Issue 还没有评估数据。