Reliable communication is not only about sending a request correctly. Students also need to see what happens when a packet is delayed, a server responds slowly, or a client retries too aggressively.

This lab asks students to treat retries and timeouts as design decisions. Instead of memorising protocol terms, they compare evidence from different timeout settings and explain how each setting changes the user experience.

Lab setup

Give each group a simple request-response scenario such as a login request, file upload, payment confirmation, or learning-management-system submission. Ask them to model three versions of the same interaction:

• a very short timeout that fails quickly
• a balanced timeout with one careful retry
• a long timeout that keeps waiting without useful feedback

Students should record what the user sees, what the client sends, what the server receives, and what evidence would appear in logs.

Discussion prompts

Use these questions to connect the activity with protocol design:

• When does a retry improve reliability?
• When can a retry create duplicate work or confusing state?
• What message should the user see while waiting?
• Which timeout value protects the system without hiding real failures?
• What log evidence would help a support team diagnose the problem?

Learning outcome

Students learn that timeout and retry choices are part of protocol quality. A good design balances patience, safety, and clear feedback so that communication failures become observable and recoverable rather than mysterious.