Built for the load real print pipelines put on it.
AmazeLPD separates a fast, highly-parallel receive path from a throttled dispatch stage, acknowledges a job only after it is durably on disk, and degrades gracefully under overload instead of collapsing. Here is how it performs, how it is built, and how it is secured.
Proven under load
Tested head-to-head against the Microsoft Windows LPD service on the same hardware (8 vCPU, ~4 GB Windows VM), driving 500 concurrent clients × 5,000 jobs, deliberately pushed to saturation.
(Microsoft LPD: 4.1%)
below a 2% failure line
(1.4× growth under overload)
then lost
| Metric | Microsoft LPD | AmazeLPD |
|---|---|---|
| Jobs succeeded | 205 / 5,000 (4.1%) | 4,989 / 5,000 (99.8%) |
| Sustainable throughput (<2% fail) | 0 jobs/s (overloaded) | 378 jobs/s |
| Median acknowledgement latency | 6,934 ms | 152 ms |
| Latency growth under overload | 13.3× | 1.4× |
| Connections starved (never acknowledged) | 1,916 (38%) | 0 |
| Acknowledged-then-lost jobs | — | 0 |
Microsoft LPD showed the classic worker-starvation collapse — 38% of connections were accepted but never acknowledged, and sustainable throughput was zero. AmazeLPD, driven to saturation, degraded gracefully: it absorbed a 4,733-item internal backlog and drained it cleanly to zero without losing a single acknowledged job. Its 11 failures (0.2%) were connection-level on the load host, never data loss — because a job is acknowledged only after its bytes are durably written to disk, the client's success count always matches what is actually on the server. There is no acknowledged-but-lost failure mode.
Figures are AmazeLPD's own controlled stress testing, measured on identical hardware.
How it's built
The on-disk spool folder is the single source of truth for job data; the embedded SQLite database (Write-Ahead Logging) holds metadata only. Keeping the data on disk rather than in the database is the decision that gives AmazeLPD its throughput.
Decoupled receive & dispatch
A massively-parallel receive path (auto-sized from RAM) is separated from a throttled dispatch stage, so clients keep getting sub-200 ms acknowledgements even while an internal backlog drains. A slow destination never stalls receiving.
Acknowledge-after-spool
Jobs are acknowledged only once durably written. On start-up, jobs stuck in Processing reset to Pending, orphaned spool files are recovered, and genuinely-missing jobs fail cleanly — no silent loss.
Safe concurrent writes
A single global write lock plus a batched writer thread eliminate SQLITE_BUSY job loss; reads use WAL and are lock-free. Exactly one worker runs per queue, and a job is claimed before dispatch, so no job is ever sent twice.
Fair, tunable concurrency
A global dispatch semaphore rotates fairly across all active queues, so one busy queue can't monopolise delivery. Concurrency, timeouts, retention and receive-thread floor are all operator settings.
Performance & tuning
| Control | Effect | Default |
|---|---|---|
MaxProcessors | Global cap on concurrent destination dispatches. Raise for REST endpoints that absorb concurrency. | 4 |
ReceiveThreadFloor | Minimum receive-worker floor. 0 auto-sizes from physical RAM to a safe ceiling. | 0 = Auto |
JobTimeoutSeconds | Per-request REST timeout. | 60 |
HistoryRetainDays | Retention window for completed/failed jobs and spool files. | 30 |
VerboseLogging | Per-job/per-connection trace logging (off keeps the hot path fast). | Off |
AllowedSenders | IPs / CIDR ranges permitted to send over LPD and IPP. Blank allows all senders. | Blank |
EncryptSpoolFiles | Encrypt spool files on disk. | On (new installs) |
RequireHttpsRest | Refuse plain-HTTP REST destinations (loopback exempt). | On (new installs) |
Security posture
Presented candidly — each area with its mitigation. These describe controls available in the software; how effective they are depends on how they are configured and on your environment.
| Area | Posture & mitigation |
|---|---|
| Least privilege | Runs as the built-in NetworkService account (not LocalSystem). Optionally a dedicated domain account, a passwordless gMSA, or the passwordless virtual account NT SERVICE\AmazeLPD, selected at install. Ports below 1024 need no elevation. |
| Stored credentials | REST usernames, passwords and tokens are protected with Windows DPAPI — never stored in plaintext. |
| Licence integrity | Licence files are RSA-signed and validated locally against an embedded public key, bound to a machine or (site licence) an Active Directory domain, with optional expiry. Tampering invalidates the signature. |
| Data in transit | IPP clients can use IPPS (TLS 1.2, plus TLS 1.3 on Windows Server 2022 and later) on port 631 with a certificate from the machine store; TLS can be required for all IPP connections. LPD/LPR (RFC 1179) has no encryption in the protocol (as with Microsoft LPD) — keep it on a trusted segment. REST destinations can be required to use HTTPS (on by default for new installs), and HTTP redirects are not followed. |
| Data at rest | Optional AES-256 spool-file encryption (with HMAC integrity check) using a key protected by Windows DPAPI — on by default for new installs. The installer removes inherited permissions so the data folder is accessible only to SYSTEM, Administrators and the service account. The SQLite job ledger holds metadata only; BitLocker / volume encryption on the host is still recommended. |
| Sender controls | Optional allowlist of sending IPs / CIDR ranges for LPD and IPP (changes apply without a restart), a per-host connection limit, a receive memory budget sized from RAM, size limits on control data, and timeouts for stalled senders. Jobs for unknown queues are parked in a capped holding area instead of creating queues. |
System requirements
Windows Server 2016 / 2019 / 2022 / 2025, or Windows 10 / 11 (x64) · .NET Framework 4.8 (ships with Windows Update) · ~50 MB disk · TCP 515 (LPD) and/or 631 (IPP), both configurable.