3 ms·
Caddy v2 is actually designed as an "app platform". The HTTP app is just one such type of app, and is what Caddy ships with by default. But it can be extended t
by francislavoie 5y ago
Caddy v2 is actually designed as an "app platform". The HTTP app is just one such type of app, and is what Caddy ships with by default. But it can be extended to do _anything_.
See https://caddyserver.com/docs/architecture https://caddyserver.com/docs/architecture
You don't have to run both the HTTP app and the SSH app in the same process, you could have two separate Caddy processes configured to each do their own thing, if you're at all concerned.
- pantulis 5y agoIsn't this like a super-server in the spirit of inetd?
- francislavoie 5y agoI guess, except Caddy doesn't spawn any processes, it just "starts apps" which are configured in-process, pure Go. Another example Caddy app is https://github.com/mholt/caddy-l4 https://github.com/mholt/caddy-l4 which lets you do arbitrary TCP/UDP handling/proxying. There's a list of available apps here https://caddyserver.com/docs/json/apps/ https://caddyserver.com/docs/json/apps/ (the SSH app is not there yet, should be soon)
- jrockway 5y agoI think it's fine for a conceptual understanding. The Go runtime looks a lot like an OS, mapping G (goroutines) to Ms (worker threads), removing goroutines from the workers when they block in syscalls, waking up goroutines when a lock they want is available or a syscall finishes, etc. In the end it really depends on what you think of inetd as. If you think of it as "I install this one server and now I have finger and gopher!" then that seems similar to Caddy's applications. If you think of it as "whenever a TCP connection arrives, the fork() syscall is used to create a process to handle that session, file descriptors 0 and 1 are connected to the TCP socket, and then exec() according to the global config is run to handle the protocol", then ... no it's not the same as inetd.