DEV Community: Slavik

Building a parenting app with UDP

Slavik — Tue, 05 Aug 2025 13:38:43 +0000

The Problem That Started It All

When I needed a screen time limiting app for my child's Fire HD device, Amazon's built-in parental controls just didn't cut it for my specific use case. Like many developers faced with a problem, I decided to build my own solution. What started as a simple hardcoded timer has evolved into something much more interesting - a real-time parent control system using UDP communication over the local network.

From Simple Beginnings

The first version was beautifully simple: a hardcoded time limit with two buttons for the child to request extensions - one minute or five minutes. I implemented this because, let's be honest, kids always ask for "just a little bit more" time at the end!

The app reliably did what it needed to do: block the tablet with an overlay activity once the time credit was reached. Simple, effective, and it worked.

The Evolution: Adding Remote Parent Control

When I decided to open-source the app, I started polishing it and implementing features I'd always thought about but never had the time (or motivation) to build. The most interesting addition? A companion parent app that can communicate with the child's device over the local network.

Initially, I had implemented admin settings directly in the child app, but this approach had serious drawbacks:

Cumbersome to use: Parents had to physically access the child's device
Disruptive experience: It interrupted the child's interaction with the device
Impractical: Imagine trying to check time limits or grant extensions from across the room!

Enter UDP: The Perfect Protocol for Local Network Communication

This is where UDP (User Datagram Protocol) comes into play. But first, let's understand what UDP actually is:

What is UDP?

UDP is a communication protocol that's like sending postcards between devices:

Fast and lightweight: No handshaking or connection establishment needed
Broadcast capable: One device can send messages to all devices on the network
Simple: Perfect for local network communication where speed matters more than guaranteed delivery
Fire-and-forget: Send a message and move on - ideal for real-time controls

Unlike TCP (which is like a phone call - establishing a connection and ensuring every word is heard), UDP is more like shouting across a room - quick, direct, and perfect for commands like "check time remaining" or "extend time by 5 minutes."

Why UDP is Perfect for Parent-Child Device Control

Discovery: The parent app can broadcast "Is there a child device here?" and any child devices respond
Real-time commands: Instant blocking, time extensions, or status checks
No complex setup: No pairing, no account creation - just connect to the same WiFi
Local network only: Commands stay within your home network for privacy

The Technical Implementation

Here's how the system works:

1. Device Discovery

Parent App → Broadcasts: "CST_PARENT_DISCOVERY" on port 8888
Child Device → Responds: "CST_CHILD_RESPONSE" with device info

2. Secure Command Communication

All commands are encrypted using AES-CBC with device ID-based keys:

Parent App → Sends: "CST_CMD:[encrypted_command]"
Child Device → Responds: "CST_RESP:[encrypted_response]"

3. Available Commands

GET_TIME_LEFT: Check remaining screen time
LOCK_DEVICE: Immediately block the device
EXTEND_TIME:30: Add 30 minutes to the time limit

4. Real-World Usage Flow

Parent opens the companion app on their phone/tablet
App automatically discovers child devices on the network
Parent can see real-time status: time remaining, current state (active/blocked)
Instant control: Block immediately or grant time extensions
No disruption to the child's experience

The Security Layer

Since this involves controlling a child's device, security is paramount:

AES-CBC Encryption: All commands are encrypted using device-specific keys
Local network only: Commands never leave your home WiFi
Device ID-based keys: Each device has unique encryption keys
No internet required: Everything works offline

Code Deep Dive: The Discovery Service

Here's a simplified version of how the child device listens for parent commands:

public class ParentDiscoveryService extends Service {
    private static final int DISCOVERY_PORT = 8888;
    private static final String DISCOVERY_REQUEST = "CST_PARENT_DISCOVERY";
    private static final String DISCOVERY_RESPONSE = "CST_CHILD_RESPONSE";

    private void handleIncomingMessage(String message, InetAddress sender, int port) {
        if (DISCOVERY_REQUEST.equals(message)) {
            // Respond to discovery
            sendResponse(DISCOVERY_RESPONSE, sender, port);
        } else if (message.startsWith("CST_CMD:")) {
            // Handle encrypted command
            String encrypted = message.substring(8);
            String decrypted = securityManager.decryptMessage(encrypted);
            String response = processCommand(decrypted);
            // Send encrypted response back
        }
    }
}

Lessons Learned

Building this system taught me several valuable lessons:

Simple protocols work best: UDP's simplicity made implementation straightforward
Security can't be an afterthought: Encryption was essential for a family app
User experience drives architecture: The need for non-disruptive parent control shaped the entire design
Local-first is powerful: No internet dependency makes the system more reliable

The Technical Challenges

Of course, it wasn't all smooth sailing:

Challenge 1: Service Persistence

Android aggressively kills background services. The solution? Multiple layers of protection:

Foreground services with proper notification channels
AlarmManager for restart scheduling
WorkManager for periodic health checks

Challenge 2: Network Discovery

UDP broadcast doesn't always work reliably across all WiFi configurations. The solution:

Retry logic with exponential backoff
Multiple discovery attempts
Graceful degradation

Challenge 3: Encryption Key Management

Securely sharing encryption keys between devices without user complexity:

Device ID-based key derivation
SHA-256 hashing for consistent keys
No manual key exchange required

What's Next?

The UDP communication system opens up exciting possibilities:

Multi-device management: Control multiple child devices from one parent app
Usage analytics: Real-time monitoring and historical data
Family coordination: Multiple parent devices controlling the same child device

Try It Yourself

The project is open source and available on GitHub. The UDP communication system demonstrates how simple protocols can solve complex real-world problems elegantly.

Key Takeaways

Sometimes simple is better: UDP's simplicity made it perfect for this use case
Local network communication is underutilized: Many problems can be solved without cloud services
User experience should drive technical decisions: The need for non-disruptive control shaped the entire architecture
Security matters in family apps: Encryption is essential, even for local communication
Android background services require careful handling: Multiple protection layers are necessary

Have you built similar local network communication systems? What protocols and patterns have worked well for you? Share your experiences in the comments!

Technical Resources

UDP in Android: Android Developer Guide
Foreground Services: Best Practices for Background Work
AES Encryption in Java: Java Cryptography Architecture

Building a Toy SSTable Storage Engine in Python

Slavik — Tue, 01 Jul 2025 08:00:53 +0000

Have you ever wondered how modern databases like LevelDB, RocksDB, or Cassandra store and retrieve massive amounts of data efficiently? The secret sauce is often a data structure called the Log-Structured Merge-Tree (LSM-Tree) and its core component, the Sorted String Table (SSTable).

In this post, we’ll build a toy, educational SSTable-based storage engine in Python, inspired by Martin Kleppmann’s Designing Data-Intensive Applications. We’ll start simple and gradually add complexity, so you can follow along even if you’re new to storage internals!

What Are LSM-Trees and SSTables?

LSM-Tree stands for Log-Structured Merge-Tree. It’s a data structure designed to make writing data to disk very fast and efficient.

An SSTable is a file format for storing large, sorted key-value pairs on disk. The key properties are:

Sorted: All keys are stored in order, making range queries and binary search possible.
Immutable: Once written, SSTables are never modified. New data is written to new files.
Efficient: By combining in-memory and on-disk structures, SSTables enable fast writes and reasonably fast reads.

SSTables are the building blocks behind many modern, high-performance databases like LevelDB, RocksDB, and Cassandra.

How Does It Work?

Writes go to memory first: When you add or update data, it’s first stored in a fast, in-memory structure (called a memtable).
Flush to disk as SSTable: When the memtable gets full, all its data is written to disk as a new SSTable file. These files are never changed after being written.
Reads check memory and disk: When you read data, the system first checks the memtable, then searches through the SSTables on disk.

How Is This Different from Other Approaches?

Traditional databases (like those using B-Trees) update data in place on disk. This means lots of small, random writes, which can be slow on hard drives and even SSDs.
LSM-Trees always write new data in large, sequential chunks, which is much faster for disks.
SSTables are immutable, so there’s no need to lock files for writing, and old data can be cleaned up later in the background (a process called compaction).

Why Use LSM-Trees and SSTables?

Fast writes: Great for applications that need to handle lots of inserts and updates quickly (like logs, metrics, or time series data).
Efficient storage: Sequential disk writes are much faster and less likely to wear out SSDs.
Scalability: LSM-Trees can handle huge amounts of data by merging and compacting SSTables in the background.

Project Structure

Here’s what we’ll build (and you can find the full code on GitHub):

memtable.py: An in-memory, sorted key-value store.
sstable_writer.py: Writes sorted key-value pairs to disk as an SSTable, with a sparse index and Bloom filter.
sstable_reader.py: Reads from SSTables using the index and Bloom filter.
sstable.py: Orchestrates the LSM-Tree logic, combining memtable and SSTables.
simple_bloom_filter.py: A simple Bloom filter for fast negative lookups.
sstable_server.py: A UNIX socket server exposing set/get operations.
main.py: A CLI client to interact with the server.
stress_test.py: A script to stress test the system.

Step 1: The Memtable – Fast In-Memory Writes

When you write data, it first lands in the memtable—a sorted, in-memory structure. In our Python version, we use a sorted list and the bisect module for efficient lookups and inserts.

# memtable.py
class Memtable:
    def __init__(self):
        self._data = []

    def set(self, key, value):
        # Insert or update, keeping the list sorted
        ...

    def get(self, key):
        # Binary search for fast lookup
        ...

When the memtable gets too big, we flush it to disk as a new SSTable.

Step 2: Writing SSTables – Persistence and Order

Flushing the memtable means writing all its sorted key-value pairs to a file. But how do we make reads efficient?

Sparse Index: Every Nth key and its file offset are written to an index file. This lets us quickly jump to the right part of the SSTable.
Bloom Filter: A probabilistic data structure that tells us if a key is definitely not in the file, saving unnecessary disk reads.

# sstable_writer.py
class SSTableWriter:
    def write(self, sorted_kv_pairs):
        # Write data lines and build sparse index
        # Serialize and store the Bloom filter
        ...

Step 3: Reading SSTables – Fast Lookups

When you want to read a key:

Check the memtable (fastest).
Check the Bloom filter for each SSTable (quickly skip files that don’t have the key).
Use the sparse index to jump to the right spot in the SSTable file and scan for the key.

# sstable_reader.py
class SSTableReader:
    def get(self, key):
        # Use Bloom filter and sparse index to minimize disk I/O
        ...

Step 4: The LSM-Tree – Orchestrating Everything

The SSTable class manages the memtable, SSTable files, and the index cache. It handles:

Set: Write to memtable, flush to SSTable when full.
Get: Check memtable, then SSTables from newest to oldest.

# sstable.py
class SSTable:
    def set(self, key, value):
        ...
    def get(self, key):
        ...
    def flush(self):
        ...

Step 5: Server and CLI – Putting It All Together

We expose our storage engine via a simple UNIX socket server (sstable_server.py). You can interact with it using the CLI (main.py):

python -m sstable_server   # Start the server
python -m main set mykey 123
python -m main get mykey

Step 6: Stress Testing

How does it perform? The stress_test.py script:

Starts the server
Inserts 1000 random key-value pairs
Reads them all back and prints the sum and average

python stress_test.py

Why Does This Matter?

Write-Optimized: LSM-Trees and SSTables are designed for fast, sequential writes—perfect for write-heavy workloads.
Efficient Reads: Sparse indexes and Bloom filters keep reads fast, even as data grows.
Real-World Use: These ideas power LevelDB, RocksDB, Cassandra, and more.

Next Steps

This project is a toy—but it’s a great way to learn! You can extend it by adding:

Compaction (merging old SSTables)
Range queries
Deletion markers (tombstones)
Compression

Conclusion

Building your own SSTable-based storage engine is a fantastic way to understand the internals of modern databases. By starting simple and adding complexity, you’ll gain intuition for how real-world systems handle massive data efficiently.

Check out the full code on GitHub and try it yourself!