1 files changed, 231 insertions, 0 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
new file mode 100644
index 0000000..d3ab75b
--- /dev/null
+++ b/usth/ICT2.7/P3L1 Software Architecture Subtitles/25 - Napster Example - lang_en_vs4.srt
@@ -0,0 +1,231 @@
+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.