sanjaysaini383/plivo-systems-23ce36009

Purpose and Entry Points

This repository implements a reliable audio-frame delivery layer over an unstable UDP network for the “Flaky Network” assignment. It uses ARQ-style recovery: the sender retains frames for retransmission, while the receiver detects gaps and requests missing frames.

Primary executables:

• sender.go

• receiver.go

Build orchestration is in Makefile.

Sender: Ingest, Forward, Retain

sender.go is the upstream protocol endpoint. It receives audio packets from the assignment harness/source, forwards them across the flaky UDP path, and stores sent frames in a retransmission buffer.

The sender’s core control loop has two responsibilities:

1. Send newly received frames immediately to minimize playback delay.

2. Receive NACK requests from the receiver and resend requested retained frames.

This establishes the sender as the authoritative source for loss recovery; it must preserve enough recent packet history to serve delayed or repeated NACKs.

Receiver: Eager Playback and Loss Detection

receiver.go is the downstream endpoint connected to the unreliable UDP path and audio player/harness sink. It forwards arriving audio frames eagerly rather than waiting for strict in-order reconstruction, prioritizing delay constraints.

It also tracks missing sequence positions and periodically emits NACKs for frames not observed. Repeated NACK transmission compensates for loss of both data packets and recovery-control packets.

Relevant implementation:

• receiver.go

ARQ Recovery Boundary

The protocol separates:

• Data plane: audio frame forwarding from sender.go to receiver.go.

• Control plane: receiver-originated NACKs requesting retransmission from receiver.go back to sender.go.

The receiver does not reconstruct content itself; it requests recovery. The sender does not decide which frames are missing; it reacts to receiver feedback. This division keeps loss detection near playback while retaining retransmission state near the source.

Timing and Bandwidth Trade-offs

The design is tuned around competing constraints:

• Immediate forwarding reduces end-to-end delay.

• Retaining frames enables late recovery.

• Periodic/repeated NACKs increase recovery probability on a lossy reverse path.

• Excessive NACK and retransmission traffic can violate bandwidth-overhead limits.

Experiment and tuning evidence is maintained in:

• RUNLOG.md

• NOTES.md

Runtime and External Integration

The implementation is written in Go and built as two standalone binaries through:

• Makefile

At runtime, both programs depend on the external assignment harness and its UDP network profiles. The documented test invocation uses a Python harness and profile configuration, while the Go processes implement the actual sender/receiver transport behavior.

Repository-facing protocol documentation is also available in:

• SUMMARY.html