# ONRouter paper — arXiv submission package Author: yxpil Artifact: ## Title **ONRouter: An OpenResty-Compatible Gateway in Rust with a Preemptible Lua Runtime** ## Suggested arXiv classification - Primary: `cs.DC` (Distributed, Parallel, and Cluster Computing) - Cross-lists: `cs.NI` (Networking and Internet Architecture), `cs.PL` (Programming Languages), `cs.CR` (Cryptography and Security) `cs.DC` is the best primary fit: the paper is about the design of a concurrent request-processing system, with the security material appearing as a design contribution (trust ordering, fail-closed access control) rather than as the subject. If a reviewer prefers a networking venue for the protocol material, `cs.NI` works as primary and `cs.DC` as a cross-list. ## Abstract (verbatim) > ONRouter (ORR) is a reverse proxy and application gateway written from scratch > in Rust that reimplements the OpenResty programming model --- nginx's > multi-phase request pipeline, an embedded Lua 5.4 scripting layer exposing the > `ngx.*` API, native Rust modules, and TLS termination --- without > reusing any gateway logic from nginx. This paper describes the architecture > and reports an on-host A/B comparison against OpenResty 1.25.3.1 across four > scenarios and five concurrency levels. Three design decisions carry most of > the result. First, a per-core Lua VM pool driven by a coroutine scheduler in > which every resume is armed with an instruction-count hook that yields the > coroutine back to the scheduler, so a runaway script in a single-process > gateway degrades to one busy core rather than stalling the gateway. Second, an > explicit blocking analysis that moved every filesystem access off the async > workers and added an in-process static-file cache; this is where the static > path win comes from. Third, a front-proxy seam placed strictly after the > real-IP trust gate, so that a client replaying a provider's entire header set > cannot move its own identity. The measurements are reported together with > their caveats: the load generator is a Python client, so absolute request > rates are client-bound; the Lua paths are *slower* than OpenResty's > LuaJIT (0.74x at one connection, 0.99x at thirty-two), while the reverse > proxy and static paths reach 2.49x and 1.82x. A control endpoint that performs > no I/O shows parity (0.99x), which isolates the difference to the I/O and > scheduling path rather than to the harness. ## Files ``` main.tex the paper refs.bib bibliography common.tex shared preamble (copied in at packaging time) figures/throughput.pdf throughput vs concurrency, from bench_ab_sweep.log figures/latency.pdf median latency vs concurrency, from bench_ab_sweep.log figures/ratio.pdf ONRouter/OpenResty ratio, from both logs figures/least_time.pdf adaptive upstream selection, from bench_least_time_20261020.json scripts/make_figures.py regenerates every figure from the committed logs scripts/bench_ab_parsed.json the parsed benchmark data the tables come from ``` ## Build ```bash cd papers/onrouter cp ../_shared/common.tex common.tex pdflatex main bibtex main pdflatex main pdflatex main ``` or, with `tectonic` (which fetches packages on demand): ```bash tectonic -X compile main.tex --keep-logs ``` `tectonic` runs bibtex automatically, so a single invocation is enough. ## Package for arXiv ```bash bash papers/make_package.sh onrouter ``` This produces `papers/dist/onrouter.tar.gz` containing `main.tex`, `common.tex`, `refs.bib`, `figures/`, and `scripts/` — the layout arXiv expects. ## Submit 1. Go to and click **Submit new paper**. 2. Upload `papers/dist/onrouter.tar.gz` (or upload the PDF for a "submit PDF only" record, but the source is strongly preferred: arXiv requires a LaTeX source for the "submission" version, and the source contains the figure scripts). 3. Category: `cs.DC` primary; add `cs.NI`, `cs.PL`, `cs.CR` as cross-lists. 4. Copy the abstract above into the metadata form. 5. License: the arXiv perpetual non-exclusive license is fine; add `CC BY 4.0` only if you want an explicit reuse grant. 6. **Author identity.** arXiv requires an account with a verified email. The author block in `main.tex` currently reads *Daozhendong Yang*, School of Intelligent Science and Engineering, Yunnan Technology and Business University, with `hi@yxpil.com` as the contact. Confirm the spelling of your name in Latin characters and the affiliation line before submitting; arXiv will not accept a name that does not match the account holder. ## Reproducing the numbers Every quantitative claim in the paper comes from artifacts committed in the ONRouter repository. From a checkout of that repository: ```bash # figures and the parsed tables python papers/onrouter/scripts/make_figures.py --repo . --out papers/onrouter/figures # the A/B sweep itself (needs a built release binary and an OpenResty install) cd python bench_ab.py # full A/B run python bench_ab.py --targets orr # ONRouter only python bench_ab.py --connections 32 # the control-endpoint run ``` The A/B harness prints the client ceiling line that the paper reports (9,591 req/s on the reference host) and its own caveats; those caveats are reproduced verbatim in the paper's Threats to Validity section, so a reader can see the limits of the comparison without opening the repository. ## What the paper does not claim Read `docs/OPENRESTY_GAP_ANALYSIS.md` in the ONRouter repository before submitting. The paper deliberately reproduces the gap analysis's own summary: no master/worker split, no USR2 binary upgrade, an interpreted Lua runtime that is slower than LuaJIT on CPU-bound scripts, and a narrower long-tail `ngx.*` surface than OpenResty. The paper's contribution is the design analysis and the honest measurement, not a claim of feature parity.