Exercise 2: Why "Connection Refused" Doesn't Fully Pinpoint the Cause — Possible Solution
====================================================================

WHY IT DOESN'T FULLY PINPOINT THE CAUSE
------------------------------
Per this chapter's warn-box, a refused connection is "a genuinely
useful, active signal - but on its own it doesn't fully distinguish
between" two different underlying situations that produce the exact
same client-side message. Getting an active "no" narrows things down
compared to silence, but doesn't by itself say which of two causes
produced that "no."

THE TWO CANDIDATE EXPLANATIONS
------------------------------
1. "Nothing is listening on this port" - per this chapter, "the
   operating system itself replies, since no process owns that port."
2. "A firewall is explicitly configured to reject rather than
   silently drop this traffic" - which, per this chapter, "can produce
   the exact same client-side message" as the first case.

WHY TELLING THEM APART NEEDS MORE THAN THE CLIENT-SIDE RESULT
------------------------------
Per this chapter, distinguishing the two "usually needs a second data
point - often access to the machine itself, or the firewall's own
logs, which Chapter 7 covers." From the requesting client's point of
view alone, both situations look identical, so the refusal message by
itself can't tell you which one actually happened.

WHY THIS WORKS AS AN ANSWER
------------------------------
It explains why "refused" is more informative than a timeout without
overclaiming it as fully conclusive, and names both candidate
explanations from the chapter accurately rather than only naming one
or inventing a third.