Emergency-Alert-System
What it does
Emergency-Alert-System is a distributed publish-subscribe alert broadcasting system built on the STOMP protocol. A Java 8 server accepts connections from C++11 command-line clients, manages channel subscriptions, and broadcasts events to all subscribers. The server can run in two modes: thread-per-client, which allocates one OS thread per connection, and a non-blocking reactor mode built on Java NIO that multiplexes all connections through a single selector thread backed by an actor thread pool.
How it works
Thread-per-client versus reactor
In thread-per-client mode, each accepted connection gets its own OS thread. This is simple to implement and reason about — each thread blocks on reads and writes for its own client — but does not scale to thousands of simultaneous connections because each thread carries significant stack memory and scheduling overhead. In reactor mode, a single NIO selector thread monitors all connection sockets for readability and writability. When a socket is ready, the selector dispatches the work to an actor thread pool rather than blocking. This allows one selector to serve many connections with far fewer threads, at the cost of additional complexity in the event loop.
How a broadcast reaches only subscribers
When a client sends a SEND frame to a channel (for example, germany), the server looks up all clients that have previously sent a SUBSCRIBE frame for that channel and delivers a MESSAGE frame to each of them. The publishing client receives a RECEIPT frame instead of a MESSAGE — it is not subscribed to the channel it published to unless it explicitly sent a SUBSCRIBE frame. This separation between publishing and subscribing is a core property of the STOMP pub/sub model.
Design decisions
- STOMP was chosen over a custom protocol because it is a well-specified, text-based protocol that is easy to implement from scratch in both Java and C++, and its frame structure maps directly to pub/sub semantics.
- The two threading modes are selectable at startup rather than configurable at runtime; this was a deliberate choice to keep the implementation of each mode simple and fully separated.
- The C++ client uses Boost ASIO for asynchronous I/O, which mirrors the reactor pattern used in the Java server and allows the client to handle responses while blocked on user input.
- The server reads events to broadcast from a JSON file rather than accepting them interactively, which makes the set of test events reproducible and avoids parsing complexity in the client.
Stack
| Layer | Technology |
|---|---|
| Language | Java 8 |
| Infra | Maven |
| Messaging | STOMP |
| Language | Java NIO selector (reactor mode) |
| Language | C++11 |
| Infra | Make |
| Messaging | Boost ASIO |
| Messaging | Boost Thread |