> For the complete documentation index, see [llms.txt](https://davidjosearaujo.gitbook.io/notes-miect/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://davidjosearaujo.gitbook.io/notes-miect/computacao-distribuida/flaw-tolerance/halting-failures.md).

# Halting failures

## Scenario

*C* does not notice any activity from *C'* - Terminal failure?

* Distinguishing between a *crash* and a failure by omission/temporal can be impossible.

## Asynchronous vs. Synchronous systems

* **Asynchronous system:** does **not assume** anything about the **speed** **of execution** of a **process** of delivery times of messages -> **it is not possible to reliably detect *****crashing***** failures***.*
* **Synchronous system:** execution times and message deliveries are delimited -> **it is possible to reliably identify temporal and omission failures**.

In practice, we have **partial synchronous systems:** most of the time we can assume that the system behaves synchronously, despite the fact that there are no limits to the moments when it behaves asynchronously -> **usually, failures by a *****crash***** can be detected**.

## Terminal failures

| Type of stop   | Description                                                                |
| -------------- | -------------------------------------------------------------------------- |
| Fail-stop      | Failure by *crash*, but reliably detected.                                 |
| Fail-noisy     | Failure by *crash*, eventually not detected.                               |
| Fail-silent    | Failure by omission or *crash*: client does not distinguish what happened. |
| Fail-safe      | Arbitrary, but benign.                                                     |
| Fail-arbitrary | Arbitrary, with malicious failures.                                        |