-
Notifications
You must be signed in to change notification settings - Fork 7
/
distributed-systems.txt
executable file
·55 lines (41 loc) · 2.38 KB
/
distributed-systems.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
===================
Distributed Systems
===================
Earlier versions of this tutorial did not contain this section. If you
remember, in the introduction I mentioned that concurrent programming paradigms
will be necessicary to take advantage of multi-CPU machines and distributed
clusters of computers. Several observant readers were quick to point out that
stackless python only runs on a single OS thread. That is, it has no inherant
ability to take advantage of multiple CPU machines or distributed systems.
This is true. Stackless python doesn't immediately 'scale' to take advantage
of these systems.
Hopefully, while reading this tutorial you've noticed a trend towards
communicating by passing simple read-only data via message passing. By using
simple read-only messages to communicate between tasklets, we create programs
that are easier to understand and less likely to have obscure bugs than other
multi-threaded techniques.
If you think about that for a second, then distributed systems aren't really a
big deal. Instead of sending messages via a channel, we can just send the same
messages over a standard network socket to achieve the same result. In this
case, a distributed system can be either multiple processes running on the same
box, or processes running on different boxes.
----------------------------
Simple Network Communication
----------------------------
So let's create a simple message passing API using network sockets.
------------------------------
Physically Distributed Systems
------------------------------
Let's start off with a distributed system where the nodes would be located in
seperate physical locations. In this case, we'll imagine an ATM network where
several ATM machines located throughout the world communicate with a central
bank to add and remove money from user's accounts.
-------------------
CPU Intensive Tasks
-------------------
Another reason to use distributed systems is to break a CPU intensive task across multiple processes or machines. In this case we'll we'll use a naive prime number generator. It demonstrates the two key factors that determine the ability to distribute the workload:
+ It is computationally intensive.
+ It can be broken down into discrete chunks. Testing each number is an
independent operation that is not reliant on the results of testing
another number.
Let's start with a simple program: