mirror of
https://github.com/go-gost/x.git
synced 2026-10-19 16:16:32 +00:00
ginuerzh
6e84d375c1
The socket server and the p2p hub are two answers to the same question, and the design rests on a spoke being unable to tell which one it reached: the same frame, the same magic, the same passphrase, the same registered addresses, the same reply it refreshes its read deadline from. A spoke configured for one is supposed to work against the other. That claim is only worth something if the *same* assertions run against both. Two separately-written suites would be allowed to drift, and nobody would notice until someone deployed one against the other — which is a field failure with nothing in any log to explain it. So the assertions are written once here, against a compatHub that names no transport, and each case is run once per implementation. The duplication that is left is structural: how to build a hub and how it delivers, which is the part that genuinely differs. The socket half drives server.go's own transportServer over a real UDP link rather than a copy of its loops; a compat suite that asserted against a reimplementation would only prove the reimplementation agreed with itself. The p2p half skips, and says why: nothing yet turns an inbound gRPC Tunnel stream into a peerStream and feeds it to p2pHub.fromSpoke, so a spoke's registration frame has no path to that hub. The skip is visible and the six shared cases are named in it, because an absent assertion is not a skipped one. Three deliberate divergences turn the suite red, each from a real behavior rather than a stub: registering a route for a frame the auther refused, delivering to whichever peer spoke last, and echoing nothing after a registration that took.
x
The implementation layer for the GOST proxy framework. Every interface defined in core/ is implemented here — handlers, listeners, dialers, connectors, plus config parsing, registries, and all cross-cutting concerns.
Package layout
| Directory | Purpose |
|---|---|
handler/ |
Protocol handlers (http, socks4/5, ss, ssh, tunnel, tun, dns, redirect, etc.) |
listener/ |
Protocol listeners (tcp, tls, ws, http2/3, quic, kcp, icmp, tun, udp, etc.) |
dialer/ |
Outbound dialers (tcp, tls, ws, http2/3, quic, grpc, ssh, wg, kcp, icmp, etc.) |
connector/ |
Destination connectors (http, socks4/5, ss, ssh, relay, tunnel, direct, etc.) |
config/ |
Config struct, YAML/JSON parsing, and service construction |
registry/ |
Typed global registries for all component types |
service/ |
Accept loop wiring listener + handler |
chain/ |
Multi-hop forwarding chain and route implementation |
router/ |
Route table router (destination-based routing) |
hop/ |
Node group with load-balanced selection |
selector/ |
Load-balancing strategies (round-robin, random, weighted, hash) |
auth/, bypass/, admission/ |
Authentication, bypass rules, admission control |
resolver/, hosts/ |
DNS resolution and host mapping |
limiter/ |
Traffic, connection, and rate limiters |
recorder/, observer/ |
Traffic recording and observability |
ingress/, sd/, routing/ |
Ingress control, service discovery, routing rules |
logger/, metrics/, api/ |
Logging, Prometheus metrics, Web API |
metadata/, ctx/ |
Metadata key-value system and context propagation |
internal/ |
Shared internals — not importable externally |
Component pattern
Every handler, listener, dialer, and connector follows the same pattern: init() registers a constructor into a global registry, the constructor takes functional options, and Init(metadata.Metadata) extracts typed configuration from the metadata key-value map.
See CLAUDE.md for detailed architecture and conventions.