WAR LESSONS

Eber Cruz — Software Engineer | C-FARARONI Project
February 2026 · S.A.T.I. Protocol / Java 25 / Sidecar Architecture
Finding: Availability failure due to I/O blocking in frozen external processes.

During stress tests of the S.A.T.I. swarm, a child process failure was simulated using the SIGSTOP signal (total execution freeze). Unlike a SIGKILL (where the process dies and the OS closes file descriptors), a process under SIGSTOP retains its descriptors but stops consuming data from its pipes.

In the initial Sidecar implementation, the message sending method was synchronized. This caused a cascading failure:

• Pipe Block: The Sidecar attempted to write to the frozen child process's stdin. The pipe buffer filled up and the Java write thread was blocked at the Kernel level (I/O Wait).
• Monitor Deadlock: Being a synchronized method, the Watchdog thread (the sentinel) attempted to acquire the lock to perform an emergency restart, but could not enter because the write thread was trapped waiting for the child process to wake up.
• Result: The Sidecar became "zombie", unable to heal itself despite having an active Watchdog.

In a traditional REST/HTTP-based architecture:

• The HTTP server consumes resources (ports, sockets) while waiting.
• Network timeouts often depend on the OS's TCP stack, which can cause unpredictable latencies.
• If the process freezes, the socket remains in CLOSE_WAIT or similar, filling the system's descriptor table.

We redesigned the Sidecar to be "Freeze-Resilient" using Java 25 capabilities:

• Dropping synchronized: We implemented ReentrantLock with tryLock(timeout). If the data tunnel does not accept information within 200ms, the thread releases control immediately, avoiding the deadlock.
• Watchdog Isolation: The hardReset() method now has absolute priority and can execute process.destroyForcibly() without waiting for the release of data I/O locks.
• Virtual Threads: We use Java 25's lightweight concurrency model so that each communication attempt is cheap and does not block the operating system, allowing the Sidecar to handle thousands of "zombie tunnels" without exhausting RAM.

Based on implementation phase tests, the Sidecar with Isolated Sentinel architecture has proven superior to standard microservice implementations.

Essential commands for managing the swarm:

Check Swarm Health:

# Monitor latency and status of all 5 nodes in real time
nats sub "fararoni.sati.registry"

Simulate Freeze Attack (Resilience Test):

# Freeze the victim; the Watchdog should detect it in < 5s
kill -STOP <PID_MCP_SERVER>

The Panic Button (Global Hard Reset):

# Force restart of ALL STDIO processes simultaneously
nats pub "fararoni.sati.control.panic" "HARD_REBOOT"

The S.A.T.I. protocol does not just act as a bridge; it acts as an active supervisor. By treating I/O failures as first-class events, we guarantee that the Fararoni Kernel always has a path back to the "Golden State", even when external processes enter deep corruption states.

The success of this implementation phase confirms that technological sovereignty is not just about having the code, but having absolute control over the execution lifecycle.

• Separation of Powers: By keeping Java as the Manager (control logic) and Node.js as the Worker (tool execution), we create a system where the failure of one component does not compromise the integrity of the brain (Kernel).
• Cost Efficiency: We do not need expensive load balancers (F5, AWS ALB). Network intelligence resides in the Sovereign Event Bus and recovery intelligence in the Sidecar.
• Security by Obscurity: By using STDIO-TUNNEL, MCP servers are invisible to the network. There are no open ports, no external attack surface.

As shown in the demo-ataque-enjambre.sh script, the final post-attack validation launches a file read request (read_file) to the wounded swarm. The result: [SUCCESS] SELF-HEALING SYSTEM CONFIRMED. Although 40% of the nodes were attacked, the request was processed by the remaining nodes in ~4.2ms, demonstrating that the end user never perceives the internal chaos.