tags: edist

Let's build! A distributed, concurrent editor: Part 6 - Testing

After a week off, I return to the distributed editor to write some tests for the server. How to test actors? How to write randomised and deterministic soak tests? And ultimately, how to build confidence that this system works like I claim it does.

Read more →

Let's build! A distributed, concurrent editor: Part 5 - Actors

I have chosen to use actors to structure the server. I believe this presents a simple model to understand, in terms of concurrency and state management, whilst allowing the server to scale and make use of multiple CPU cores. This week's instalment introduces the actors model, my actors library, and explains how I have used it for the distributed editor server.

Read more →

Let's build! A distributed, concurrent editor: Part 4 - Writing to disk

Back to the fun stuff: how shall I store the document and its editing history on disk? How do I calculate what the document should look like after receiving an undo or redo message? How do I get the server to make reasonable use of its CPU and disk resources so that it can scale well? These are the questions I'm exploring this week.

Read more →

Let's build! A distributed, concurrent editor: Part 3 - Client

This week I focus on the client: how does it send changes to the server; how does it process updates it receives from the server; how does it synchronise with the server when it first connects and then reconnects? It turns out that most of the problems the server faces, in terms of concurrent modifications to words, can also occur at the client because of concurrent changes received from the server, and received from the user typing.

Read more →

Let's build! A distributed, concurrent editor: Part 2 - Protocols

In Part 1 I set the scene. Alice and Bob haven't fully specified the system, but they've certainly given me some requirements: The exact behaviour of concurrent edits is left for me to define, but I'm not allowed to solve it trivially (i.e. just do nothing), and the key requirement is that all users should end up seeing the exact same document fairly quickly, once they're connected to the server; They want the editing history to be stored so that undo/redo will work even if they disconnect and reconnect; They want to be able to edit the document locally even when disconnected from the network. Some sort of synchronisation will need to happen when they reconnect to the network.

Read more →

Let's build! A distributed, concurrent editor: Part 1 - Introduction

The sun is bright and the sky's blue when I get to the office in London. As the lift doors ping open and I step out, a pair of heads near my desk swivel and look towards me. A sense of shame and embarrassment immediately forms in the pit of my stomach as I spot Alice and Bob sat waiting for me. I'd forgotten the meeting with them this morning that I'm late for.

Read more →