The technique of running an internet application behind xinetd (or its predecessor inetd) is commonly referred to as using a super-server architecture, and the applications themselves are said to be running in inetd mode. [1, 2] (Our proprietary inetd is called PITS (Pseudo Internet Terminal Server.)
How the Technique Works
Instead of a server application running continuously in the background as a standalone daemon, xinetd acts as a single delegate that listens on multiple network ports simultaneously. When a client request arrives, the process follows these steps: [1]
1. Port Listening: xinetd listens on the configured network port.
2. Process Spawning: Upon receiving a connection, xinetd spawns (forks) the associated application on demand.
3. Socket Hooking: xinetd hooks the network socket directly to the application's standard input (stdin), standard output (stdout), and standard error (stderr).
4. On-Demand Execution: The application handles the single request via standard I/O streams and exits immediately after completion, freeing up system memory. [1, 3, 4]
Common Use Cases
This approach is highly efficient for lightweight or rarely used services (such as legacy telnet, ftp, or custom health-check scripts) because it conserves system resources by keeping application daemons dormant until they are explicitly needed. [4, 5, 6]
Inspired by Mystic bbs and Oblivion/2.
New design. Celerity inetd...
Re: New design. Celerity inetd...
Halloween Build
Trick? Or Treat?
BBS.PAS is now CelerityLX.js
1. Still managed by PITS, with a single instance of my DXJS.
Key Architecture Decisions
Singleton DXJS embedded in PITS (not per-connection spawning)
- Single DXJS runtime instance (~50MB)
- Each session gets isolated JavaScript execution context (2-5MB each)
- Shared JIT code cache (FLUX scripts compiled once, reused by all callers)
- Supports both blocking and non-blocking I/O modes
SessionIO & SessionProcess globals (bridge between PITS and DXJS)
global.SessionIO = {
readLine(prompt), // Get user input
writeLine(text), // Send output
read(bufferSize), // Raw input
write(buffer), // Raw output
getSessionInfo() // Caller metadata
}
global.SessionProcess = {
exit(code), // Graceful shutdown
error(message), // Error exit
setSessionTimeout(),// Protection
resetTimeout() // Keep-alive
}
celeritylx.js entry point (the BBS in JavaScript)
- Loads as require('celeritylx.js')
- Main function executes BBS logic
- Uses SessionIO for all I/O
- Async-compatible (works with both modes)
Trick? Or Treat?
BBS.PAS is now CelerityLX.js
1. Still managed by PITS, with a single instance of my DXJS.
Key Architecture Decisions
Singleton DXJS embedded in PITS (not per-connection spawning)
- Single DXJS runtime instance (~50MB)
- Each session gets isolated JavaScript execution context (2-5MB each)
- Shared JIT code cache (FLUX scripts compiled once, reused by all callers)
- Supports both blocking and non-blocking I/O modes
SessionIO & SessionProcess globals (bridge between PITS and DXJS)
global.SessionIO = {
readLine(prompt), // Get user input
writeLine(text), // Send output
read(bufferSize), // Raw input
write(buffer), // Raw output
getSessionInfo() // Caller metadata
}
global.SessionProcess = {
exit(code), // Graceful shutdown
error(message), // Error exit
setSessionTimeout(),// Protection
resetTimeout() // Keep-alive
}
celeritylx.js entry point (the BBS in JavaScript)
- Loads as require('celeritylx.js')
- Main function executes BBS logic
- Uses SessionIO for all I/O
- Async-compatible (works with both modes)