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).

Server-initiated replicates

• 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 leases: From an object that is not altered in a long time, it is not expected to be altered in soon, so the lease time should be long.

• Renewal-frequency leases: Clients that frequently ask for an object, should have a larger expiration time.

• State leases: The bigger the load on the server, the shorter the periods should be.