hkarl · fyrk · Jun 13, 2024 · Jun 13, 2024 · Jun 24, 2024 · Jun 24, 2024
diff --git a/content/ch_00/ch_00.org b/content/ch_00/ch_00.org
@@ -40,13 +40,13 @@ In general: architectures and protocols of communication systems
 *** Distributed system (DS)?
 
 #+BEGIN_QUOTE
- A distributed system is a collection of independent computers that appears to its users as a single coherent system. 			-- A. S. Tannenbaum
+ A distributed system is a collection of independent computers that appears to its users as a single coherent system. 			\textendash{} A. S. Tannenbaum
 #+END_QUOTE
 
 
 #+BEGIN_QUOTE
  A distributed computing system consists of multiple autonomous processors that do not share primary memory but cooperate by sending messages over a communication network.
-				-- Henri Bal
+				\textendash{} Henri Bal
 #+END_QUOTE
 
 #+BEGIN_QUOTE
@@ -256,7 +256,7 @@ We will do mini-projects!
     \cite{Steen:DistributedSystems:2017}
   - Coulouris, Distributed Systems
     \cite{Coulouris:DistributedSystems:2011}  
-- Lot's of material online 
+- Lots of material online 
 
 
 *** Cancelled classes, compensate for missed classes

diff --git a/content/ch_01_basic_CS/ch_01_basic_CS.org b/content/ch_01_basic_CS/ch_01_basic_CS.org
@@ -126,7 +126,7 @@ We usually have some operations like:
     - Possibly, of specified properties: desired originator, maximum
       length, \ldots
     - Often, no guarantee on minimum length!
-  - Nonblocking (~man fcntl~, ~O_NONBLOCK~): Check whether message is available
+  - Non-blocking (~man fcntl~, ~O_NONBLOCK~): Check whether message is available
     - Copy into process' buffer if yes
     - Corresponding return value if no
     - Does never block process for longer time 
@@ -307,7 +307,7 @@ are allowed to occur
     - If it did not arrive with $T$ time, consider it lost
       $\rightarrow$ Timeout! 
 
-** Faults models 
+** Fault models 
 
 *** Fault models 
 
@@ -703,7 +703,7 @@ print("Received request: %s" % message)
 
 - Message Pack \textendash{} https://msgpack.org
 
-  - Lot's of language bindings; used by redis, Pinterest, ... 
+  - Lots of language bindings; used by redis, Pinterest, ... 
 
 - Cap'n Proto \textendash{} https://capnproto.org
 

diff --git a/content/ch_02_web_CS/ch_02_web_CS.org b/content/ch_02_web_CS/ch_02_web_CS.org
@@ -256,7 +256,7 @@ Hence division of labor:
     dynamic responses (a *web application*) 
     - Examples: Django \url{https://www.djangoproject.com}, Tomcat \cite{ApacheTo2:online}, Ruby on Rails
       \url{http://rubyonrails.org}, Play \url{https://www.playframework.com}, ...
-    - Lot's of fanboyism \textendash{} but some good comparisons
+    - Lots of fanboyism \textendash{} but some good comparisons
       (\href{https://en.wikipedia.org/wiki/Comparison_of_web_frameworks}{Ref1},
       \href{https://softwareengineering.stackexchange.com/questions/102090/why-isnt-java-used-for-modern-web-application-development}{Ref2})
 

diff --git a/content/ch_03_RPC_CS/ch_03_RPC_CS.org b/content/ch_03_RPC_CS/ch_03_RPC_CS.org
@@ -189,7 +189,7 @@ What if things go wrong?
   - At least once?
   - At most once? 
 
-*** Source or failures
+*** Source of failures
 
 - Request message is lost
 - Reply message is lost
@@ -639,7 +639,7 @@ import zerorpc
 
 c = zerorpc.Client()
 c.connect("tcp://127.0.0.1:4242")
-print c.hello("RPC")
+print(c.hello("RPC"))
 #+END_SRC
 
 
@@ -663,7 +663,7 @@ import zerorpc
 class StreamingRPC(object):
     @zerorpc.stream
     def streaming_range(self, fr, to, step):
-        return xrange(fr, to, step)
+        return range(fr, to, step)
 
 s = zerorpc.Server(StreamingRPC())
 s.bind("tcp://0.0.0.0:4242")
@@ -682,7 +682,7 @@ c = zerorpc.Client()
 c.connect("tcp://127.0.0.1:4242")
 
 for item in c.streaming_range(10, 20, 2):
-    print item
+    print(item)
 #+END_SRC
 
 
@@ -963,14 +963,14 @@ From \cite{RESTRepresen19:online}
 \small 
 
 #+BEGIN_SRC  html
- <html>
+<html>
 <body>
-  <form action="form_handler.php" method=”POST">
+  <form action="form_handler.php" method="POST">
     User Name: <input name="user" type="text" />
-   <input type="submit"value="Submit" />
+    <input type="submit"value="Submit" />
   </form>
- </body>
- </html>
+</body>
+</html>
 #+END_SRC
 
 But:  No DELETE, PUT,  ... supported!
@@ -1004,27 +1004,27 @@ But:  No DELETE, PUT,  ... supported!
 
 
 *** Examples
- - Several popular sites provide Web services 
-   - Yahoo, google, ebay, Amazon, … 
- - Example: Access to Google’s Map api 
+ - Several popular sites provide Web services
+   - Yahoo, Google, Ebay, Amazon, … 
+ - Example: Access Google Maps’s API
    - You’ll need: 
      - a programming language that can curl a URL 
      - Interpret the resulting JSON
 
 
-**** Example: Google Map Service                             :B_exampleblock:
+**** Example: Google Maps Service                             :B_exampleblock:
      :PROPERTIES:
      :BEAMER_env: exampleblock
      :END:
 \small 
 
 #+BEGIN_SRC python
- import requests
- import json
- 
- r = requests.get("https://maps.googleapis.com/maps/api/geocode/json?address=Warbugrstr. 100, Paderborn") 
- 
- print json.dumps(r.json(), indent=4)
+import requests
+import json
+
+r = requests.get("https://maps.googleapis.com/maps/api/geocode/json?address=Warbugrstr. 100, Paderborn") 
+
+print(json.dumps(r.json(), indent=4))
 #+END_SRC
 
 

diff --git a/content/ch_04_improving_CS/ch_04_improving_CS.org b/content/ch_04_improving_CS/ch_04_improving_CS.org
@@ -70,7 +70,7 @@
   - At runtime, errors are the manifestation of a fault in an
     unexpected state 
     - E.g.: memory cell was written with a 1, subsequent read returns a
-      0 owing to the bit flit fault  
+      0 owing to the bit flip fault  
   - Do not necessarily cause failure
 \pause 
 - *Failure*: System displays behavior contrary to specification 
@@ -1239,7 +1239,7 @@ Almost all!
 *** Towards better hashing: nodes and keys 
 
 - Keys and node identifiers: both chosen as \ac{GUID}
-- Node responsibility: from it's own GUID to the next bigger one by
+- Node responsibility: from its own GUID to the next bigger one by
   any node
 
 *** Distance  

diff --git a/content/ch_05_practical/ch_05_practical.org b/content/ch_05_practical/ch_05_practical.org
@@ -72,7 +72,7 @@ We need to automate the following tasks:
   instructions
   - Example
     \href{https://aws.amazon.com/getting-started/tutorials/launch-a-virtual-machine/}{Amazon Elastic Cloud}
-  - Lot's of clicking through web pages
+  - Lots of clicking through web pages
   - Gives you at the end an IP address, key pair for ssh access 
 
 ** Vagrant 
@@ -625,7 +625,7 @@ real-time) guarantees.
 - First step: Aggregates logs on a single machine
   - Instead of each process writing a text file in some weird
     location
-- Buzzword: syslogd and friedns 
+- Buzzword: syslogd and friends
 
 *** Distributed example: GrayLog 
 

diff --git a/content/ch_06_p2p_ncs/ch_06_p2p_ncs.org b/content/ch_06_p2p_ncs/ch_06_p2p_ncs.org
@@ -21,7 +21,7 @@ Recall memcached:
 #+BEAMER: \pause
 
 - Simple scheme, but does not scale well
-  - Lot's of state in clients 
+  - Lots of state in clients 
 
 *** Key-value stores, without explicit server list 
 
@@ -261,16 +261,16 @@ Content of cells?
 *** Example table structure for $v = 65A1FC$
 
 \footnotesize  
-|   |      0 |      1 |       2 |       3 |     4 |    5 |     6 |     7 |     8 |      9 | A  | B      | C      | D | E | F |
-|---+--------+--------+---------+---------+-------+------+-------+-------+-------+--------+----+--------+--------+---+---+---|
-| 0 |   0... |   1... |    2... |    3... |  4... | 5... |    -- |  7... |  8... |        |    |        |        |   |   |   |
-| 1 |  60... |  61... |   61... |   63... | 64... |   -- | 66... | 67... | 67... |        |    |        |        |   |   |   |
-| 2 | 650... | 651... |  652... |  653... |   ... |      |       |       |       | 659... | -- | 65B... | 65C... |   |   |   |
-| 3 | 65A0.. |     -- | 65A2... | 65A3... |       |      |       |       |       |        |    |        |        |   |   |   |
-| 4 |        |        |         |         |       |      |       |       |       |        |    |        |        |   |   |   |
-| 5 |        |        |         |         |       |      |       |       |       |        |    |        |        |   |   |   |
-| 6 |        |        |         |         |       |      |       |       |       |        |    |        |        |   |   |   |
-| 7 |        |        |         |         |       |      |       |       |       |        |    |        |        |   |   |   |
+|   |       0 |      1 |       2 |       3 |     4 |    5 |     6 |     7 |     8 |      9 | A  | B      | C      | D | E | F |
+|---+---------+--------+---------+---------+-------+------+-------+-------+-------+--------+----+--------+--------+---+---+---|
+| 0 |    0... |   1... |    2... |    3... |  4... | 5... |    -- |  7... |  8... |        |    |        |        |   |   |   |
+| 1 |   60... |  61... |   62... |   63... | 64... |   -- | 66... | 67... | 68... |        |    |        |        |   |   |   |
+| 2 |  650... | 651... |  652... |  653... |   ... |      |       |       |       | 659... | -- | 65B... | 65C... |   |   |   |
+| 3 | 65A0... |     -- | 65A2... | 65A3... |       |      |       |       |       |        |    |        |        |   |   |   |
+| 4 |         |        |         |         |       |      |       |       |       |        |    |        |        |   |   |   |
+| 5 |         |        |         |         |       |      |       |       |       |        |    |        |        |   |   |   |
+| 6 |         |        |         |         |       |      |       |       |       |        |    |        |        |   |   |   |
+| 7 |         |        |         |         |       |      |       |       |       |        |    |        |        |   |   |   |
 
 *** Routing table plus local neighbors 
 
@@ -554,7 +554,7 @@ Note: Variants exist
 
 * Other examples  
 
-*** Bittorrent 
+*** BitTorrent 
 
 - Perhaps the most alive of the remaining P2P systems
 - Emphasis splitting of big files into pieces
@@ -568,7 +568,7 @@ Note: Variants exist
 
 *** Mainline DHT  
 
-- DHT as used in (many clients for) Bittorrent 
+- DHT as used in (many clients for) BitTorrent 
 - Based on Kademlia 
 - Many implementations exist, e.g., https://github.com/the8472/mldht ,
   https://github.com/nictuku/dht (in golang) 

diff --git a/content/ch_07_mcast_ncs/ch_07_mcast_ncs.org b/content/ch_07_mcast_ncs/ch_07_mcast_ncs.org
@@ -471,7 +471,7 @@ def Receive(m, seqnr):
 #+BEAMER: \pause
 
 - But maybe that is good enough for typical applications
-- We ere on the side of safety here (overestimate causality) 
+- We err on the side of safety here (overestimate causality) 
 
 *** Preserving causality \textendash{} problems 
 
@@ -1017,10 +1017,10 @@ R_1 \vee \exists e: (e_1, e) \in R_1 \wedge (e, e_2) \in R$$
   - The happened-before relation represents only *potential* causality
     - All messages that *possibly* had influence on a given event
       contribute to this partial order
-  - It orders pairs of events that were not  cause/effect
+  - It orders pairs of events that were not cause/effect
     - But that is not decidable from perspective of a group
       communication protocol!
-  - So ere on the side of safety 
+  - So err on the side of safety 
 
 
 *** Happened-before relationship, concurrent events
@@ -1051,7 +1051,7 @@ R_1 \vee \exists e: (e_1, e) \in R_1 \wedge (e, e_2) \in R$$
 
 
  It holds:
- - a $\rightarrow$ f (via b, c, d)
+ - a $\rightarrow$ f (via c, d)
  - But: a and e are not ordered by $\rightarrow$; a and e are concurrent
 
 

diff --git a/content/ch_08_des_pubsub/ch_08_des_pubsub.org b/content/ch_08_des_pubsub/ch_08_des_pubsub.org
@@ -19,7 +19,7 @@
 
 - Send/receive
 - Unicast or multicast
-- Blocking or nonblocking 
+- Blocking or non-blocking 
 
 
 #+BEAMER: \pause

diff --git a/content/ch_09_msqQueuing/ch_09_msqQueuing.org b/content/ch_09_msqQueuing/ch_09_msqQueuing.org
@@ -462,7 +462,7 @@ e-business and developing e-business applications.
 - Supports multiple protocols; in particular, AMQP-0.9.1
 - Written in Erlang, runs on Erlang VM 
 - Cluster deployments for throughput and availability
-- Lot's of plugins
+- Lots of plugins
 - Open source plus commercial distribution (Pivotal) 
 
 
@@ -907,7 +907,7 @@ Topic:my-replicated-topic   PartitionCount:1    ReplicationFactor:3 Configs:
 - Mostly follows
   \href{https://kafka.apache.org/documentation/\#design}{Design discussion} 
 - Challenges to solve
-  - How to persist massages?
+  - How to persist messages?
   - How to get total order?
   - How to deal with failing servers? How to replicate? 
   - Efficiency! High throughput! 
@@ -1229,7 +1229,7 @@ Topic:my-replicated-topic   PartitionCount:1    ReplicationFactor:3 Configs:
 
 - Communicate anticlockwise
 
-#+CAPTION: LCR example ring: First two steps 
+#+CAPTION: LCR example ring: Eight steps 
 #+ATTR_LaTeX: :width 0.75\linewidth :options page=3
 #+NAME: fig:LCR_ring_complete
 [[./figures/leaderelect_ring.pdf]]
@@ -1248,7 +1248,7 @@ Topic:my-replicated-topic   PartitionCount:1    ReplicationFactor:3 Configs:
   - Number of nodes globally known 
   - Processes can fail, recover at indeterminate times
   - Time to broadcast is much smaller than MTTF, MTTR
-  - In typical operation, nodes only talks to leader, but not to other
+  - In typical operation, nodes only talk to leader, but not to other
     nodes 
 
 *** Source 
@@ -1683,7 +1683,7 @@ Core building block of leader election
 - Powerful programming model 
 - Decoupling allows scaling up
 - Fault tolerance is a *real* challenge
-- Lot's of powerful tools available, with different tradeoffs
+- Lots of powerful tools available, with different tradeoffs
   (cp. \href{http://queues.io}{Queues IO website})  
 
 
@@ -1699,7 +1699,7 @@ Core building block of leader election
 
 *** Support machinery 
 
-- To build really correct MQ systems, lot's of support machinery,
+- To build really correct MQ systems, lots of support machinery,
   algorithms is necessary
 - We touched upon leader election as a first step
 - But:

diff --git a/content/ch_11_distStorage/ch_11_distStorage.org b/content/ch_11_distStorage/ch_11_distStorage.org
@@ -773,7 +773,7 @@ Writer may proceed even if data not written yet
 - Observation: Protocols above do not support *locality* of programs
   - After accessing a variable once, it is likely that this variable
     or nearby variables are accessed in near future 
-- Non-blocking remote-write protocols: Lot's of update traffic
+- Non-blocking remote-write protocols: Lots of update traffic
 - Idea: Move primary: *local write* protocols 
 
 *** Local-write protocol without backup 

diff --git a/content/ch_14_nosql/ch_14_nosql.org b/content/ch_14_nosql/ch_14_nosql.org
@@ -212,7 +212,7 @@ consistent
   - Different query approaches
   - Different update semantics
     - Not uncommon: ACID locally, eventually consistent across cluster
-- But *very* hard to generalise; lot's of variability across products 
+- But *very* hard to generalise; lots of variability across products 
 *** Why? 
 
 - Making CAP tradeoffs explicit is a *very* good thing for developers
@@ -241,7 +241,7 @@ consistent
 
 - SQL is great, mature, familiar
 - Counterpart?
-  - Not much standardized \textendash{} lot's of diversity
+  - Not much standardized \textendash{} lots of diversity
 - SparQL: query RDF / tuple data
   - But not generalised to other types