New design. Celerity inetd...

Closed source BBS project. Resistive in 2026.
Post Reply
ONiX
Site Admin
Posts: 248
Joined: Tue Nov 18, 2025 1:27 am

New design. Celerity inetd...

Post by ONiX »

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.
ONiX
Site Admin
Posts: 248
Joined: Tue Nov 18, 2025 1:27 am

Re: New design. Celerity inetd...

Post by ONiX »

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)
Post Reply