Prepare next lecture

Author: s-macke

README.md

@@ -64,7 +64,7 @@ Each student will compare Go to one of these languages as Semester Work: Modula,
 ## Lecture 8 - Distributed Programming 
 - Introduction to Networking in Go
 - [Slides](https://s-macke.github.io/concepts-of-programming-languages/docs/08-Network-Programming.html)
-- [Slides](https://s-macke.github.io/concepts-of-programming-languages/docs/15-Distributed-Programming-Raft.html)
+- [Slides](https://s-macke.github.io/concepts-of-programming-languages/docs/08-Distributed-Programming-Raft.html)
 - [Exercise 8](docs/exercises/Exercise8.md)
 
 ## Lecture 9 - Systems Programming

docs/15-Distributed-Programming-Raft.slide renamed to docs/08-Distributed-Programming-Raft.slide

@@ -30,22 +30,31 @@ Terms are not always used consistently.
 *
 .background ./img/07-parallel-distributed.png 600 _
 
-* Message Passing
-Message Passing is invoking behavior on a separate process (not necessarily on the same computer) by sending messages.
+: * Message Passing
+: Message Passing is invoking behavior on a separate process (not necessarily on the same computer) by sending messages.
 
-Models for exchanging messages:
+: Models for exchanging messages:
 
-- point to point (symmetric/asymmetric, synchronous/asynchronous)
-- remote procedure calls (RPC, RMI)
-- broadcasting and multicasting
+: - point to point (symmetric/asymmetric, synchronous/asynchronous)
+: - remote procedure calls (RPC, RMI)
+: - broadcasting and multicasting
 
 : Sender schickt Nachricht an Empfänger
 : symmetrisch: beide kennen sich / asymmetrisch: nur ein eine Richtung
 : synchron: blockiert bis Nachricht gelesen
 : RPI: wie lokaler Prozeduraufruf
 
+* The two general problem
+
+.image ./img/08-two-generals-problem.png 400 _
+
+- The two generals problem is a thought experiment in distributed computing and unsolvable when the communication might fail.
+- We need a pragmatic solution.
+
 * What is Distributed Consensus?
-Distributed consensus is the problem how to achieve consistency in distributed systems. Distributed consensus protocols can be used for distributed databases which should stay consistent:
+
+The consensus problem requires agreement among a number of processes on a single data value.
+Distributed consensus protocols can be used for distributed databases which should stay consistent:
 
 - The system stays consistent even if some nodes goes down
 - The system stays consistent if a network partition occurs (but could get unavailable)
@@ -61,15 +70,15 @@ In a distributed system the following requirements can be met:
 Pick Two: Only two requirements can be met -> CP, AP are typical (CA does not exists)
 .link https://codahale.com/you-cant-sacrifice-partition-tolerance/
 
-: AP = DNS, Cloud Computing
-: CP = Geldautomat
-: CA = RDBMS?
+AP = DNS (Domain Name System)
+CP = Cash Machine
 
 * Securing C and P
 - All known algorithms use the concept of a quorum to detect network partition problems
 - Only the partition with the majority of nodes stay alive to ensure consistency
 - All known algorithms use the concept of a Master or Leader node to control replication
-- All known algorithms use a replicated log and implement a two phase commit
+- All known algorithms use a replicated log and implement a two phase commit.
+- A replicated log is a list of all changes which are applied to the system
 
 : Consistency & Partition Tolerance
 
@@ -91,7 +100,6 @@ Phases:
 .link https://github.com/lshmouse/reading-papers/blob/master/distributed-system/Zab:%20High-performance%20broadcast%20for%0Aprimary-backup%20systems.pdf The ZAB paper
 .link https://lamport.azurewebsites.net/pubs/lamport-paxos.pdf The Paxos Paper
 
-
 * Who uses Raft?
 - ectd - The Cloud Native key value store -> Part of Kubernetes!
 - Docker Swarm - Docker in cluster mode
@@ -133,42 +141,21 @@ Other implementations
 * Is it possible to build your own Raft implementation?
 Requirements and Decisions
 
-- We want to stay as close a possible on the original specification
-- We want to make a Raft cluster local testable (as single process)
-- We want to use gRPC as middleware
-.link https://github.com/s-macke/concepts-of-programming-languages/tree/master/dp/kvstore/core/raft
-.link https://github.com/s-macke/concepts-of-programming-languages/tree/master/dp/raft
-
-* Step I - Defining a KV Business API 
-.code ../src/distributed/kvstore/kvstore-api.go
-
-- This is the business API for setting and getting data in/out or Raft cluster
-
-* Step II - The Raft Interface : AppendEntries
-.code ../src/distributed/kvstore/core/raft/noderpc.go /type NodeRPC/
-.code ../src/distributed/kvstore/core/raft/noderpc.go /AppendEntries/,23
-- The interface could be easily proxied with gRPC or run locally without proxy
-
-* Step II - The Raft Interface : RequestVote
-.code ../src/distributed/kvstore/core/raft/noderpc.go /type NodeRPC/
-.code ../src/distributed/kvstore/core/raft/noderpc.go /RequestVote/,37
-
-* Step III - Implement the Raft Interfaces in a Server/Node
-.code ../src/distributed/kvstore/core/raft/node.go /type Node/,28
-
-* Step IV - Write Tests 
-.code ../src/distributed/kvstore/core/raft/node_test.go /TestElection/,33
+- We want to stay close on the original specification, but focus especially on the leader election.
+- We limit our use case to only 3 nodes.
+- We want to use easy built-in network mechanisms in Go such as HTTP. JSON not strictly necessary
 
 * Interesting Parts
-- Statemachine 
-- Concurrency: Behavoir of remote calls, election and heartbeat timers
+- State Machine
+- Concurrency: Behavior of remote calls, election and heartbeat timers
 - Design: Timer implementation
-- Clean Architecture: Separation of Raft and server APIs 
-- Clean Code: Testability
 
-* Be Creative!
+* Exercise 8.2: Be Creative!
+- Write your own Raft Implementation!
+
+.link https://github.com/s-macke/concepts-of-programming-languages/blob/master/docs/exercises/Exercise8.md
+
 - Write your own Raft Implementation!
-.link https://www.youtube.com/watch?v=YbZ3zDzDnrw More information
 
 * Summary
 - Go is an excellent choice to implement an distributed protocol like Raft