> Network services are defined by the presence, in a directory watched by listen, of executable files whose name is of the form <protocol><port>.
That seems a bit silly to me as it means something like rot1376 is tricky to parse correctly. I'd think it would make sense for the protocol to need to be separated from the port by a non-numeric character, like a hyphen. Like that it would be trivial to parse: just grab all the numeric characters from the end until we find the non-numeric character.
Rot13 is not a protocol. If you want to make a rot13 over tcp on port 13, your executable would be named tcp13. I thought the same mistake at first too.
Honesty, that’s trivial to parse, even if you don’t want to use or don’t have regex available: In C, e.g., just treat the name as a string and walk backwards from the last character until you find a non-digit; adjust for indexing, and you now know where the protocol ends and port begins.
I believe GP meant that you can't have protocols containing numbers, using rot13 as the example protocol on port 76. Though, as msk-lywenn said, rot13 isn't a real protocol, which don't really have numbers in their names.
Inetd style services are great, but do have an issue with programs that have a lot of startup overhead (e.g. things written in Python). I always thought the FastCGI approach was a neat one, with a defined protocol for what would otherwise start a new process, and the managing daemon can choose if/when to start and stop the process. It certainly makes the listening daemon significantly more complicated, and the actual launched program slightly more complicated, but IMO there are real benefits there.
That specific aspect(a persistent service worker) of fastcgi works well. but I have yet to find a compelling argument for fastcgi the protocol. let me explain.
cgi as a protocol, really a calling convention for launching processes, make sense, it fits a specific niche in the ecosystem. fastcgi does not, fastcgi is a different incompatible http, that is, fastcgi does nothing that http does better. Did we all just collectively loose our ability to think critically, locked on to the fact that the common usage was that a http server launches a cgi process and when the time came to make that process it's own service, said we need cgi for services, creating fastcgi, forgetting that http already works just fine as a service?
I am not really a back-end programmer, I am a sys-admin who sometimes makes web-based tooling. it is very possible there is a subtlety to this I missed. But I was a lot happier when I gave up on fastcgi and just made each service a http server with a reverse proxy in front to dispatch the requests.
I agree completely that writing a FastCGI client is almost as hard as writing an HTTP client, so having a different protocol is gratuitous. See mongrel2 and pushpin as things that can connect to long-running services that speak HTTP over zmq. Neither will manage the worker processes the way Apache could with fastcgi though.
The cgi model(also inetd) starts a new process on every single request.
If you wrote your service in C like god intended(sarcasm) this is not a problem, unix systems are traditionally by design very good at starting processes.
However python(my favorite language for what it's worth) has a lot of baggage it needs to sort out when it starts. so python specifically and any interpreted language that takes more than a few milliseconds to start in general starts to suffer under heavy loads in the one process per request model.
Thus the motivation to make it one process for many requests.
I would be honestly surprised if any listen server ever experience heavy loads ;) this is more targeted at smolweb-scale hosts.
On current hardware it can serve up to a few hundreds requests/s without too much trouble.
There's also the trick of pre starting a pool of processes beforehand and handing the data to them when it comes. It is not implemented in listen yet, but would not be too hard to do.
the lack of access control in traditional bsd sockets has been a pain point and the concept of privileged port range is utterly useless, especially as you generally don't want to run your services as root anyways.
that being said, didn't selinux resolve that problem decades ago?
That seems a bit silly to me as it means something like rot1376 is tricky to parse correctly. I'd think it would make sense for the protocol to need to be separated from the port by a non-numeric character, like a hyphen. Like that it would be trivial to parse: just grab all the numeric characters from the end until we find the non-numeric character.