Peer-to-Peer Systems

Peer-to-peer Systems

In peer to peer systems, the guarantees offered by conventional servers may be violated by:

• Power failure and act of sabotage
• Accidental deletion of file and permission failure
• Tampering of data and denial of service attack
• Failures of HDD and program bugs

Attacks on the security of system software is a criminal breach of trust. PCs and servers must cope with users and provide trust for its services.

Peer-to-peer systems typically depend on untrusted and volatile computer systems for most of their resources. Trust is a social phenomenon with technical consequences. Volatility (i.e. unpredictable availability) also is often due to human actions.

• Ownership is important because they are liable if the trust is broken in a peer-to-peer system
• Geographic location is important in establishing barriers and access control
• Network connectivity is important because without it the peer-to-peer services are limited
• Country or legal jurisdiction again ties into legal accessibility of systems.

In unstructured peer-to-peer systems, significant improvements on search results can be provided by the adoption of particular search strategies.

In the standard random walk algorithm, the querying node forwards the query message to one randomly selected neighbor. This neighbor randomly chooses one of its neighbors and forwards the query message to that neighbor. This procedure continues until the data is found. Consider the query message as a walker. The query message is forwarded in the network the same way a walker randomly walks on the network of streets. The standard random walk algorithm uses just one walker. This can greatly reduce the message overhead but causes longer searching delay.

Expanded ring search:

Reactive routing protocols in MANETs such as DSR and AODV are often supported by a so-called Expanding Ring Search (ERS for short). During the route discovery stage, the RREQ (Route REQest packet) is broadcasted by flooding and propagated from one intermediate node to another to find the route information from the source to the destination node.

Considering drift rate is constant and known , then the only requirement is to only measure it between synchronization points with an accurate source and compensate for the drift.

For example, if the clock loses one second every hour, then we can add one second for every hour, in smooth increments, to return the value for the use but here the major difficulty is that the drift rate of clock is liable to be variable – for example, it may be a function of temperature. Therefore we need some adjustment method which is adaptive and guesses the drift rate, based on past behaviour, but which compensates when the drift rate is discovered to have changed to the next synchronisation point.

By considering a chain of zero or more messages connecting events e and e and using induction, show that e → e 0 ⇒ L(e) < L(e 0 ).

• If e and are successive events occurring at the same process, then the result is immediate from LC1.
• If there is a message m such that e=send (m) and e’=rcv (m), then the result is immediate from LC2.

Consider three processes in a ring, in the order P1, P2 and P3. Note that processes may send messages to one another independently of the token-passing protocol

The token is initially with P2. P1 requests the token, then sends a message to P3, which also requests the token. The message passes the token at P2. Then P2 sends on the token. P3 gets it, but the token should have been granted to P1 first.

In a certain system, each process typically uses a critical section many times before another process requires it.

A client that repeatedly enters the critical section has to issue a multicast request every time it requires entry. We can modify the Ricart and Agrawala's algorithm as follow: a token may be marked also as JUST RELEASED. This means that a client that finished with the critical section has not conveyed any information to other processes that it has finished with the critical section. If the client attemts to enter the critical section and finds the token to be JUST RELEASED, itcan change the state to HELD and re-enter the critical section.To meet the liveness condition ME2, a JUST RELEASED token should become RELEASED if a request for entry is received.

In the Bully algorithm, a recovering process starts an election and will become the new coordinator if it has a higher identifier than the current incumbent.

The number of processes reflect their relative advantage. In this case, the advantage maybe worth the re-election costs including the message rounds needed to implement the election. To avoid a re-election a recovery process could merely send a request, states message to successive lower numbered processes to discover whether another process is already elected.

A three-phase commit protocol has the following parts:

Phase 1: is the same as for two-phase commit.

Phase 2: the coordinator collects the votes and makes a decision;

if it is No, it aborts and informs participants that voted Yes;

if the decision is Yes, it sends a preCommit request to all the participants. participants that voted Yes wait for a preCommit or doAbort request. They acknowledge preCommit requests and carry out doAbort requests.

Phase 3: the coordinator collects the acknowledgments. When all are received, it Commits and sends doCommit to the participants. participants wait for a doCommit request. When it arrives they Commit.

Committing to the second phase:In the two-phase commit protocol:The ‘uncertain’ period occurs because a worker has voted yes but has not yet been told the outcome. Moving on to the third phase. In the three-phase commit protocol: The workers ‘uncertain’ period lasts from when the worker votes yes until it receives the Pre Commit request. At this point no other participant can have committed. If a group of workers discover that they are all ‘uncertain’ and the coordinator cannot be contacted, they can decide unilaterally to abort