# Replicates

## Location

Discovering which are the best _k_ spots from _N_ possible spots.

* Selecting the best spot from _N_ possible spots for which the average distance to the clients is minimum. After that, choose the best server. Repeat the process _k_ times. _**(costly)**_
* Select the _k_ biggest autonomous systems and place a server in the best-connected computer. _**(costly)**_
* Place nodes in a _d-dimensional_ space, where the distance reflects the latency. Identify _k_ regions with the greatest density and place a server in each. _**(cheap)**_

## Content replication

Distinguish the different processes:

* **Permanent replicates:** Process/machine has always a replicate.
* **Server-initiated replicates:** The process can, dynamically, host a replicate by request of the server.
* **Client-initiated replicates:** The process can, dynamically, host a replicate by request of a client (client cache).

<figure><img src="https://2387753953-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F9sVneYw7epWOEEPKsfCf%2Fuploads%2FG6c0aomaS6weWhdhuZ1P%2Fa.png?alt=media&#x26;token=b9c1888e-a54a-4b93-89a3-055b2e09cd6e" alt=""><figcaption></figcaption></figure>

### Server-initiated replicates

<figure><img src="https://2387753953-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F9sVneYw7epWOEEPKsfCf%2Fuploads%2FBlttRTwPabNsLgFYR1v9%2Fa.png?alt=media&#x26;token=2d2d260a-2665-4c82-85cd-2af63648fc02" alt=""><figcaption></figcaption></figure>

* Keep the **number of accesses by file**, and **aggregate by server**.
* The number of accesses drops below _D_ -> erase file.
* The number of accesses surpasses _R_ -> replicate file.
* The number of accesses is between _D_ and _R_ -> migrate file.

## Content distribution

Considering only client-server:

* Propaget only the **notification**/invalidation of an update (caches).
* Transfer **data** from one copy to another (distributed DB): **passive replication**.
* Propagate an **update** operation to other copies: **active replication**.

### Client-server

* **Push updates:** initiated **by the server**, the update is **propagated independent** of the fact whether the **destination has requested it or not**.
* **Pulling updates:** initiated **by the client**, where the **client asks for the updates**.
* It is possible to commutate between the two modes through _leases_: a contract in which the server promises to _push_ the updates to the client until the contract expires.

|                        | Push-based                                                          | Pull-based               |
| ---------------------- | ------------------------------------------------------------------- | ------------------------ |
| Server state           | List of replicates in the clients and caches                        | N/A                      |
| Exchanged messages     | Update (and possibly a _fetch-update_ if there was an invalidation) | _Poll_ and _Update_      |
| Client's response time | Immediate (or the time of a _fetch-update_)                         | Time of a _fetch-update_ |

### _Leases_

The time of the lease must be dependent on the behavior of the system:

* **Age-based&#x20;**_**leases**_**:** From an object that is **not altered in a long time**, it is not expected to be altered in soon, so the _**lease**_**&#x20;time should be long**.
* **Renewal-frequency&#x20;**_**leases**_**:** Clients that **frequently ask** for an object, should have a **larger expiration time**.
* **State&#x20;**_**leases**_**:** The bigger the load on the server, the shorter the periods should be.
