The Overview
This project began as an exploration into how operating systems handle real-world data movement between processes and devices. A key motivation was understanding how raw data — particularly image frames from a camera sensor — is processed, buffered, and transferred through system layers before reaching an application. At the operating system level, we studied how concepts like process scheduling, memory management, and I/O buffering affect real-time applications. In particular, we focused on how data moves from hardware (camera input) into user-space applications through kernel-managed buffers. This helped connect theoretical OS concepts to practical behavior such as frame delays, dropped packets, and blocking I/O.
We also explored how networking fits into the OS stack through socket programming. This included understanding how TCP/IP handles segmentation of data into packets, how kernel buffers manage transmission, and why application-level framing is required to reconstruct meaningful data from a raw byte stream.
This phase was less about building features and more about building intuition for how a system “thinks” when handling continuous data like video streams.
Raspberry Pi client — server architecture for real-time video streaming.
Custom TCP Protocol
Building on the system-level understanding, the project was implemented as a client-server networked camera system using a Raspberry Pi as the embedded endpoint. The architecture separated responsibilities between a control client and a server responsible for camera capture and data transmission.
The camera subsystem continuously captured image frames, which were then passed through a network layer for transmission over TCP sockets. On the receiving side, the client reconstructed these frames for display and control feedback.
The system was designed around real-time constraints, where latency and throughput directly affected usability. As a result, careful attention was given to how frames were queued, serialized, and transmitted across the network.
This stage transformed theoretical OS concepts into a working distributed system where hardware input, OS buffering, and network communication all interacted in real time.
Length-prefixed framing protocol handling partial reads, blocking I/O, and kernel socket buffering.
Network Validation
To ensure reliable communication, a custom TCP-based protocol was implemented on top of the raw socket layer. Since TCP is a byte-stream protocol and does not preserve message boundaries, a length-prefixed framing system was introduced to reconstruct complete messages on the receiver side.
This protocol also defined structured command messages for system control, including startup initialization, Wi-Fi connection handling, timed shutdown sequences, and safe termination of camera streams. These additions ensured that both ends of the system could transition between states without manual intervention or undefined behavior.
The final stage involved network validation under real-world conditions. This included testing against partial reads, packet fragmentation, and unstable wireless connections. The system was verified to correctly handle buffering edge cases and maintain synchronization between sender and receiver.
Stress testing confirmed that the protocol remained stable under repeated connections and disconnections, ensuring robustness beyond ideal network conditions.
