Fault Tolerance

Smockron is resilient against multiple failure scenarios. It attempts to preserve access to the resources it protects, even at the cost of potentially allowing some undesired requests to pass; that is, it is a "fail-permissive" design.

Because the gatekeeper uses local information to decide the disposition of each request instead of consulting the master, it has minimal impact on the latency of requests. If the gatekeeper is incorporated as part of an existing proxy or application then no additional network hops are added in the request path.

Because it is possible that the gatekeeper itself could have crashing bugs, it is recommended that it is installed in a part of the system which is not a single point of failure. Smockron is designed to provide rate-limiting in multi-machine distributed applications, and the gatekeepers should be distributed as well. If you prefer to funnel all of your traffic through a single point in order to rate-limit it, you can probably find something simpler than Smockron to do it with.

If the master crashes, accounting messages from the gatekeepers will be dropped, and the gatekeepers will receive no control messages. In the absence of control messages, the gatekeepers will allow all requests, preserving access to the underlying resource.

If the master becomes overloaded, it will queue and then drop accounting messages. If the processing delay for accounting messages is too long, the master may send control messages too late to be effective. If accounting messages are dropped, the master may think that the number of requests to a domain is less than it is. In both cases, requests might be allowed that would have been dropped in the ideal case of a master that responds instantly, but no requests will be delayed or rejected that would not have been otherwise.