Leading up to the launch of SIS's beta, I wanted to discuss the design decisions of how the SIS server suite works. There are four main components that everything is built off of, Servers, request handlers, the server routers, and the multiplexer. This part will begin with servers and their Host mappings first.
The most important component within SIS is the Server, which is defined by SIS as a collection of routes (resource paths) that send back a resource to the client (via request handlers), and which speak a particular protocol or multiple protocols (kinda, more on this in Part II). This resource could be a status code, an error code, a static file, or a dynamically-generated resource. Every server gets its own directory for hosting public-facing content, if desired, and a setting for its default language.
Most importantly, in SIS, this is all that a Server is. Rather than storing one bind address, hostname, and port for each server, SIS instead chooses to generalize a Server so that multiple hosts can be mapped to it.
A Host in SIS is defined as a bind address, bind port, hostname, serve port, protocol, and a boolean determining whether it's an SCGI host. Hosts determine how a Server is accessed. A Server can be accessed through multiple Hosts if multiple Hosts are mapped to that Server. For Hosts of TLS protocols, every Host must also be mapped to a TLS Certificate.
This system allows a Server to be accessed from multiple hostnames, multiple ports, and most importantly, multiple protocols. It also allows multiple hostnames to be provided on one bind address and bind port for virtual hosting. A bind address and bind port is called a PortListener within SIS.
When loading in all of the Servers and their Host mappings, SIS takes this list of Host mappings and creates a list of PortListeners - all of the bind address and bind port combos that the server should listen on.
After SIS has loaded in all of the configuration, initialized all of the Servers, and loaded each Server's Host mappings and each TLS Host's Certificate, SIS then starts up each PortListener in its own lightweight execution thread (goroutine), which listens for tcp connections on the bind address and bind port.
Every PortListener then multiplexes every request based on whether it's a TLS connection, its SNI information (if availale), and what protocol it is using by parsing the header for the gemini, scroll, spartan, nex, misfin, and gopher protocols. PortListeners will also accept SCGI connections for each of these protocols. The PortListener then uses the protocol type and the header information to find a Host mapping that maps to a Server. Finally, the PortListener sends off the header information to the Server's function for handling incoming requests.
In Part II, I will discuss how each Server deals with each request.
=> SIS Repo
Jan 16 ยท 3 days ago ยท ๐ CitySlicker ยท ๐ค 1
text/gemini; charset=utf-8This content has been proxied by September (ba2dc).