From b2d80610db6beda38573890ed169815e495bc663 Mon Sep 17 00:00:00 2001 From: Nguyễn Gia Phong Date: Sun, 24 May 2020 16:34:31 +0700 Subject: [usth/ICT2.7] Engineer software --- .../26 - Skype Example - lang_en_vs5.srt | 287 +++++++++++++++++++++ 1 file changed, 287 insertions(+) create mode 100644 usth/ICT2.7/P3L1 Software Architecture Subtitles/26 - Skype Example - lang_en_vs5.srt (limited to 'usth/ICT2.7/P3L1 Software Architecture Subtitles/26 - Skype Example - lang_en_vs5.srt') 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. -- cgit 1.4.1