1 files changed, 287 insertions, 0 deletions
diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/26 - Skype Example - lang_en_vs5.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/26 - Skype Example - lang_en_vs5.srt
new file mode 100644
index 0000000..2118c73
--- /dev/null
+++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/26 - Skype Example - lang_en_vs5.srt
@@ -0,0 +1,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.