diff options
Diffstat (limited to 'usth/ICT2.7/P3L1 Software Architecture Subtitles/26 - Skype Example - lang_en_vs5.srt')
| -rw-r--r-- | usth/ICT2.7/P3L1 Software Architecture Subtitles/26 - Skype Example - lang_en_vs5.srt | 287 |
1 files changed, 0 insertions, 287 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 deleted file mode 100644 index 2118c73..0000000 --- a/usth/ICT2.7/P3L1 Software Architecture Subtitles/26 - Skype Example - lang_en_vs5.srt +++ /dev/null @@ -1,287 +0,0 @@ -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. |