1 files changed, 0 insertions, 231 deletions
diff --git a/usth/ICT2.7/P3L1 Software Architecture Subtitles/25 - Napster Example - lang_en_vs4.srt b/usth/ICT2.7/P3L1 Software Architecture Subtitles/25 - Napster Example - lang_en_vs4.srt
deleted file mode 100644
index d3ab75b..0000000
--- a/usth/ICT2.7/P3L1 Software Architecture Subtitles/25 - Napster Example - lang_en_vs4.srt
+++ /dev/null
@@ -1,231 +0,0 @@
-1
-00:00:00,160 --> 00:00:03,160
-So let's start by considering Napster. In it's first
-
-2
-00:00:03,160 --> 00:00:07,210
-incarnation, Napster was a peer-to-peer file sharing system. And
-
-3
-00:00:07,210 --> 00:00:10,200
-it was mostly used, actually, to illegally share mp3s.
-
-4
-00:00:10,200 --> 00:00:12,630
-Which is also why it got sued and later
-
-5
-00:00:12,630 --> 00:00:16,129
-on, it basically ceased operations. But nevertheless, I think
-
-6
-00:00:16,129 --> 00:00:19,710
-Napster is an interesting example of mixed architecture. And
-
-7
-00:00:19,710 --> 00:00:22,020
-I'm going to illustrate the way Napster works by showing
-
-8
-00:00:22,020 --> 00:00:25,820
-you, here, the basic configuration of Napster and the interactions
-
-9
-00:00:25,820 --> 00:00:28,950
-between its elements. So let's look at how such interaction
-
-10
-00:00:28,950 --> 00:00:32,250
-can take place for the three peers shown here. And
-
-11
-00:00:32,250 --> 00:00:34,430
-in this case Peer A and B are the only
-
-12
-00:00:34,430 --> 00:00:37,290
-ones really involved in the action. So let's look at
-
-13
-00:00:37,290 --> 00:00:40,700
-a typical sequence of events for the Napster system. We
-
-14
-00:00:40,700 --> 00:00:44,340
-have Peer A that will start by registering, here, with
-
-15
-00:00:44,340 --> 00:00:47,530
-the content directory. Peer B will also register with the
-
-16
-00:00:47,530 --> 00:00:50,970
-content directory. And when these two peers register, the content directory
-
-17
-00:00:50,970 --> 00:00:54,370
-will know what kind of content they can provide. Later on,
-
-18
-00:00:54,370 --> 00:00:57,660
-Peer A will request a song. And one first observation that
-
-19
-00:00:57,660 --> 00:01:00,550
-we can make, based on this interaction, is the fact that,
-
-20
-00:01:00,550 --> 00:01:03,900
-up to now, this is a purely client-server system. This is
-
-21
-00:01:03,900 --> 00:01:06,530
-the client. This is the client. And this is the server.
-
-22
-00:01:06,530 --> 00:01:10,320
-And the interaction is a typical client-server interaction. But now we're
-
-23
-00:01:10,320 --> 00:01:12,410
-at the point in which things start to change a little
-
-24
-00:01:12,410 --> 00:01:16,008
-bit. At this point, after Peer A has requested the song,
-
-25
-00:01:16,008 --> 00:01:18,820
-the peer and content directory will look up its
-
-26
-00:01:18,820 --> 00:01:22,730
-gigantic index and will see that Peer B actually has
-
-27
-00:01:22,730 --> 00:01:24,850
-the song that Peer A requested. So it will
-
-28
-00:01:24,850 --> 00:01:27,690
-send to Peer A a handle that Peer A can
-
-29
-00:01:27,690 --> 00:01:31,052
-use to connect directly to Peer B. So this
-
-30
-00:01:31,052 --> 00:01:34,540
-is where the system is no longer a client-server system.
-
-31
-00:01:34,540 --> 00:01:37,890
-Because at this point, the two peers are connected directly.
-
-32
-00:01:37,890 --> 00:01:41,000
-So at this point, we have a peer-to-peer interaction. And,
-
-33
-00:01:41,000 --> 00:01:43,770
-after getting the request from Peer A, then Peer B
-
-34
-00:01:43,770 --> 00:01:47,170
-will start sending the content to Peer A. And I said
-
-35
-00:01:47,170 --> 00:01:50,660
-earlier that one of the useful things about representing an
-
-36
-00:01:50,660 --> 00:01:52,440
-architecture and interaction within an
-
-37
-00:01:52,440 --> 00:01:54,580
-architecture graphically, is the fact that
-
-38
-00:01:54,580 --> 00:01:57,550
-it allows you to spot possible problems. And in this
-
-39
-00:01:57,550 --> 00:02:00,666
-case, by representing the Napster architecture in this way, and by
-
-40
-00:02:00,666 --> 00:02:03,300
-studying how things work, we can see that there's an
-
-41
-00:02:03,300 --> 00:02:06,010
-issue with the architecture of Napster that will not make this
-
-42
-00:02:06,010 --> 00:02:10,020
-architecture scale. As some of you might have already noticed, this peer
-
-43
-00:02:10,020 --> 00:02:13,720
-and content directory is a single point of failure, and is very
-
-44
-00:02:13,720 --> 00:02:17,230
-likely to cause problems when the number of peers grows too large.
-
-45
-00:02:17,230 --> 00:02:19,890
-Because at that point, there are going to be too many requests to
-
-46
-00:02:19,890 --> 00:02:22,840
-the peer and content directory, and the peer and content directory is
-
-47
-00:02:22,840 --> 00:02:25,460
-unlikely to be able to keep up with all the requests. So
-
-48
-00:02:25,460 --> 00:02:27,840
-some changes in the architecture will have to be made. In the
-
-49
-00:02:27,840 --> 00:02:31,310
-case of Napster, we didn't see this problem occurring because, as I said
-
-50
-00:02:31,310 --> 00:02:34,420
-earlier, Napster got sued and ceased operation before the problem
-
-51
-00:02:34,420 --> 00:02:37,650
-actually manifested. Now looking at the system for an architecture-style
-
-52
-00:02:37,650 --> 00:02:40,560
-perspective, we can see that Napster was a hybrid architecture
-
-53
-00:02:40,560 --> 00:02:43,920
-with both client-server and peer-to-peer elements. And something I would
-
-54
-00:02:43,920 --> 00:02:45,870
-like to stress here, is that this is not at
-
-55
-00:02:45,870 --> 00:02:49,400
-all uncommon. So in real world nontrivial architectures, it is
-
-56
-00:02:49,400 --> 00:02:52,470
-very common to see multiple styles used in the same
-
-57
-00:02:52,470 --> 00:02:56,209
-system. The next system that we will consider, Skype, is instead,
-
-58
-00:02:56,209 --> 00:02:59,885
-an example of a well-designed, almost purely peer-to-peer system.