So let's start by considering Napster. In it's first
incarnation, Napster was a peer-to-peer file sharing system. And
it was mostly used, actually, to illegally share mp3s.
Which is also why it got sued and later
on, it basically ceased operations. But nevertheless, I think
Napster is an interesting example of mixed architecture. And
I'm going to illustrate the way Napster works by showing
you, here, the basic configuration of Napster and the interactions
between its elements. So let's look at how such interaction
can take place for the three peers shown here. And
in this case Peer A and B are the only
ones really involved in the action. So let's look at
a typical sequence of events for the Napster system. We
have Peer A that will start by registering, here, with
the content directory. Peer B will also register with the
content directory. And when these two peers register, the content directory
will know what kind of content they can provide. Later on,
Peer A will request a song. And one first observation that
we can make, based on this interaction, is the fact that,
up to now, this is a purely client-server system. This is
the client. This is the client. And this is the server.
And the interaction is a typical client-server interaction. But now we're
at the point in which things start to change a little
bit. At this point, after Peer A has requested the song,
the peer and content directory will look up its
gigantic index and will see that Peer B actually has
the song that Peer A requested. So it will
send to Peer A a handle that Peer A can
use to connect directly to Peer B. So this
is where the system is no longer a client-server system.
Because at this point, the two peers are connected directly.
So at this point, we have a peer-to-peer interaction. And,
after getting the request from Peer A, then Peer B
will start sending the content to Peer A. And I said
earlier that one of the useful things about representing an
architecture and interaction within an
architecture graphically, is the fact that
it allows you to spot possible problems. And in this
case, by representing the Napster architecture in this way, and by
studying how things work, we can see that there's an
issue with the architecture of Napster that will not make this
architecture scale. As some of you might have already noticed, this peer
and content directory is a single point of failure, and is very
likely to cause problems when the number of peers grows too large.
Because at that point, there are going to be too many requests to
the peer and content directory, and the peer and content directory is
unlikely to be able to keep up with all the requests. So
some changes in the architecture will have to be made. In the
case of Napster, we didn't see this problem occurring because, as I said
earlier, Napster got sued and ceased operation before the problem
actually manifested. Now looking at the system for an architecture-style
perspective, we can see that Napster was a hybrid architecture
with both client-server and peer-to-peer elements. And something I would
like to stress here, is that this is not at
all uncommon. So in real world nontrivial architectures, it is
very common to see multiple styles used in the same
system. The next system that we will consider, Skype, is instead,
an example of a well-designed, almost purely peer-to-peer system.