Power-Cut-Resilient Programming Lab Exam Server That Runs on the Local Network

The problem: a power cut halfway through a lab exam

Programming lab exams in many Pakistani universities follow the same pattern. Fifty students sit in a lab, write code for two hours, and submit through a learning management system or by copying files to a shared folder. Then the power goes. Some machines are on a backup supply and some are not. The internet drops. A student who had not saved loses forty minutes of work. Another claims they lost work when they did not. The invigilator has to decide, on the spot, who gets extra time.

Online platforms make this worse, not better, because they depend on an internet connection the lab does not reliably have. Teachers end up going back to paper or to files on USB drives, which makes automatic testing and integrity checks impossible.

What already exists and the gap

• Moodle with the CodeRunner plugin lets teachers write programming questions with automatic tests, and is widely used for programming exams. It assumes a working connection to the Moodle server for the whole exam.
• Safe Exam Browser, developed by ETH Zurich IT Services, locks a computer down during an exam and works with Moodle, Canvas, Open edX and other systems. It controls the machine, not resilience to outages.
• Online judges and coding platforms run code well but are hosted on the internet.

The gap is a lab-first system: one server in the room, every change saved continuously, work that survives a power cut and resumes on any machine, and timing that is fair and auditable.

Inspiration

CodeRunner (Lobb and Harlow, "CodeRunner: a tool for assessing computer programming skills", ACM Inroads, 2016) showed how programming questions with automatic tests can run inside a learning management system, with students getting results as they work. Your project keeps that idea of test-driven questions but rebuilds the delivery for unreliable power and networks, borrowing the write-ahead logging approach databases use to survive crashes.

What you build

• Teachers create an exam with questions, starter code and tests, and load it onto the lab server.
• Students log in at any machine, write code in a browser editor and run tests. Every change is saved. If a machine dies, they move to another and continue from where they were.
• Invigilators see a live seat map: who is connected, who has lost connection, who has asked for help, and any outage time added.

The technically interesting part

• Saving without losing anything. Send small edit operations to the server over WebSockets and write them to an append-only log before acknowledging. Keep a copy in the browser's local storage too, and reconcile on reconnect. Test with real power cuts on a test machine.
• Fair time. Decide how to measure an outage: the server can see when a student's connection dropped and came back. Pause the student's clock only for verified outages, cap the total, and log every change for the teacher to review.
• Safe code execution. Student code runs on the same server that holds the exam. Use containers or nsjail with limits on CPU, memory, processes and network, and test it with deliberately hostile programs.
• Server survives too. The lab server itself may lose power. Use a database configured for durability, and test that the server restarts cleanly with no lost submissions.
• Integrity without spying. Edit history replays help investigate suspected copying, but students should know what is recorded. Show a clear notice.

How to evaluate it

• Data loss: in 50 forced power cuts on client machines and 10 on the server, how many characters of work were lost? The target is none beyond the last second.
• Resume time: time from switching on a different machine to continuing work.
• Sandbox safety: results of a set of attack programs such as fork bombs, network access and file system escapes.
• Load: response time with 60 simulated students running tests at once on modest hardware.
• Real use: feedback from a teacher, invigilators and students after one real lab test.

Suggested plan

• Weeks 1 to 3: study CodeRunner and Safe Exam Browser, interview two lab teachers, design the save protocol.
• Weeks 4 to 7: editor, autosave, reconnect and resume.
• Weeks 8 to 10: sandboxed test runner and exam authoring.
• Weeks 11 to 13: invigilator dashboard, fair timing, edit replay and load tests.
• Weeks 14 to 15: real lab trial, report and demo.

Path to a product

Universities, colleges and training institutes across South Asia run programming exams in labs with unreliable power and internet. A free self-hosted edition, with paid installation, support and integration with each university's systems, is a realistic model. The project shows employers backend, reliability and security skills on a problem every examiner recognises.

Scope warning

Do not build a full learning management system; focus on the exam itself and export results. Support two languages well before adding more. Never run student code outside a sandbox, even in a quick demo. Get written permission before trialling in a real assessment, and start with a practice test rather than a graded exam.

Learn what you need on Sefism

• Backend development roadmap: WebSockets, durable storage and servers.
• Linux, terminal and Git roadmap: processes, limits and running services on one machine.
• DevOps and cloud roadmap: containers and isolation for the code runner.
• PostgreSQL Documentation: durability settings and write-ahead logging.
• OWASP Cheat Sheet Series: guidance for running untrusted code safely.
• Docker Docs: Get Started: building the sandbox images.

Get help with this idea

The risk is a system that works in a demo but loses work in a real power cut, or a sandbox that a clever student can escape. Tauseef can help you design the save protocol, plan the failure tests and approach a department for a trial. If you are new here, create a free account first.

• Discuss this idea with a mentor
• Send a query to Tauseef
• Book a 1:1 session