Exercise 2: Why Relay-Based Tools Suit Ad-Hoc End-User Support — Possible Solution
====================================================================

THE CONNECTION-MODEL DIFFERENCE
------------------------------
Per this chapter, RDP/VNC use a direct-connection model, while relay-
based tools work differently: "both sides connect outward to the
vendor's own relay servers, meeting there - avoiding any need for
inbound firewall rules on either end." Instead of one side needing to
accept an incoming connection from the other, both the support
engineer and the end user's machine each initiate an outbound
connection to a third-party relay server, which then bridges the two.

WHY DIRECT CONNECTION MODELS DON'T FIT THE END-USER SCENARIO
------------------------------
RDP or VNC require the target machine to accept an incoming connection
- which means it needs to be directly reachable, typically requiring
firewall/router configuration to allow inbound traffic. An end user's
own home machine is almost always behind a router doing NAT, with no
inbound access configured and no realistic way to ask them to set that
up mid-support-call.

WHY THE RELAY MODEL SOLVES THIS
------------------------------
Per this chapter, this "avoiding any need for inbound firewall rules
on either side" is exactly what makes the model work for this
scenario: since both the support engineer's machine and the end user's
machine only ever make outbound connections (which almost every
network allows by default), neither side needs any special network
configuration for the session to work.

WHY THIS WORKS AS AN ANSWER
------------------------------
It explains the specific mechanical difference between direct-
connection and relay-based models, and explains precisely why the
relay model removes the network-configuration barrier that would
otherwise make reaching a typical end user's home machine impractical.