Printers wedged during bursts and stayed wedged until someone power-cycled them. On a receiving dock, that stops work.
There were two real causes and neither was hardware failure. These print servers accept one connection at a time on their raw port, and concurrent or half-closed connections leave them stuck. And every label carried the company logo inline — three and a half kilobytes of compressed bitmap describing a seventeen-kilobyte image — sent again, in full, on every single print.
A transport layer that respects what the hardware can actually do. Jobs to the same device are serialized behind a per-printer lock. Connections are shut down in write direction before closing, so the printer sees a clean end-of-stream and frees its connection slot immediately rather than waiting out a network timeout. A short cooldown sits between jobs to the same device, and lock acquisition itself times out — a wedged printer fails fast instead of queueing work behind it forever.
Then the payload problem. The printers can store graphics in onboard flash and recall them by name, so the logo only needs to be sent once per device, ever.
- The logo is fingerprinted by content hash, so the same image gets the same name on every printer and across restarts
- The printer is asked whether it already holds that graphic, and the upload is verified before the label is rewritten to use it
- The inline image becomes a short recall instruction — twenty-four bytes in place of three and a half thousand
- Status queries read the reply before half-closing, because these print servers abandon a pending response the moment they see a close
The failure case that matters
The interesting decision is what happens when the printer doesn't answer. There are three possible answers to 'do you already have this graphic' — yes, no, and no reply — and treating the third as a 'yes' would produce labels with a silently missing logo.
So the check is explicitly three-valued. No reply means the full image is sent inline, exactly as before. Any partial failure returns the original label untouched rather than a half-converted one. The optimization is allowed to not apply; it is never allowed to produce a wrong label.
A live status board polls every printer in parallel and reports paper out, head open, ribbon out, paused or offline — so the question 'is the printer broken or is it out of labels' has an answer on a screen.
The lock-ups stopped. Print volume that previously wedged the hardware runs through it, and when a printer genuinely does have a problem, the board says which one and what kind.
This is the pattern of most performance work we do. Nothing was rewritten and nothing was replaced — the fix came from reading the hardware's documentation carefully enough to find out what it had been trying to tell us.
