Implementation of an Algorithm for Peer-to-Peer Collaborative - - PowerPoint PPT Presentation

implementation of an algorithm for peer to peer
SMART_READER_LITE
LIVE PREVIEW

Implementation of an Algorithm for Peer-to-Peer Collaborative - - PowerPoint PPT Presentation

Implementation of an Algorithm for Peer-to-Peer Collaborative Editing Damien Aymon Ecole Polytechnique F ed erale de Lausanne, Switzerland June 20, 2017 damien.aymon@epfl.ch (EPFL) ABTU Implementation June 20, 2017 1 / 28 Outline


slide-1
SLIDE 1

Implementation of an Algorithm for Peer-to-Peer Collaborative Editing

Damien Aymon ´ Ecole Polytechnique F´ ed´ erale de Lausanne, Switzerland June 20, 2017

damien.aymon@epfl.ch (EPFL) ABTU Implementation June 20, 2017 1 / 28

slide-2
SLIDE 2

Outline I

1

Introduction

2

Goals

3

Corresponding Background Operational Transformation ABTU Algorithm

Important notions Undo of Operations Description of the Algorithm

4

Design and Implementation ABTU Instance The Big Picture Receiving Buffer Manager Frontend Controller ABTU Controller The Big Picture Communication with Peers

damien.aymon@epfl.ch (EPFL) ABTU Implementation June 20, 2017 2 / 28

slide-3
SLIDE 3

Outline II

5

Results

6

Limitations of the Project and Future Work

7

Conclusion

damien.aymon@epfl.ch (EPFL) ABTU Implementation June 20, 2017 3 / 28

slide-4
SLIDE 4

Introduction

Introduction

Real-time collaborative editing tools (Google Docs, ...) are widely used nowadays. Requirements: simultaneous editing of a shared document convergence undo of operations

damien.aymon@epfl.ch (EPFL) ABTU Implementation June 20, 2017 4 / 28

slide-5
SLIDE 5

Introduction

Introduction

Major issue : dependence on a central server implies loss of control

  • ver the data

Solution is ABTU : a decentralized p2p algorithm for collaborative editing ABTU has been proven to converge

damien.aymon@epfl.ch (EPFL) ABTU Implementation June 20, 2017 5 / 28

slide-6
SLIDE 6

Goals

A Bigger Project

Implementation of ABTU is part of a bigger project: a user friendly software for collaborative editing. Three main parts in the design Frontend: user interface and database (JavaScript) ABTU Instance: actual ABTU implementation (Go) Management: Links frontend and ABTU Instance (Go)

damien.aymon@epfl.ch (EPFL) ABTU Implementation June 20, 2017 6 / 28

slide-7
SLIDE 7

Goals

Goals

Implement p2p communication between two sites Implement ABTU algorithm and design interface with management and frontend If enough time is left Test the implementation Evaluate the performance of the algorithm Link ABTU implementation with frontend

damien.aymon@epfl.ch (EPFL) ABTU Implementation June 20, 2017 7 / 28

slide-8
SLIDE 8

Corresponding Background Operational Transformation

Document and Operations

A document is a string of characters Each site has its own copy of the document Operations (INS, DEL) are executed on the local copy: OP(siteId, type, position, character) ”abc” ”abcd” OP(0, INS, 4, d)

Figure: Execution of an Operation on a String. Own Illustration

damien.aymon@epfl.ch (EPFL) ABTU Implementation June 20, 2017 8 / 28

slide-9
SLIDE 9

Corresponding Background Operational Transformation

Operations are concurrent

Local operation must applied at all other sites. Site 1 ”abc”

  • 1 = OP(1, INS, 0, z′)

”zabc”

  • 2

”zac” Site 2 ”abc”

  • 2 = OP(2, DEL, 3, c)

”ab”

  • 1

”zab”

Figure: Generation of two Concurrent Operations. Own Illustration.

damien.aymon@epfl.ch (EPFL) ABTU Implementation June 20, 2017 9 / 28

slide-10
SLIDE 10

Corresponding Background Operational Transformation

Operational transformation

Before a remote operation is executed, is should be transformed: Operational transformation.

damien.aymon@epfl.ch (EPFL) ABTU Implementation June 20, 2017 10 / 28

slide-11
SLIDE 11

Corresponding Background ABTU Algorithm

Time

Vector clocks are used to keep track of time: When an operation is generated, time increases. Operations are timestamped.

damien.aymon@epfl.ch (EPFL) ABTU Implementation June 20, 2017 11 / 28

slide-12
SLIDE 12

Corresponding Background ABTU Algorithm

Character Order

There is a relation between characters in the system (effects relation), even between two characters not present in the same document state. Conceptually, a ≺ b if a precedes b in the document.

damien.aymon@epfl.ch (EPFL) ABTU Implementation June 20, 2017 12 / 28

slide-13
SLIDE 13

Corresponding Background ABTU Algorithm

Undo of Operations

The undo of an operation is achieved applying its inverse. Some operations cannot be undone: Define o1 = OP(1, INS, 0, a) and o2 = OP(1, DEL, 0, a)

  • 2 depends on o1

Timestamps keep track of the dependence between operations.

damien.aymon@epfl.ch (EPFL) ABTU Implementation June 20, 2017 13 / 28

slide-14
SLIDE 14

Corresponding Background ABTU Algorithm

Causality and Admissibility Preservation

Two important principles which enforce the convergence of ABTU: Causality preservation: if o1 → o2, then o1 must be invoked before o2. Admissibility preservation: execution of any operation respects effects relation ≺.

damien.aymon@epfl.ch (EPFL) ABTU Implementation June 20, 2017 14 / 28

slide-15
SLIDE 15

Corresponding Background ABTU Algorithm

History and Receiving Buffer

To preserve causality, remote operations are treated once causally ready. Receiving buffer RB stores untreated remote operations Before being executed, remote operation must be transformed against executed operation. History buffer H stores all operations locally executed, in effects relation order.

damien.aymon@epfl.ch (EPFL) ABTU Implementation June 20, 2017 15 / 28

slide-16
SLIDE 16

Corresponding Background ABTU Algorithm

Local Thread

After local operation has been executed locally: Time is incremented Operation is timestamped Operation is distributed If the operation is an undo: The original operation is recovered. Its inverse generated and applied. The steps for normal operations executed.

damien.aymon@epfl.ch (EPFL) ABTU Implementation June 20, 2017 16 / 28

slide-17
SLIDE 17

Corresponding Background ABTU Algorithm

Remote Thread

When local thread is not busy, causally ready operation o from RB is treated:

  • is transformed against concurrent operations in H.

Local time is incremented

  • ′ is executed.
  • ′ is integrated in H.

If o is an undo, original operation is marked as undone.

damien.aymon@epfl.ch (EPFL) ABTU Implementation June 20, 2017 17 / 28

slide-18
SLIDE 18

Design and Implementation ABTU Instance

ABTU Instance as a ”plug-and-play” module

An instance of the algorithm is represented by a Go structure ABTUInstance: Uses 4 Go channels for communication. Can be plugged in any frontend that respects the interface. Frontend Management ABTU Instance TCP Connection Go Channels

Figure: General Organization of the Software. Own Illustration.

damien.aymon@epfl.ch (EPFL) ABTU Implementation June 20, 2017 18 / 28

slide-19
SLIDE 19

Design and Implementation The Big Picture

The Big Picture

Remote Listener RBM ABTU Controller Local Thread Remote Thread remoteToABTU localToABTU ABTUToLocal ABTUToRemote AddOp GetCausallyReadyOperation RemoveRearrange

Figure: The Big Picture. Own Illustration

damien.aymon@epfl.ch (EPFL) ABTU Implementation June 20, 2017 19 / 28

slide-20
SLIDE 20

Design and Implementation Receiving Buffer Manager

Receiving Buffer Manager

Two tasks use the receiving buffer concurrently: Remote operations are put into RB Remote thread requests causally ready operation There is a need for a concurrent datastructure, the receiving buffer manager RBM.

damien.aymon@epfl.ch (EPFL) ABTU Implementation June 20, 2017 20 / 28

slide-21
SLIDE 21

Design and Implementation Frontend Controller

Frontend Controller

Life of a local operation:

1 Frontend generates and applies local operation o. 2 o is sent to ABTU Instance 3 o is integrated into H and distributed.

No remote operation can be integrated into H between steps 1 and 3.

damien.aymon@epfl.ch (EPFL) ABTU Implementation June 20, 2017 21 / 28

slide-22
SLIDE 22

Design and Implementation Frontend Controller

Frontend Controller

Frontend implements a controller for the execution of operations: No remote operation can be executed as long as pending local

  • perations have not been integrated.

Wait for ackLocalOperation from ABTU before accepting remote

  • perations

For a local undo: No operation can be executed nor generated before undo operation is received from ABTU. Wait for ackLocalUndo from ABTU.

damien.aymon@epfl.ch (EPFL) ABTU Implementation June 20, 2017 22 / 28

slide-23
SLIDE 23

Design and Implementation ABTU Controller

ABTU Controller

ABTU instance must implement a controller to give priority to local

  • perations:

ABTU instance must listen for local operations. Listen for local operation and handle it. Ask for causally ready operation or to RBM. Handle or and send result to frontend. Changes to H, SV and RB should not be applied but stored. If local operation is received before ”ackRemoteOperation”, discard

  • changes. Apply changes otherwise.

damien.aymon@epfl.ch (EPFL) ABTU Implementation June 20, 2017 23 / 28

slide-24
SLIDE 24

Design and Implementation The Big Picture

The Big Picture

Remote Listener RBM ABTU Controller Local Thread Remote Thread remoteToABTU localToABTU ABTUToLocal ABTUToRemote AddOp GetCausallyReadyOperation RemoveRearrange

Figure: The Big Picture. Own Illustration

damien.aymon@epfl.ch (EPFL) ABTU Implementation June 20, 2017 24 / 28

slide-25
SLIDE 25

Design and Implementation Communication with Peers

Peer-to-Peer Communication

The communication with other peers is done by using the go-libp2p library: A peer is represented by its ip/tcp address, siteId and peerId. A communicationService struct can be instanciated with a list of peers. The communicationService provides two Go channels for communication (sending/receiving). The communication is part of the management. This is done to allow more than only ABTU operations to be shared over the network.

damien.aymon@epfl.ch (EPFL) ABTU Implementation June 20, 2017 25 / 28

slide-26
SLIDE 26

Results

Results

The implementation has been tested in different ways. Let us execute one

  • f them:

Two ABTU instance communicate with each other over p2p. Local operations are sent to the first instance. The resulting input/output is printed out in the log for both instances.

damien.aymon@epfl.ch (EPFL) ABTU Implementation June 20, 2017 26 / 28

slide-27
SLIDE 27

Limitations of the Project and Future Work

Limitations and Future Work

Some feature to be implemented: Stopping of an instance is not implemented. Communication protocol between peers must be improved ... ... to allow for features such as peer joining/leaving. Error handling: integrate it in communication with management. Secure communication. Project continuation: Further in depth testing of the ABTU implementation Performance evaluation Linking with management and frontend. Feature implementation

damien.aymon@epfl.ch (EPFL) ABTU Implementation June 20, 2017 27 / 28

slide-28
SLIDE 28

Conclusion

Conclusion

Algorithms for P2P collaborative editing are complex but nonetheless interesting. The implementation of ABTU requires a deep understanding of the ABTU framework. The perspective of a complete software with an intuitive graphical interface is exciting.

damien.aymon@epfl.ch (EPFL) ABTU Implementation June 20, 2017 28 / 28