W1·A2 — Client-server vs peer-to-peer

Time: 30 min

Needs: three OL9 PC nodes + one Ethernet switch

GNS3 project: w01-a2-roles

Import the appliance

• Download the OL9 PC appliance
• In GNS3, go to File -> Import appliance then click through the import wizard.

• When you reach Required files, click the Download button to download the disk image. This will take a minute.

  Info

  You only need to download the OL9 disk image once. All remaining appliances in this course reference the same disk image.

• Complete the remaining steps

Build it

• Browse Switches and drag an Ethernet switch on to the canvas
• Browse End Devices and drag three OL9 PC 1.0 onto the canvas
• Right-click each PC node, go to Change hostname and rename them to H1, H2, H3 respectively.
• Run a cable between each host and the switch.
• Click the green start button to run the topology
• Click on the console button to bring up a console window for your hosts

Log on to H1:

sudo nmcli con mod 'System eth0' con-name eth0
sudo nmcli con mod eth0 ipv4.method manual ipv4.addresses 192.168.10.11/24
sudo nmcli con up eth0

Log on to H2 and H3 and do the same. Their addresses are 192.168.10.12/24 and 192.168.10.13/24 respectively.

Predict first

1. In a client-server network of three machines, how many are running server software?
2. If one machine fails, how many conversations stop?

Do this — client-server

On H1 only:

echo 'the only copy of anything' > /tmp/index.html
cd /tmp && python3 -m http.server 8080 &

On H2 and H3:

curl http://192.168.10.11:8080/index.html

Run the next command on each of the three nodes:

ss -tln

See any differences?

What just happened

• ss -tln shows H1 listening on 0.0.0.0:8080. H2 and H3 listen for nothing. That asymmetry is the entire definition — one process waits, two initiate.
• The server is a process, not a box. All three nodes are identical OL9 images with identical hardware. H1 is the server because of one command you ran on it, and it stops being one the moment you press Ctrl-C.

Do this — kill it

On H1: kill %1.

Then on H2 and H3:

curl http://192.168.10.11:8080/index.html

What just happened

• Both clients dead, simultaneously, from one failure. H2 and H3 are up, cabled, and can still ping each other — but neither is able to get what it wants, which is the web page that is no longer being served by anybody.
• The dependency is on the role, not the link. Nothing about the network broke.
• The key idea: Simplicity, but single point of failure

Do this — peer-to-peer

On all three, each hosting its own content:

echo "content from $(hostname)" > /tmp/index.html
cd /tmp && python3 -m http.server 8080 &

# on H1
curl http://192.168.10.12:8080/index.html
curl http://192.168.10.13:8080/index.html

Then check the listeners again on each node:

Now kill the server on H2 and repeat every fetch.

What just happened

• Every node listens and every node initiates. There is no structural difference between the machines, which is precisely what "peer" means.
• Pulling H2 down made its content unavailable, but the rest of the network continued to function. Compare that to the client-server outage, where one failure took out every conversation on the network.
• Nothing about the topology changed between the two halves of this activity. Same three nodes, same switch, same cables, same addresses. The model is a property of how the software is arranged, not of how the network is wired
• On the flip side, this is more costly. You have three copies to keep in sync, three machines to secure, three addresses to keep track of.
• The key idea: flexibility, but distribution burden.

Record

Worksheet section 22:

Plus one sentence: what command would you run on an unknown machine to decide whether it is acting as a server?

If it went wrong