The occasional ECONNRESET

Tiny local chat between two apps turns into a surprise breakup — and commenters say it’s ancient TCP drama

TLDR: The mystery reset wasn’t a random crash: one program closed the connection while unread data was still sitting there, triggering a hard disconnect. Commenters were split between helpful explainers and smug “this has worked that way for 30 years” veterans, turning a bug hunt into a mini internet-history lesson.

A seemingly boring mystery — two programs on the same computer talking over a local connection, and one randomly getting the digital equivalent of a slammed door — turned into catnip for the comments. The setup looked innocent: one side opens a port, the other connects, they trade data, and then boom: “Connection reset by peer,” meaning the other side abruptly cut things off. The weird part? No crash, no obvious error, no smoking gun in the logs. Just vibes and betrayal.

That’s where the community piled in like internet detectives. The loudest consensus was basically: this isn’t random at all. Several commenters said the real villain is an old, deeply baked-in behavior of the internet’s plumbing: if both sides talk, but one side closes the connection without bothering to read what the other side sent, the system may respond with a hard reset instead of a polite goodbye. In plain English: one app says, “Here’s your data, bye,” while ignoring the other app’s message — and the network throws a fit.

The drama came from tone as much as substance. One commenter delivered a classic nerd-eye-roll with, “Um, yes?”, acting like this has been obvious for decades. Others brought receipts, linking old standards docs and even Linux source-code comments like courtroom exhibits. There was also some relatable war-story energy from people who’d hit the same issue in Go and HTTP, where tossing away unread responses quietly sabotaged connection reuse. The mood was half forensic investigation, half ‘welcome to ancient networking goblin behavior’ meme.

Key Points

  • The article reproduces an intermittent localhost socket issue where a client receives ECONNRESET while reading from a TCP connection.
  • The server listens on TCP port 8125, forks per connection, and sends 600,000 bytes to the client immediately after accept.
  • Without the client's --spam option, the client reads all 600,000 bytes and exits normally; with --spam, it first sends data and then may receive errno 104, Connection reset by peer.
  • A packet capture confirms that an actual TCP RST is sent on the connection.
  • Server-side strace shows accept, fork, sendto of 600,000 bytes, close, and clean exit, indicating no crash and no locally detected send error.

Hottest takes

"If there's data still pending to be read, this will cause a RST" — Joker_vD
"That's how TCP has been universally implemented for more than 30 years" — Joker_vD
"we send a RST here because data was lost" — smarks
Made with <3 by @siedrix and @shesho from CDMX. Powered by Forge&Hive.