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.