about summary refs log tree commit diff
path: root/usth/ICT2.7/P3L1 Software Architecture Subtitles/26 - Skype Example - lang_en_vs5.srt
blob: 2118c7385704ac79e73bb1324af2c74805177711 (plain) (blame)
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
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
1
00:00:00,220 --> 00:00:03,040
So even if you're too young to have used Napster,

2
00:00:03,040 --> 00:00:06,150
I'm pretty sure that most of you know and use Skype,

3
00:00:06,150 --> 00:00:10,180
a Voice Over IP and instant messaging service. Many of

4
00:00:10,180 --> 00:00:13,790
you, however, probably don't know how Skype works. To understand that,

5
00:00:13,790 --> 00:00:16,360
let's have a look at Skype's architecture, which I'm sketching

6
00:00:16,360 --> 00:00:19,890
here, and which is a peer-to-peer architecture with a small twist.

7
00:00:19,890 --> 00:00:22,300
So first of all, by looking at the architecture we can

8
00:00:22,300 --> 00:00:25,600
see that whereas Napster was a client-server system with an element

9
00:00:25,600 --> 00:00:29,960
of peer-to-peer, Skype is a much more decentralized system. Why

10
00:00:29,960 --> 00:00:31,940
is that? Well, if we look here, we can see

11
00:00:31,940 --> 00:00:34,720
that there is a login server -- this node over

12
00:00:34,720 --> 00:00:38,670
here -- and that means that every Skype user has to register

13
00:00:38,670 --> 00:00:42,000
with this centralized service. But that's the only interaction of

14
00:00:42,000 --> 00:00:44,930
this kind within Skype. After you log in, all you

15
00:00:44,930 --> 00:00:47,580
get is a connection through a super node like this

16
00:00:47,580 --> 00:00:50,760
one. So, what are super nodes? Super nodes are highly reliable

17
00:00:50,760 --> 00:00:54,680
nodes with high bandwidth that are not behind a firewall

18
00:00:54,680 --> 00:00:58,180
and that runs Skype regularly, which means that nodes that shut

19
00:00:58,180 --> 00:01:01,540
down Skype occasionally will not qualify as super nodes. And one

20
00:01:01,540 --> 00:01:04,239
interesting thing about super nodes is that they're not owned by

21
00:01:04,239 --> 00:01:07,990
Skype. They're just regular nodes that get promoted by Skype to

22
00:01:07,990 --> 00:01:11,500
super nodes, and that know about each other. So basically Skype

23
00:01:11,500 --> 00:01:13,710
has an algorithm that looks at the nodes in the system

24
00:01:13,710 --> 00:01:15,880
and decides whether a node can be a super node or

25
00:01:15,880 --> 00:01:18,932
not based on its characteristics. So now that we've discussed

26
00:01:18,932 --> 00:01:22,040
super nodes, let's see what will happen if peer two wanted

27
00:01:22,040 --> 00:01:25,091
to communicate with peer three. So let's represent this by

28
00:01:25,091 --> 00:01:27,956
creating a dashed line between peer two and peer three. In

29
00:01:27,956 --> 00:01:30,980
this case, peer two will contact this super node, which

30
00:01:30,980 --> 00:01:33,750
is super node A. And super node A, based on its

31
00:01:33,750 --> 00:01:36,570
knowledge of the Skype network and the position of the super

32
00:01:36,570 --> 00:01:40,930
nodes, will contact and route the communication through super node C,

33
00:01:40,930 --> 00:01:44,100
which will in turn route the communication to peer three.

34
00:01:44,100 --> 00:01:46,620
And in that way peer two and peer three will be

35
00:01:46,620 --> 00:01:50,740
able to communicate with each other. And this will happen just

36
00:01:50,740 --> 00:01:53,970
as if peer two and peer three were connected directly, as

37
00:01:53,970 --> 00:01:57,760
peers, even though the communication goes through two super nodes. Another

38
00:01:57,760 --> 00:02:00,470
thing that is important to know about the behavior of Skype

39
00:02:00,470 --> 00:02:03,760
is that, if the link between super nodes A and C

40
00:02:03,760 --> 00:02:05,950
were to go down. So let's assume that there is a

41
00:02:05,950 --> 00:02:10,840
problem with this link, then Skype will automatically, or automagically

42
00:02:10,840 --> 00:02:14,550
reroute the communication through super node B, which will in

43
00:02:14,550 --> 00:02:17,950
turn reroute it super node C, which will again reroute

44
00:02:17,950 --> 00:02:20,020
to peer three. So peer two and three will still

45
00:02:20,020 --> 00:02:22,550
be connected, but this time they will be going through

46
00:02:22,550 --> 00:02:25,620
three super nodes. And just in case you wondered, this

47
00:02:25,620 --> 00:02:28,620
is exactly what happens when you are talking over Skype.

48
00:02:28,620 --> 00:02:31,790
The quality of the communication degrades, and you are reconnected.

49
00:02:31,790 --> 00:02:34,880
So there is this rerouting going on through different nodes. So

50
00:02:34,880 --> 00:02:37,640
although this architecture is more effective than the Napster's one, it

51
00:02:37,640 --> 00:02:40,640
is not without problems. For example, you might remember that a

52
00:02:40,640 --> 00:02:44,640
few years ago, Skype went down for about 36 hours. And

53
00:02:44,640 --> 00:02:47,880
later on it was discovered that the cause was the algorithm

54
00:02:47,880 --> 00:02:51,460
used by Skype to determine which nodes could be super nodes.

55
00:02:51,460 --> 00:02:54,330
And remember, as I said, that one requirement for these nodes

56
00:02:54,330 --> 00:02:57,130
is that have to up all the time. So what happened

57
00:02:57,130 --> 00:03:00,420
is most of the super nodes were running on Windows machines,

58
00:03:00,420 --> 00:03:03,820
and Microsoft pushed a critical patch that required a reboot to

59
00:03:03,820 --> 00:03:06,860
be installed. So a large number of machines, and therefore a

60
00:03:06,860 --> 00:03:10,150
large number of super nodes were down roughly at the same

61
00:03:10,150 --> 00:03:13,980
time throughout the globe. And Skype's algorithm for determining super nodes

62
00:03:13,980 --> 00:03:17,230
didn't have enough nodes to work with. So the whole system

63
00:03:17,230 --> 00:03:19,790
crashed and burned. So the message I want to give here,

64
00:03:19,790 --> 00:03:22,340
is that when you have a large peer to peer distributed

65
00:03:22,340 --> 00:03:24,650
system, such as this one, such as Skype,

66
00:03:24,650 --> 00:03:27,200
these kind of perfect storms can happen. Because you

67
00:03:27,200 --> 00:03:29,560
are not really in control. Because the control

68
00:03:29,560 --> 00:03:33,170
is distributed. So the algorithms become more complex. So

69
00:03:33,170 --> 00:03:35,140
to wrap up our Skype example, in case

70
00:03:35,140 --> 00:03:37,280
you are interested, Skype then fixed the issue by

71
00:03:37,280 --> 00:03:39,950
changing the algorithm for identifying super nodes. And

72
00:03:39,950 --> 00:03:44,084
more recently actually, Skype ditched peer-to-peer super nodes altogether.