Protocol lessons become more concrete when students can see that failure is not always a total outage. Many real incidents begin as interrupted sessions, delayed acknowledgements, duplicated requests, or inconsistent client behaviour.
This drill asks learners to analyse a short session-recovery scenario and decide which evidence would prove whether the protocol handled the interruption safely.
Scenario
A student information dashboard intermittently freezes during enrolment week. Users report that some form submissions appear twice, while others time out and must be retried. The infrastructure team suspects unstable client sessions between the browser, edge cache, and application endpoint.
Student task
Ask each group to prepare a recovery evidence sheet with four sections:
- Failure signal: What did the user observe, and which protocol layer might explain it?
- Retry evidence: Was a request resent, duplicated, cancelled, or completed after delay?
- State consistency check: Did the server record one action, two actions, or no action?
- Safe recovery rule: What should the system do before accepting another submission?
Teaching note
The goal is not to make students memorise every protocol detail. The goal is to help them reason from observable evidence: timestamps, status codes, request identifiers, logs, and user-visible results.
Learning outcome
Students learn to connect communication protocol behaviour with service reliability. They practise explaining why session recovery needs clear evidence before a team can decide whether the fix belongs in the client, network path, cache configuration, or application workflow.