diff --git a/content/ch_00/ch_00.org b/content/ch_00/ch_00.org index 4a8b0e4..92ddb2f 100644 --- 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 index eb4eefe..94b3296 100644 --- 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 index 2ec6d4f..0a57497 100644 --- 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 index 70057e3..b13f66e 100644 --- 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 - + -
+ User Name: - +
- - + + #+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 index 0ce74e8..00b8666 100644 --- 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 index e1e4386..5f81411 100644 --- 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 index 06cac80..0e1b296 100644 --- 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 index 4c3d669..937f0be 100644 --- 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 index 47fa827..c3850e6 100644 --- 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 index 603f82d..f6167f1 100644 --- 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 index 4495b3e..e55de3d 100644 --- 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 index ec4b15c..b637da0 100644 --- 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