1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
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.
|
