Seminar P2P im Wintersemester 2010

Transcription

Seminar P2P im Wintersemester 2010
Teilnehmer des Seminar P2P im Wintersemester 2010
26. Juni 2011
Veranstalter:
Fachgebiet Peer-to-Peer Netzwerke und Fachgebiet Telekooperation
Fachbereich Informatik
TU Darmstadt
Inhaltsverzeichnis
1
2
3
4
Exploiting Anonymity in P2P-based Systems von Hristo Chonov
3
Replikationsstrategien in Content-Distributionssystemen von Julian Dean
11
P2P Service Description Language von Dimitar Goshev
20
Cheating Detection in P2P-based Massive Multiplayer Online Games von Georgi
Hadshiyski
26
5 P2P-Based Video-on-Demand-Streaming von Pablo Hoch
32
6 Skype - Ein Überblick über die Protokolle, das Overlay-Netzwerk und die Sicherheitsmaÿnahmen von Marius Hornung
40
7 Übersicht über datenorientierte Netzwerklösungen von Bastian Laur
47
8 Trac Analysis of p2p Applications von The An Binh Nguyen
54
9 Peer-to-Peer-basierte Live-Streaming-Systeme von Thomas Schlosser
61
10 Harvesting Sensor Networks von Andreas Straninger
70
11 Load Balancing in Peer-to-Peer Netzwerken Survey von Johannes Thomas
75
12 Diaspora und Safebook: Der Stand von Decentralized Online Social Networks
von Samuel Vogel
80
13 P2P-based VoIP von Zoran Zaric
85
2
~
1
EXPLOITING ANONYMITY IN P2P-BASED SYSTEMS
Exploiting Anonymity in P2P-based Systems
Hristo Chonov
who are taking part in the anonymous message transfer. On the
other side Low-Latency systems like Tor attempts to reduce the
delivery delay to provide normal speeds for internet browsing
and file sharing.
In the current open peer-to-peer overlay networks every
client can participate without the need to prove that it is
trust-able. Thus a small fraction of malicious nodes can easily
be built, what can lead to incorrect message delivery. That’s
why closed peer-to-peer overlay networks where the clients
connect to the nodes they trust have evolved. In some cases to
participate the network a client needs an invitation. The closed
peer-to-peer networks are usually very small and increasing
the size of the network makes it more insecure. I’ll mainly
concentrate on open peer-to-peer systems.
The main objective of an adversary in an anonymous
communication system is to link the initiators of connections
with their respective communication partners and vice versa.
Outline
The rest of the paper is organized as follow: In Section
II I give a short background information and in Section III
I briefly describe well known look up mechanisms and their
weaknesses. Sections IV to XI present different systems for
anonymous communication and how the anonymity in those
systems can be exploited. At the end I make a conclusion
about the most uncovered weak points which could be used
to exploit the anonymity in the respective systems.
Abstract—After David Chaum, considered the father of anonymous communications, proposed a system for anonymous email
in 1981 many new systems has been implemented on the scene
aiming to offer better protection than their predecessors. But
trying to cover some security holes in the anonymity new
protocols can cause other security issues.
In this paper I describe some of the peer-to-peer network
protocols that employ anonymization techniques and some of
the known approaches that can be used to exploit anonymity in
overlay networks built on top of those protocols. At the end, I
make a conclusion based on a table showing the most widely
uncovered and effective types of attacks.
I. I NTRODUCTION
Anonymous overlay networks allow Internet hosts to communicate with each other, while preventing linkability between
sender and receiver from the rest of the overlay. This means
they conceal who is interacting with whom. Those networks
have a very important usage like for online privacy, resisting censorship, evasioning surveillance. At some places in
the world there is no freedom of speech and censorship is
imposed. There expressioning online could be considered as a
crime and thus the authors need to protect their real identities.
This kind of networks could also be used to resist blocking
circumvention censorship.
Of course they could be used for illegal file sharing, what
someones are doing, by running BitTorrent on the top of Tor
for exchanging illegal content. But actually this is not what
these systems are built for, it’s just an exploitation of them.
Some of the schemes use global list to choose relays from
it. An alternative is to organize the nodes of a network
overlay in a distributed hash table (DHT), which can form
a decentralized and distributed system that maps identifiers to
nodes and has a mechanism to determine the responsible nodeID for a given identifier. The problem however with DHTs
is that they are proven to have very weak points and thus
be very insecure – queries in DHTs are easy to observe and
manipulate. That’s why redundancy mechanisms for securing
DHTs are developed and will continue to be developed in the
future.
In this paper I review both mechanisms for finding relays
i.e. overlays based on a global list and overlays based on a
DHT.
In the most cases the anonymity has a price and that
is the speed. The anonymous peer-to-peer network overlays
are structured in two areas: The first one is Low-Latency
anonymity systems and the second one is High-Latency
anonymity systems.
The time of message delivery in High-Latency systems
like Mixmaster and Mixminion is around 4 hours. This two
networks are assuming that the attacker can see the whole
network traffic and also can manipulate some of the nodes,
II. BACKGROUND
David Chaum, considered the father of anonymous communications, proposed a system for anonymous email in 1981
which is count as the the first one of its kind. He introduced
the term MIX that is a server between sender and receiver
performing cryptographic transformations on the messages and
forwarding them to the next destination in such a way that the
input address could not be linked with the output address.
Most of the existing anonymous routing layers utilize ChaumMIXes for anonymity. Figure 1. illustrates a path in a MIX
system.
Other technique built on the idea of Chaum-MIXes is
Onion-routing, where the messages are encrypted in layers
and sent through several network nodes (onion routers), which
remove the upper encryption layer to uncover routing instructions.
Fig. 1.
3
Example Path in a MIX system
2~
In the following sections I review Tor and Torsk, which
are Onion-routing schemes and Tarzan, Cashmere, Salsa and
MorphMix, which are Chaum-MIXes based systems. Torsk,
Cashmere and Salsa also are based on DHTs for finding relays.
They all represent open peer-to-peer networks.
controlled from an attacker. If an attacker succeeds in finding
a way to control the distribution of the node-IDs she can use
a lot of mechanisms to violate the network overlay.
• An attacker needs to control small fraction of nodes.
When, in Chord, the attacker chooses appropriate nodeIDs she can accomplish that all the entries in a victim’s
finger table point to enemy nodes.
• The access to a target object can also be controlled by
choosing node-IDs close to the target key and so the
attacker can gain full control over the target object by
owning all the replicas. So the attacker can delete, modify,
corrupt, or deny access to the object.
Using both techniques an adversary is able to reveal identities.
III. S TRUCTURED PEER - TO - PEER OVERLAY NETWORKS
A. Overview
In structured P2P networks, peers employ a globally consistent protocol. Thus the nodes in the overlay can route and
search for other peers. The most such networks are using
distributed hash table – DHT.
These following are look up mechanisms, which doesn’t
built a whole system and actually does not employ any
anonymization techniques, but they can be used as a base for
building a peer-to-peer system that provides anonymity.
Some of this look up mechanisms are Pastry, Tapestry,
Chord and CAN. Lets just briefly describe them.
In Pastry the nodes get assigned an unique IDs and maintain
a list of their neighbors called “leaf set”, which is used for
storing replicas. The IDs of the nodes included in the “leaf
set” are numerically close to the current node-ID. From a
message to be send is built a key, which is used for choosing
the node towards which the message will be routed. Beside the
list of neighbors a node maintains also a routing table. Two
options to route a message are available. First, the message is
forwarded to a node-ID from the routing table, which shared
prefix with the key of the message is at least one bit longer
than the shared prefix with the current sender. Otherwise, the
message is forwarded to a node-ID which shares the same
prefix length, but is numerically closer to the key than the
current node. Finally, if no node is found to which the message
should be forwarded the destination is either the current node
or its immediate neighbor.
Tapestry is similar to Pastry, but the nodes don’t keep a
neighbors set. Tapestry also uses a surrogate routing mechanism by trying to forward the message to a node that matches
the key’s n-th digit. If no such node exists in the routing table,
the n-th digit will be incremented till an appropriate node is
found.
Unlike Pastry Chord uses circular ID space and routes the
messages only in clockwise direction. Chord doesn’t have a
routing table but maintains a so called “finger table”, which
contains up to m pointers to online nodes. A node always is
aware of it’s predecessor. The more deeper an entry in the
table is, the more distant node it’ll point to. Chord maintains
the replicas by mapping keys to node-IDs.
CAN is based on d-dimensional Cartesian coordinate space.
A hash function is assigned to each dimension. The entire
space is partitioned amongst the nodes. Each node has a routing table consisting of O(d) entries, which are the neighbors
of the current node.
Sybil attack: If the attacker can gain control over many
legitimate nodes she can accomplish 1. and 2. without the
need of freely choosing node-IDs. This kind of attack is called
Sybil attack.
2) Attacks based on the maintenance of the routing table
[1]:
• The first attack works only against routing algorithms
which are aiming to improve network efficiency by calculating the delays between nodes. If an attacker controls
enough number of nodes she can intercept a delaycalculating request from a correct node to hostile node
and get another faulty node closer to the correct node
answer to the request. This way an attacker can populate
the victim’s routing table with bad entries.
• The second attack is based on the routing updates. It is
hard to check their trust in network overlays like Pastry
and Tapestry. The attacker can just start populating the
overlay with updates pointing to hostile nodes. As result
the correct nodes will announce their bad entries in the
routing updates.
Storage Anonymity means that a request for a particular
data doesn’t reveal the node storing this data. Chord doesn’t
provide such anonymity since the answer of such a request is
the IP address of the node on which the data is stored.
Problem: Pastry and Tapestry employ very weak constraints
which node-IDs should be granted in the routing table. This
gives the opportunity to use the network proximity and thus to
improve routing performance. CAN and Chord on the other
side employ very strong constraints: only the closest nodeIDs should be accepted in the routing tables. This improves
the security, but thus the network proximity can’t be used.
IV. ATTACKS AGAINST G ENERAL C HAUM -MIX ES BASED
AND O NION - ROUTING BASED NETWORK OVERLAYS
A. Timing Attacks in Low-Latency MIX Systems
B. Attacks
A MIX can be defined as a proxy that hides the conversation between its incoming and outgoing connections. Routing
through many MIXes provides strong unlinkablity of senders
and receivers. Among the systems using MIXes for routing are
1) Attacks based on the node-ID assignment [1]: The
security of structured peer-to-peer overlay networks depends
on the assumption that the assignment of node-IDs can’t be
4
~
3
Onion-routing, Freedom and Tarzan. Using a timing attack an
adversary tries to identify, if two malicious MIXes Mf irst and
Mlast that belongs to him are on the same path. To reveal the
Identity of the sender and the receiver one of the MIXes should
be the first and and the other one the last in the chain and they
must be aware of their position. This way an adversary is able
to find a correlation in the timings of both malicious nodes
and thus link the initiator with the receiver.
The first method to exploit the attack is to compute the
difference between the arrival time of packet xn and its
successor packet xn+1 at Mf irst and Mlast . The adversary
can compare both differences and for example, if the delay at
Mf irst was large and both nodes lie on the same path the delay
at Mlast is more likely to be larger than average. This method
is sensitive to dropped packets and some otherwise perfect
correlations could be identified as a mismatch. More powerful
approach [8] is to use a nonoverlapping and adjacent windows
of time. During this periods both malicious nodes will count
the packets on every path they are belonging to. Finally the
collected counts need to be compared. To make this attack
even more powerful Mf irst could drop intentionally packets
to enhance the correlation.
Onion-routing and the second version fo Freedom do not
offer any special mechanisms to prevent timing attacks if an
adversary happens to own the first and the last node of a chain.
Tarzan and the original version of Freedom employ constantrate cover traffic between pairs of mixes and send traffic
between covered links. Freedom however is still vulnerable to
timing attacks, because the traffic between the initiator and first
node and between the last node and the receiver is not covered.
In Tarzan and in Freedom the mixes are able to distinguish
between real and covered traffic and the malicious nodes can
consider only the first for the timing attack.
circuit. The first encryption is done with the key known to the
last node called exit node and the last encryption is done with
the key known to the first node in the circuit. This represents
the so called onion routing and every node in a circuit knows
only its predecessor and successor.
Multiple TCP streams from one source are put together in
one circuit to improve efficiency instead of building many
circuits from a single node. This improves the anonymity and
it is restricted to put new streams in circuits containing streams
older than 10 minutes.
Tor protects against non-global adversary that only control
fraction of the nodes. Tor doesn’t protect against attacks
trying to find out, if two parties are communicating with each
other by observing them – this kind of attack is the already
mentioned traffic confirmation attack. Tor only makes it
difficult for an adversary with weak suspicions to collect more
information.
B. Attacks
1) Traditional traffic analysis – global passive adversary:
•
•
B. Intersection Attacks in Onion-routing Systems
The Onion-routing project has drawn the attention to such
kind of attacks and also named them Traffic Confirmation
Attacks.
This kind of attacks is based on the fact that not all the
nodes are active at the same time and that users typically
communicate with a small number of parties – for example a
user queries the same web sites in different sessions. To reveal
the identities of the nodes the observer records the active users
and intersects the sets. This is possible only if the observer
knows all the nodes in the system. When the attacker has
reduced the possible set of initiators she can switch to another
tactic e.g. Packet Timing to reveal the original initiator.
One kind of attack is to consider the time of connection initiations. Statistical variant of this attack is also
developed. Both attacks could be used to determine if a
specific node establishes connections to a set of web sites
regularly.
Low cost traffic analysis - One corrupt node in the Tor
overlay network is required to accomplish this attack. The
corrupt node first must establish connections to the nodes
in the network to measure and monitor the latencies of
those connections for some period of time. The aim of
this is to determine the traffic loads of the nodes the
attacker has made connection with. Then from this traffic
patterns are derived. They can be used to be built a
template indicating how a stream based on the reply of a
server outside the overlay network will look like inside of
it. A comparison of all links is needed to find similarity
with the model built from the template and so even the
position of a node in the circuit can be found. [6]
2) Traffic analysis – non-global passive adversary:
Packet Counting – Lone Connection Tracking [7]: This
attack is applicable on the 2nd generation onion routing,
Tarzan and MorphMix.
The attacker only needs to observe all the links used by
a connection. By counting the packets on lone connections
the anonymised streams can be followed. The term lone
connection means that only this connection is traveling toward
a particular link. If the packets number on D->X and X->T is
very similar, it can be assumed that X is communicating with
T, as it can be observed on Figure 2.
There are some restrictions about the measure interval to
implement the attack: First, it must be larger than the mix
delay. Otherwise the incoming and outgoing packet counts will
be made dissimilar. Second, it must be shorter than the mean
time new connections are built between the pair of links.
A simulation [7] in a network with 100 nodes showed that
92 Figure 3. shows a graph of the number of nodes against
V. T OR – S ECOND GENERATION ONION - ROUTING
A. Overview
Tor is a Low-Latency circuit-based anonymous network
overlay, thus it’s main aim is to hide the identities of the
clients. When a client wants to establish a connection to a
server, it first obtains a list of Tor nodes from a directory
server and then picks up n nodes from the Tor network and
afterward builds a circuit. The messages are encrypted n times
with encryption keys negotiated separately with the hops in the
5
4~
Fig. 2.
Packet Counting Example
Fig. 4.
Attack Model Against Tor
TCP port the client is listening on, 3. peer ID of the client
and 4. optionally the IP address of the Alice’s NIC device.
In return the tracker sends a sub list of peers already joined
the torrent. Finally, the client sends a handshake to the peers
to establish a connection with them. BitTorrent can also use
DHT over UDP to search for a tracker controlling the desirable
torrent. BitTorrent can run over Tor network as over proxy. So
it is possible to use the Tor network for communication with
the tracker and the peers. The client can decide to use Tor for
only one of them or both.
Fig. 3.
B. De-anonymizing IPs in BitTorrent on top of Tor
Lone Connections Simulation
In a study [2] 6 Tor exit nodes have been mounted all over
the world for 23 days.
1) Inspection of BitTorrent control messages: The tracker
announces can contain the IP address of a client and according
to the study 3968 unique public IP addresses were captured ,
which represents 58
Clients supporting the Extension Protocol may also send
additionally their IP addresses. As result 1131 unique public
IP addresses were collected – 33
2) Hijacking Trackers’ Responses: The following is typical
man-in-the-middle attack and works, if the client is using Tor
only for communication with the tracker. The attacker Bob
can hijack the tracker’s response to an announce message from
Alice. Then Bob can just send an altered sub list with peers
where the first one is Bob himself. This way Alice will try
to establish a direct connection with Bob and thus revealing
her public IP address. Comparing this IP address with the
public addresses of the Tor’s exit nodes can show, if it belongs
to Alice or to the exit nodes. Finally, 2240 unique public IP
addresses were collected - 73
3) Exploitation of the DHT: As Tor doesn’t support UDP
the client will connect to the DHT without Tor and Alice will
publish it’s public IP address in the DHT and despite of the
connection to the peers over Tor the IP address of Alice can
still be looked up in the DHT. This is possible only when Bob
is controlling Alice’s exit node and so knowing her BitTorrent
port number. Later Bob can search in the peer list for this
torrent in the DHT and compare the port numbers. After
finding a match it is possible that the published IP address
belongs to Alice. This tactic resulted in 6151 unique public
IP addresses.
the lone connections when there are 60 connections all running
through 2 links.
Traffic-analysis of Tor - Tor employs round-robin sending
of packets. If a stream has no more cells to be forwarded,
it is skipped and the node proceeds with the next waiting
connection. Thus the load on a Tor node affects the latency
of the connections running through it. This can be used by an
attacker.
• An adversary can route a connection through a Tor node
and with another corrupt node measure the latency to
learn the traffic load of that node by connecting with
it and sending probe traffic. If traffic pattern is already
extracted the traffic load can be compared with it and
thus an attacker is able to detect the nodes it is relayed
through.
• The following attack is just a more powerful version of
the previous one and is based on the assumption that
a victim node is trying to access a corrupt server which
sends the data in specific traffic pattern. Using this pattern
a template can be derived and it can be checked which
nodes correspond to it. One such traffic pattern could
represent sequences of short bursts of data. Figure 4.
shows an example model of this attack. [6]
VI. B IT T ORRENT ON TOP OF T OR
A. Overview of BitTorrent
When joining a torrent Alice first sends an announce message to the tracker containing 1. unique torrent identifier, 2.
6
~
5
VII. T ORSK
A. Overview
Torsk improves the scalability of Tor and retains the benefits
of the client-server architecture claiming it doesn’t introduce
new attacks. Torsk distributes most of the Tor directory service
over a DHT and propose usage of secret buddy nodes and
certificates to keep the look up initiator anonymous. The look
up mechanism is based on Kademlia DHT and Myrmic.
Torsk look-up: Every node maintains a finger table and
when it wants to look up data x, it first selects t (usually 3)
pointers close to x. Then the querier starts independent look
ups at the t pointers and builds a list with the closest nodes
from every look up he has learned. Next the node selects again
from every list t pointers and start the same way independent
look ups. This iterative process terminates when at the end of
an iteration the lists with the closest nodes to x stay unchanged.
Every node has a certificate from a trusted central authority,
that contains all fingers of the node. Finally, the querier can
check if the node he has found is responsible for x by verifying
it’s certificate.
During the iterative process every node included in the
search learns x and if a hostile node is looked up it can
associate the found node with the query initiator.
Secret buddy: To remain anonymous the nodes select
random buddies in the network and when a node searches for
some data it gets the query executed from one of its buddies.
The selection of buddies is realized with random walks before
starting the look up, what prevents Timing Analysis Attacks.
The buddies should be used only one time and not repeatedly.
Fig. 5.
Example Binary Tree In Salsa
B1 ...Br . Then connections are built from each A1 ...Ar node
to each B1 ...Br node. The initiator then asks the B nodes
to search for a final node. Next the querier selects a circuit
randomly and connects the final node to it. The nodes get
mapped trough a hash function of their IP addresses into points
in the ID space. This is done for bound checking and so the
closest node to a target is selected. If a path exceeds a threshold
length, it is discarded. The ID space is partitioned in groups
as each node knows all of the participants in its group and
also knows some nodes in the other groups to route look up
requests in the system. The groups are organized in the form
of a binary tree. A node has a global contact for each level
in the tree, which is selected at random from the child subtree where the node is not belonging to. A global contact is
chosen by hashing the concatenation of the selecting node’s
IP address and the level height. This is done to ensure that a
node cannot select arbitrary global contacts. Figure 5. shows
an example for a binary tree in Salsa.
B. Attacks
1) Inherited attacks: As Torsk is just a implementation of
Tor that aims to make the overlay network achieve scalability
it inherits the weaknesses of the previous system. Thus all
the attacks mentioned in the Tor section are applicable also
against the Torsk overlay network.
2) Buddy Exhaustion Attack: Since the buddies should
be used only one time on the end node of a built circuit,
Buddy Exhaustion Attack can be used and thus the attacker
can succeed placing malicious entry and exit nodes in many
circuits. Then the attacker can apply DoS attack or use timing
analysis attack. The attack consists in flooding the node that is
looked up with the aim to extend the circuit. Since the random
walk for selecting new buddies is restarted every time when
an invalid certificate is found, the attacker can just let the
malicious nodes expose invalid certificates and with enough
large fraction of hostile nodes it is most likely a malicious
node to be included in a random walk. Thus the victim node
can’t recover from the exhaustion attack. The performed study
[3] shows that with this attack over 80
B. Attacks
1) Intersection Attack: To accomplish this attack in Salsa
an attacker only needs to have at least one node in each group.
When 4096 groups exits, an attacker needs 68100 hostile
nodes to ensure success with probability 0,9998. [4] The other
mechanism of gaining overview of the network is by using the
look up process. This is a long procedure and new nodes are
joining over and over again.
2) Active path compromise attacks: If an attacker gets
all the nodes in a particular stage compromised, she can
get all the IDs/public keys of the next set of nodes, being
looked up, modified. Since a node can not determine the
validity of a public key the bound checking algorithm is
defeated. The remaining stages of the path building can now
be emulated. If the attacker gets the first and the last node in
a circuit compromised she can use end-to-end timing analysis
to compromise the path.
3) Conventional Continuous Stage Attack: Another way of
compromising path is to have at least one malicious node at
every stage of the path. Lets take the three attacks nodes A1 ,
VIII. S ALSA
A. Overview
Salsa is a DHT-based layered circuit anonymity scheme.
Look up mechanism: The querier selects r random nodes
A1 ...Ar and gets them separately look up for another r nodes
7
6~
A2 , A3 , where 1, 2 and 3 stay for the different stages. A1
looks up A2 , which on his turn looks up A3 .
the last node in the tunnel and last with the key of the first
node. Before forwarding the packet each node first removes
the outer encryption layer and then tags the packet with the
flow identifier of the next node in the tunnel. The last hop
removes the last layer and sends the original IP packet. The
response from the server then gets encrypted l times in the
tunnel and Alice needs to perform l decryptions.
IX. C ASHMERE
A. Overview
Cashmere is a recursive DHT based network overlay on
top of Pastry DHT. A node has k-bit signed node-ID. The
nodes are divided in groups with m-bit IDs, where k is equal
or greater than m. The group-ID serves as a prefix of the
nodes. A node participates in a group if the ID of the group
is a prefix of its ID. Every group has assigned public/private
keys and the group members receive them. The nodes obtain
also the public keys from the other groups. Messages in the
overlay are routed using group-IDs. The first found node, that
has this group-ID as a prefix is responsible for forwarding the
message to all other members in this group. The forwarding
of messages is done through n groups. The sender encrypts
separately the path and the message in layers using the public
keys of the groups. Thus the same path can be used multiple
times. A group in the path decrypts the path message with it’s
private key and finds out the next group in the path and the
symmetric key to decrypt the outer layer of the message.
B. Attacks
1) Low Cost Attack: The term low cost attack means that
the attacker requires only a partial view of the network.
Like the low cost attack against Tor a corrupt node must
find the other nodes and establish connections with them to
monitor their latencies. When the adversary is ready with the
monitoring she can use the latencies information to obtain the
traffic load of the nodes, she has built connections with. If
the nodes were on a path to a corrupt server there will be
similarity between their traffic load and the traffic load of that
server. Checking all the nodes can lead to learning the whole
path.
For this attack to be applicable, the traffic loads of the nodes
must be extracted from the latencies, as the described above
Tor attack. Second, the corrupt node must be able to discover
all nodes. Third, an establishment of direct connections to all
of them should be possible.
In the testbed of Tarzan during the study [5] a mimic
part wasn’t available and it wasn’t possible to conduct an
experiment to obtain, if the mimic mechanism is able to
destroy the timing characteristics. So the problem if it is
possible to extract the real traffic loads was left open. Tarzan
offers the ability to discover all other nodes in the network
overlay through a goosip-protocol based mechanism. The last
condition is also met. Through the mimics is not possible
to be established a direct connections to all nodes, unless
the desired nodes are mimics of the corrupt node. But the
NAT-Server node can be freely chosen and thus it is possible
to be established a one-hop connection to the desired nodes
if they are treated as the NAT-Server of that connection.
As conclusion the applicability of the attack against Tarzan
depends only on the open question if the mimic traffic can
destroy the timing characteristics.
2) Intersection Attacks: Since as already mentioned a node
is capable of discovering all nodes in the network an Intersection attack is thus applicable here.
3) Packet Counting – Lone Connection Tracking [7]: As I
already said in the Tor Section that this attack is applicable
also against Tarzan.
B. Resending captured messages Attack [4]
If a observer catches a message m1 delivered to group G1
and m2 to G2 , the attacker can try to send m1 over a new
path, including both groups and built by the attacker. Then
depending on that if m2 is seen on the same place, where the
first m2 was caught it is sure whether G1 and G2 were/are
neighbors on the original path. This attack is possible, because
only public-private key structure is used for encryption. It is
not applicable in overlays where only session keys are used
for encryption.
X. TARZAN
A. Overview
Tarzan is the first anonymizing communication system that
is both self-organizing and fully-decentralized. Every node in
the network is a client and a relay. Not both ends of a tunnel
need to be in Tarzan for the communication. If a client wants
to connect to a server not in Tarzan, the last node in the
circuit (the exit node) acts as a NAT-Server. Tarzan is based
on the Chaum-MIXes idea and every node in the tunnel adds
or removes encryption layer depending on the direction. When
joining Tarzan, a node ask k nodes already in the network to
share with it mimic traffic. This means they must send him
their mimics. The mimics are normal nodes in the network and
the joining node builds a bidirectional connections with them.
When Alice wants to establish a connection with a server, she
picks up the first node n1 of her mimic list. Then she asks n1
for its mimic list and picks up the second node from it. This
process is repeated until the path reaches length of l hops. The
l + 1 node in the path is the NAT-Server and Alice picks up it
randomly from her peer database. The initiator first negotiates
symmetric session keys with the hops in the circuit. The IP
packet that has to be send is first encrypted with the key of
XI. M ORPH MIX
A. Overview
MorphMix is a peer-to-peer anonymous network based on
MIXes. Each node is a client that generates anonymous traffic
and at the same time is a mix server that forwards anonymous
traffic for other nodes. A node finds other nodes in the system
through its neighbors. To defend against attacks based on
colluding nodes that redirect to a set of other colluding nodes
when a tunnel is built up, MorphMix introduces new collusion
8
~
7
detection mechanism (CDM). Each node has virtual links via
TCP to its neighbors. MorphMix uses fixed size messages and
layered encryption to defends against traffic analysis and also
protect the message content. To build a anonymous tunnel the
initiator D firsts select node A from its neighbors and establish
a symmetric key with it. If the initiator wants to extend the
tunnel he asks A to recommend nodes. Then D selects one of
the recommended nodes, B, and gets a witness node C from
the already known nodes to establish a symmetric key between
D and B. This continues until D stops appending nodes to the
tunnel. The witness mechanism is also used for the selection
of the first node, thus a node is not aware of its position in
the tunnel.
CDM – To improve security each node maintains a fixed
size extended selection list LES which consists of the suggested selections and the 16-bit IP prefix of the node that recommended them. To detect that a malicious node recommends
another malicious nodes MorphMix distinguishes the nodes
from each other by their 16-bit IP address prefix, because it
is very costly for an attacker to own nodes in many unique
/16 subnets. For every recommended selection a comparison
in the extended selection list is made.
Low cost traffic analysis and Packet counting are also very
powerful threats that can be used against plenty of the existing
anonymous communication systems.
I hope this review of the attacks will motivate the development of a communication system that implements anonymization techniques and doesn’t expose weaknesses which can be
used to employ the attacks described in this paper and also
others not reviewed here.
Personally I think that the development of a new system
should not follow the approaches of the existing ones and
needs to take a whole new way, because analysis of the old
schemes has proven that those systems could not be made
resistant against all the attacks.
The focus of my paper were Low-Latency Open anonymous
peer-to-peer systems and I haven’t reviewed any closed ones
a.k.a. Darknets like Nulsoft’s WASTE and Freenet. However
I suggest extensions of this paper that include those systems
and even more of their kind.
R EFERENCES
[1] Miguel Castro and Peter Druschel and Ayalvadi Ganesh and Antony
Rowstron and Dan S. Wallach Secure routing for structured peer-topeer overlay networks. Proceedings of the 5th symposium on Operating
systems design and implementation - OSDI ’02, 2002. III-B1, III-B2
[2] Pere Manils and Abdelberi Chaabane and Stevens Le Blond and Mohamed Ali Kaafar and Claude Castelluccia and Arnaud Legout and Walid
Dabbous Compromising Tor Anonymity Exploiting P2P Information
Leakage. VI-B
[3] Qiyan Wang and Nikita Borisov In Search of an Anonymous and Secure
Lookup. ACM CCS, 2010. VII-B2
[4] Andrew Tran and Yongdae Kim Hashing it out in public: common failure
modes of dht-based anonymity schemes. WPES, 2009. VIII-B1, IX-B
[5] Rungrat Wiangsripanawan and Willy Susilo and Rei Safavi-naini Design
principles for low latency anonymous network systems secure against
timing attacks. In Proceedings of the fifth Australian symposium on
ACSW frontiers (ACSW ’07, 2007. X-B1
[6] Steven J. Murdoch and George Danezis Low-Cost Traffic Analysis Of Tor.
In Proceedings of the 2005 IEEE Symposium on Security and Privacy.
IEEE CS, 2005. V-B1, V-B2
[7] Andrei Serjantov and Peter Sewell
Passive Attack Analysis for
Connection-Based Anonymity Systems. In Proceedings of European
Symposium on Research in Computer Security (ESORICS, 2003. V-B2,
V-B2, X-B3, XI-B3
[8] Brian N. Levine and Michael K. Reiter and Chenxi Wang and Matthew
Wright Timing attacks in low-latency mix systems (extended abstract.
Proceedings of the 8th International Financial Cryptography Conference
(FC 2004), Key West, FL, USA, February 2004, volume 3110 of Lecture
Notes in Computer Science, 2004. IV-A
B. Attacks
1) Intelligent Selection Attack if a colluding node knows it
is the first one in the tunnel:
1) For every victim we construct a list of selections S, so
that there is no overlap in the subnets between the nodes
in S.
2) Global pointer pg keeps reference to a node in the list
that is to be offered the next time.
3) Every time the pointer is incremented and when it refers
to the last node in S the pointer is moved to the first node
and the iteration goes so on.
2) Intelligent Selection Attack if a colluding node doesn’t
knows it is the first one in the tunnel:
1) We reply to a v’s request by assigning local pointers pl to
the elements referenced by pg and offer v this selection.
2) For every successive request we increment pl and offer
the selection it points to.
3) After the tunnel is built up we just measure the length of
the tunnel and determine if the initiator was v or some
other node.
4) In the case v was the initiator we set pg to point to the
elements referenced by pl .
The Intelligent Selection Attack is very powerful especially
against new nodes, because their extended selection lists are
empty.
3) Packet Counting – Lone Connection Tracking [7]: As I
already mentioned earlier in the Tor Section that this attack is
applicable also against MorphMix.
XII. C ONCLUSIONS
As we can see based on Table 1. that makes a summary of
the attacks described here the Intersection Attack approach
seems to be serious problem for Onion-routing schemes.
9
8~
TABLE I
C OMPARISION
Attack Protocol
Time of connection initiations
Low Cost traffic analysis
Packet counting
Traffic Analysis - corrupt Node, corrupt Server
Intersection Attack
Active path compromise attacks
Conventional Continuous Stage Attack
Resending catched messages
Intelligent Selection Attack
Timing Attacks
Buddy Exhaustion Attack
Salsa
x
x
x
Cashmere
TOR
x
x
x
x
Torsk
x
x
x
x
x
Tarzan
MorphMIX
Chaum-MIXes systems
x
x
x
x
x
x
x
10
Onion Routing
x
x
x
~
1
REPLIKATIONSSTRATEGIEN IN CONTENT-DISTRIBUTIONSSYSTEMEN
Replikationsstrategien in
Content-Distributionssystemen
Julian Dean
Zusammenfassung—Mittels Replikation können Performanz
und Verfügbarkeit von Content-Distributionssystemen erhöht
werden. Solche Systeme dienen der Verbreitung von Inhalten, etwa Webinhalten oder Streaming-Medien im Internet. Es
existieren verschiedene Strategien für die Platzierung, Aktualisierung und Abfrage der Replikate, welche die Performanz
und Verfügbarkeit maßgeblich beeinflussen. In diesem Paper
wird ein Überblick über existierende Replikationsstrategien in
Content-Distributionssystemen gegeben. Sie unterscheiden sich
vorallem bezüglich Kommunikation (Client-Server vs. Peer-toPeer), Informationsfluss (Push vs. Pull) und Konsistenz (stark
vs. schwach).
chen. Dazu werden zunächst in Kapitel II Faktoren genannt,
anhand derer solche Replikationsstrategien klassifiziert werden
können. Danach werden konkrete Replikationsstrategien für
Verschiedene Architekturen beschrieben: in Kapitel III für
Client-Server-Systeme, in Kapitel IV für unstrukturierte P2PSysteme, in Kapitel V für strukturierte P2P-Systeme und in
Kapitel VI für hybride Systeme. Abschließend wird in Kapitel
VII eine Taxonomie der Systeme gegeben und in Kapitel VIII
ein Fazit und ein Ausblick.
I. E INLEITUNG
Es gibt grundsätzlich zwei verschiedene Arten von Replikation [SKS09]:
• Replikation ganzer Dateien: hierbei werden n Kopien
einer Datei auf verschiedenen Knoten abgelegt. Der
Nachteil ist, dass die Replikation ganzer Dateien relativ
aufwendig ist. Eine Lösung ist die . . .
• Blockweise Replikation: hierbei wird eine Datei in Blöcke zerteilt, die dann auf verschiedenen Knoten abgelegt werden. Der Verlust von Blöcken ist allerdings
problematisch. Eine Lösung ist die Verwendung von
Auslöschungscodes (engl. erasure code), eine Art von
Vorwärtsfehlerkorrektur (engl. forward error correction,
FEC), mit denen verlorene Blöcke wiederhergestellt werden können. Dabei können b originale Blöcke von m
kodierten Blöcken rekonstruiert werden, wobei m nur
wenig größer ist als b.
Bei der Konstruktion von Replikationsstrategien für ein verteiltes System sind diverse Faktoren zu beachten, anhand derer
auch die späteren Algorithmen klassifiziert werden können
[Kla06]:
a) Kommunikation: Grundsätzlich sind zwei Arten von
Kommunikation denkbar:
• Bei Client-Server-Systemen werden Daten auf eine bestimmte Anzahl von Knoten kopiert, beispielsweise bei
Content-Delivery-Networks (CDN). Ein CDN ist ein Netz
von Servern zur Auslieferung von Inhalten.
• Bei Overlay-Netzwerken kann die logische Struktur des
Netzwerks auf der Anwendungsebene genutzt werden,
um Replikate zu platzieren. Es kann aber auch anhand
von Kriterien wie der Beliebtheit von Daten oder der
Verfügbarkeit von Knoten repliziert werden. Zu beachten
ist, dass bei gewöhnlichen P2P-Netzwerken, etwa Tauschbörsen, bereits implizit eine Replikation stattfindet, weil
Benutzer lokale Kopien von Daten erzeugen. Das Ausmaß
der Replikation hängt dort allerdings von der Popularität
der Daten ab und ist daher nicht ausreichend, weil auch
unpopuläre Daten verfügbar sein müssen.
II. G RUNDLAGEN
Content-Distributionssysteme sind im Allgemeinen Systeme, mit denen Inhalte an Verbraucher geliefert werden,
beispielsweise Webinhalte oder Streaming-Medien im Internet. Solche Systeme reichen von Content-Delivery-Systemen
(CDN) bis hin zu Peer-to-Peer-Systemen. Das Ziel des Betreibers ist immer, seine Inhalte möglichst wirtschaftlich einem
großen Publikum bereitzustellen. Er will also – wie immer in
der Wirtschaft – seinen Gewinn maximieren und gleichzeitig
die Kosten minimieren. Dazu müssen die Daten möglichst
nahe an den Verbraucher gebracht werden, damit die Auslieferung nur geringe Kosten verursacht. Dies erreicht der Betreiber
für Inhalte, die nicht in Echtzeit übertragen werden müssen,
durch Replikation.
Das generelle Ziel der Replikation ist es, Performanz und
Verfügbarkeit von verteilten Systemen zu erhöhen, etwa den
erwähnten Content-Distributionssystemen. Daten und Dienste sollen effizient abrufbar und trotz Knotenausfällen oder
Netzwerkpartitionen verfügbar sein. Knotenausfällen kommen
beispielsweise durch Abstürze von Servern zustande. Netzwerkpartitionen treten dann auf, wenn Gruppen von Knoten
durch den Ausfall von Verbindungen voneinander getrennt
werden, jedoch für sich noch funktionsfähig sind. Es wird
mit einem Lehrbuchbeispiel gezeigt, dass durch Replikation
die beiden Ziele erreicht werden können: Bei n replizierenden
Knoten mit unabhängiger Ausfallwahrscheinlichkeit p beträgt
die Verfügbarkeit des Gesamtsystems 1 − pn , sie kann demnach durch Replikation verbessert werden. Allerdings ist in
Folge mehr Fehlertoleranz nötig, etwa muss bei gleichzeitigen
Updates in verschiedenen Netzwerkpartitionen eine Synchronisierung durchgeführt werden, nachdem die Partitionierung
behoben ist. Lese- und Schreibvorgänge müssen auf vielen
Knoten ausgeführt werden. Da all dies aber nicht skaliert,
muss häufig die Konsistenzbedingung abgeschwächt werden
[CDK05], [Kla06].
Die Arbeit gibt einen Überblick über existierende Ansätze,
Replikation in Content-Distributionssystemen zu verwirkli-
11
2~
Da – insbesondere bei Overlay-Netzwerken – eine starke
Fluktuation von Knoten bestehen kann, müssen deren Eigenschaften wie Bandweite, Rechenleistung oder Verweildauer
beachtet werden, wenn sie Replikate speichern sollen.
b) Synchronisierung und resultierende Konsistenz: Bei
der Synchronisierung von Replikaten kann der Informationsfluss zwischen den Knoten grundsätzlich in zwei Richtungen
stattfinden:
• Knoten sind passiv und bekommen ihre Updates zugewiesen (Push). Die Aktualisierung von Replikaten kann
auf zwei Wege geschehen, wobei das benötigte Maß an
Konsistenz ausschlaggebend ist:
– Bei der eifrigen Replication (engl. eager replication)
werden alle Replikate synchron durch eine Transaktion aktualisiert. Sie führt zu starker Konsistenz, ist bei
großen Systemen allerdings ungeeignet, weil Deadlocks auftreten können. Ein Deadlock kann etwa
auftreten, wenn mehrere Transaktionen gleichzeitig
Knoten aktualisieren, jedoch jede Transaktion auf
das Commit einer anderen Transaktion warten muss.
– Bei der trägen Replication (engl. lazy replication)
werden Updates asynchron durch Subtransaktionen
propagiert. Sie führt zu schwacher Konsistenz und
kann nur eingesetzt werden, wenn veraltete Daten
hinnehmbar sind.
• Knoten sind aktiv und erkundigen sich bei anderen Knoten nach Updates (Pull). Die resultierende Konsistenz ist
schwach, da Updates nur allmählich propagiert werden.
c) Schreiben: Bezüglich des Schreibens auf Knoten gibt
es zwei Möglichkeiten:
• Es kann nur auf einen ausgezeichneten Knoten geschrieben werden. Dieser stellt somit einen Single-Point-ofFailure dar. Es wird in der Regel ein pessimistisches
Replikationsprotokoll verwendet, wobei Updatekonflikte
gar nicht erst auftreten dürfen. Es entsteht der Eindruck
einer einzigen Kopie der Daten.
• Es kann auf mehrere oder alle Knoten geschrieben werden. Dabei können Inkonsistenzen auftreten, deren Behandlung zu schlechter Skalierbarkeit führt. Daher wird
in der Regel ein optimistisches Replikationsprotokoll
eingesetzt, wobei Updatekonflikte nur beim Eintreten
behandelt werden.
Problem ist, dass es sich die zentralisierten Nameserver nicht
leisten können, die genauen Standorte der Replikate zu speichern. Die Replikate werden in Rechenzentren gespeichert, um
eine gewisse Verfügbarkeit zu erreichen. Allerdings platziert
das CDN oft mehr Replikate als nötig, was Speicher und
Bandbreite verschwendet [CKK02].
B. Zufällig
Die Idee hinter einem auf Zufall basierenden Ansatz rührt
daher, dass ein randomisierter Algorithmus für gewöhnlich
eine gute durchschnittliche Performanz aufweist. Ein möglicher Algorithmus (Random-Popularity) funktioniert wie folgt:
Jedem Objekt wird eine bestimmte Popularität zugeordnet, die
der Anzahl der Anfragen nach diesem Objekt entspricht. Der
Algorithmus ist iterativ: Die Objekte werden in jeder Iteration
absteigend nach ihrer Popularität geordnet und das populärste
Objekt auf einen zufälligen CDN-Knoten repliziert. Ist das
Replikat in der Nähe des Zugangsnetzes ein oder mehreren
ISPs platziert, so wird die Popularität des entsprechenden
Objekts mit der Anzahl der Anfragen dieser ISPs gesenkt, da
diese Anfragen nun durch das Replikat bedient werden können. Damit auch unpopulärere Objekte verfügbar sind, werden
mindestens k Replikate jedes Objekts erzeugt. Sehr populäre
Objekte dürfen nur mehr als k-mal repliziert werden, wenn
alle anderen Objekte bereits k Replikate besitzen [KMS09].
Blade
Runner
Attack of
the Clones
Replicant
Metropolis
Popularität
Abbildung 1. Bei einer zufälligen Platzierung wird in jedem Schritt das
populärste Objekt repliziert und entsprechend abgestuft.
III. C LIENT-S ERVER -S YSTEME
Bei Client-Server Systemen handelt es sich beispielsweise
um CDNs, welche Inhalte im gesamten Internet ausliefern.
Von besonderer Bedeutung ist es dabei, Inhalte innerhalb der
Domänen der Internetdienstanbieter (engl. Internet Service
Provider, ISP) bereitzustellen, um den Traffic über den Backbone zu minimieren. Die folgenden Ansätze sind möglich,
stellen jedoch keine erschöpfende Aufzählung dar. Es handelt
sich um akademische Ansätze, nicht um industrielle.
C. Baum-basiert
Die Topologie des Internets kann als Baum aufgefasst
werden, mit dem CDN-Knoten, von dem die Inhalte ausgehen,
als Wurzel, und den einzelnen ISPs als Blättern. Nun sollen
mindestens k Replikate jedes Objekts möglichst auf Pfaden
zu Blättern (ISPs) platziert werden, über die viele Zugriffe
stattfinden. Eine Möglichkeit (Tree Based Bottom Up) besteht
darin, eine Breitensuche (Traversierung) von den Blättern
ausgehend zur Wurzel durchzuführen. Dabei werden der Reihe
nach auf jeder Ebene des Baums möglichst viele Objekte auf
jenen Knoten repliziert, bei denen sie am populärsten sind. Da
die Replikate von unten nach oben im Baum platziert werden,
A. Klassisch
Die meisten gängigen CDNs verwenden eine DNS-basierte
Weiterleitung von Anfragen an Replikate (Lastverteilung). Das
12
~
3
handelt es sich um das Bottom-Up-Prinzip. Die Popularität
der Objekte entspricht wieder am Anfang der Anzahl entsprechender Anfragen und wird für jedes Replikat entsprechend
der nun bedienbaren Anfragen gesenkt. Allerdings werden
nicht mehr als k Replikate erzeugt, sodass möglicherweise
nur auf den unteren Ebenen des Baums Replikate existieren.
Das Resultat ist, dass sehr populäre Objekte nahe an den
Blättern – also näher an den Verbrauchern – repliziert werden,
während unpopulärere weiter oben Replikate besitzen. Daraus
resultiert eine Entlastung des Netzwerks, weil gefragte Daten
mit weniger Aufwand an den Mann gebracht werden können.
[KMS09].
das populärste Objekt auf dem Knoten platziert, für den die
durchschnittlichen Zugriffskosten aller ISPs am geringsten
sind. Danach wird die Popularität des Objekts gemäß der
Anfragen benachbarter ISPs gesenkt. Es wird wieder solange
iteriert, bis jedes Objekt k Replikate besitzt. Es handelt sich
um einen Greedy-Algorithmus, weil in jedem Schritt auf dem
besten Knoten repliziert wird.
Telekom
AOL
AT&T
Metropolis
1&1
Top CDN-Knoten
Blade
Runner
Replicant
Attack of
the Clones
Replicant
Metropolis
Popularität
DECIX
EQUINIX
Blade
Runner
Telekom
Abbildung 3. Bei einer „gierigen“ Platzierung werden Objekte dorthin
repliziert, wo viele ISPs in der Nähe sind. Dadurch können sie ökonomischer
abgefragt werden.
Attack of
the Clones
1&1
AOL
AT&T
Eine Optimierung des Algorithmus (Greedy Median Robust) berücksichtigt die Auswirkungen von Knotenausfällen
im Worst Case. Der Ablauf ist ähnlich, allerdings werden die
jeweils populärsten Objekte nicht nur solange an günstigen
Knoten repliziert, bis deren Speicher ausgeschöpft ist, sondern
es werden zusätzlich bestehende Replikate gelöscht, deren
Verlust die kleinste Verschlechterung bezüglich des Traffics
bewirkt. Des Weiteren wird am Ende verbleibender Speicher
von Knoten aufgefüllt. Dazu werden Replikate von Objekten
identifiziert, deren Ausfall den meisten Traffic verursachen
würde. In der Nähe dieser Replikate wird das Objekt dann
weiter repliziert, um den Schaden bei Knotenausfällen zu
begrenzen [KMS09].
Abbildung 2. Bei der Baum-basierten Platzierung werden populäre Objekte
möglichst an den Blättern (ISPs) platziert, damit der Zugriff ökonomisch ist.
D. Greedy
Eine weitere Möglichkeit ist der Einsatz eines GreedyAlgorithmus, wobei in jedem Schritt ein Knoten so platziert
wird, dass später minimale Kosten entstehen. Die Motivation
dafür ist folgende: Wenn Anomalien auftreten, beispielsweise
Knotenausfälle, so müssen die Kommunikationskosten zwischen den Replikaten beachtet werden, da bei einem Knotenausfall ein anderes Replikat in der Nähe die Anfragen übernehmen muss. Das gesuchte Verfahren ähnelt dem FacilityLocation-Problem, der Platzierung von k Anbietern, sodass
die Summe der Abstände jedes Verbrauchers zum nahesten
Anbieter minimal ist. Der Abstand zum nahesten Anbieter ist
demnach für die meisten Verbraucher relativ klein, er kann
aber für einige Verbraucher auch größer ausfallen. Entscheiden ist, das die Summe aller Abstände minimiert wird. Die
Anbieter entsprechen hier der Teilmenge von Knoten, die
Inhalte bereitstellen, die Verbraucher den restliche Knoten,
welche die Inhalte abrufen. Die Replikate (Anbieter) müssen
zusätzlich so platziert werden, dass ihr Ausfall zu möglichst
geringem Schaden führt. Daher platziert der iterative Algorithmus (Greedy Median) Objekte derart an Knoten (Anbietern),
dass der Zugriff für alle ISPs (Verbraucher) minimale Kosten
verursacht. Die Popularität eines Objekts wird wieder mit der
Anzahl der Anfragen initialisiert. In jeder Iteration werden
die Objekte nun absteigend nach Popularität sortiert, und
E. Dynamisch
Die drei genannten Algorithmen erfordern globales Wissen
sowie eine Instanz, die alle Knoten kennt und Replikate
zuweist. Sie bringt auch die üblichen Probleme mit sich:
Flaschenhals und Single-Point-of-Failure. Daher wird nun ein
Algorithmus vorgestellt, bei dem jeder CDN-Knoten lokal
entscheidet, ob Replikate weiter geklont oder gelöscht werden
sollen [PPV07]. Die Entscheidung basiert auf Anzahl, Inhalt,
Art von Abfragen und Last der Replikate, die der Knoten
speichert. Jeder Knoten j speichert zwei Mengen benachbarter
Knoten:
• α(j) enthält CDN-Knoten, die höchstens dmax entfernt
sind. Es sind Knoten, die j versorgen kann.
• ρ(j) enthält CDN-Knoten, die höchstens dmax von Knoten in α(j) entfernt sind. Es sind Knoten, die j bei einem
Ausfall vertreten können.
13
4~
Anhand dieser Information kann Knoten j nun überlastete
Replikate klonen und unterbelastete Replikate löschen.
Der Klonalgorithmus ist rekursiv und funktioniert wie folgt:
Knoten j bestimmt zunächst die Last eines einzelnen Replikats,
welche der Anzahl der Anfragen entspricht. Wenn die Last
einen Schwellwert überschreitet, wird solange repliziert, bis
j selbst nicht mehr überlastet ist. Dazu wählt j in jedem
Rekursionsschritt einen Knoten aus ρ(j), der die abzugebenden Anfragen am besten bedienen könnte, ohne dabei
selbst überlastet zu werden, und repliziert auf diesem das
entsprechende Objekt.
Der Löschalgorithmus kann ein Replikat nur dann löschen,
wenn es keine Anfragen mehr bedient, daher müssen Anfragen zuerst umgeleitet werden. Es besteht die Gefahr, dass
kurzzeitig nicht belastete Replikate ständig gelöscht und kurz
darauf neu angelegt werden, was dem Seitenflattern (engl. page
thrashing) bei der virtuellen Speicherverwaltung ähnelt. Deshalb wird für jedes Replikat eine Zugriffshistorie gespeichert,
über die längerfristig der Bedarf nach dem Replikat ermittelt
werden kann.
Replicant
Attack of
the Clones
ein nahe gelegener Knoten das Objekt bereits repliziert, sinkt
Tn,f . Der Algorithmus optimiert nur nach Transferkosten,
welche nicht auftreten, falls ein Knoten ein Objekt speichert.
Dabei wird nicht beachtet, dass die Speicherung ebenfalls
Kosten verursacht.
Ein Algorithmus (Storage Renting) der ebenfalls die Speicherungskosten Sn,f berücksichtigt, ist dem erstem Algorithmus sehr ähnlich. Der Aufwand berechnet sich zu An,f =
Tn,f −α·Sn,f . Dadurch ist ein Kompromiss zwischen Transferkosten und Speicherungskosten über α steuerbar [WCDT+ 06].
IV. U NSTRUKTURIERTE P2P-S YSTEME
Der Vorteil dezentralisierter, unstrukturierter P2PNetzwerke liegt darin, dass sie relativ belastbar bezüglich
der Fluktuation von Peers sind. Der Nachteil ist, dass
sie nicht skalierbar sind, weil Abfragen (engl. Queries)
über Flooding oder Walker umgesetzt werden. Beim
Flooding werden Abfragen an alle Nachbarn weitergeleitet,
das P2P-Netzwerk wird förmlich überflutet. Bei Walkern
werden Abfragen jeweils an einen zufälligen Nachbarn
weitergeleitet, es sind infolge mehrere Walker nötig, um mit
angemessener Wahrscheinlichkeit eine Datei zu finden. Weil
beide Verfahren das P2P-Netzwerk stark belasten, ist die
Reduzierung des Abfrageaufwands ein wichtiges Ziel der
Replikation [LCC+ 02].
Um das Problem zu verdeutlichen, nehme man ein vereinfachtes System mit m zu replizierenden Objekten und n
Knoten an. Jedes der mit dem Index i durchnummerierten
Objekte besitzt die Abfragerate qi (q steht für Query) und
den Replikationsfaktor ri , wird also auf ri zufälligen Knoten repliziert.
Die gesamte Anzahl von Replikaten ist somit
Pm
R = i=1 ri mit 1 < ri ≤ P
n. Die Summe der Abfrageraten
m
wird normiert und ist somit i=1 qi = 1. Das Problem kann
nun wie folgt formuliert werden: Wie muss die Verteilung
der R Replikate auf die m Objekte geschehen, damit der
Abfrageaufwand möglichst gering ist?
Drei idealisierte Verteilungen sind vorstellbar:
R
. Die
1) Die Replikate sind gleichverteilt, somit ist ri = m
Auslastung eines Replikats ist dann proportional zu Abfragerate des replizierten Objekts, der Abfrageaufwand
zum Finden eines Objekts hingegen ist für alle Objekte
gleich.
2) Die Replikate sind proportional zur Abfragerate verteilt,
somit ist ri = Rqi . Es entsteht eine perfekte Lastverteilung, da alle Replikate die gleiche Auslastung haben.
Allerdings haben populäre Objekte einen niedrigeren
Abfrageaufwand als unpopuläre.
3) Die Replikate sind proportional zur Quadratwurzel der
√
Abfragerate verteilt, ri = λ qi mit λ = PmR √q . Es
Metropolis
Blade
Runner
Blade
Runner
Abbildung 4. Bei einer dynamischen Platzierung entscheiden die Knoten
lokal, welche Objekte sie halten. Hier wird beispielhaft ein sehr populäres
Objekt repliziert.
F. Ring-basierte CDNs
Es gibt CDNs mit Ringstruktur, bei denen Objekte immer
über jeden Knoten des Rings gereicht werden. Für Algorithmen zur Platzierung von Replikaten können dabei ähnliche
Annahmen wie bei Greedy-Algorithmen getroffen werden.
Ein Algorithmus (Survival of the Fittest), der nur die Transferkosten Tn,f von Objekten beachtet, die ja immer um den
Ring herum gereicht werden, basiert auf dem Überleben der
populärsten Objekte. Wenn ein Objekt f über den Knoten n
gereicht wird, modifiziert dieser seinen Aufwand An,f = Tn,f
entsprechend der Kosten, das Objekt auf sich selbst zu übertragen. Zuerst speichern nun alle Knoten jedes weiterzureichende
Objekt bis sie voll sind, danach werden bestehende Objekte
durch populärere ausgetauscht. Allerdings sind gespeicherte
Objekte nicht unbedingt die lokal populärsten, da durch Tn,f
(Transferkosten von Objekt f zu Knoten n) auch die Entfernung zum entsprechenden Knoten berücksichtigt wird. Wenn
i=1
i
entsteht eine optimale Verteilung im Hinblick auf den
Abfrageaufwand.
Es kann gezeigt werden, dass 1 und 2 den gleichen durchschnittlichen Abfrageaufwand verursachen, und dass bei 3 ein
optimaler durchschnittlicher Abfrageaufwand besteht. Leider
sind diese Erkenntnisse theoretischer Natur, in der Praxis sind
sie kaum anwendbar, da kein globales Wissen über die Anzahl
bestimmter Replikate existiert. Allerdings gibt es verschiedene
14
~
5
Möglichkeiten, bei Abfragen auch gleich Replikate anzufertigen, um bestimmten Verteilungen nahe zu kommen. Es wird
von keinem Flooding ausgegangen, sondern von k-Walkern,
also k parallelen Walkern zwecks Verkürzung der Suche.
• Der anfordernde Knoten repliziert das Objekt (owner
replication, z.B. bei Gnutella). Es ist die einfachste Art
von Replikation.
• Das Objekt wird entlang des Pfades zwischen anforderndem und lieferndem Knoten repliziert (path replication, z.B. bei Freenet). Dies führt annähernd zu einer
Quadratwurzel-Verteilung, hat aber den Nachteil, dass
replizierende Knoten immer auf dem selben Pfad liegen,
also keine gute Streuung über das Netz stattfindet.
• Das Objekt wird auf p zufällige Knoten repliziert, die ein
k-Walker besucht hat, wobei p die Anzahl der Knoten
auf dem Pfad zwischen anforderndem und lieferndem
Knoten ist (random replication). Die Methode ist deutlich aufwendiger zu implementieren als die Vorige (path
replication) und daher eher hypothetisch, sorgt jedoch für
eine bessere Streuung der Replikate über das Netz.
•
Knoten gespeichert wird. Reagiert er nicht, können weiter
entfernte Knoten kontaktiert werden.
Unterstützt die DHT keine Lokalität, so bleibt nichts
übrig als zufällige Replikate auszuwählen und die entsprechenden Knoten zu kontaktieren bis eine Antwort
vorliegt.
B. Chord und Co
Besitzt die DHT eine Ringstruktur wie beispielsweise
Chord, so kann die Platzierung von Replikaten entweder
mit Hilfe der Ringstruktur oder der Hashfunktion geschehen
[LDH06].
1) Über Ringstruktur: Die Platzierung anhand der Struktur
ist bei einem Ring besonders gut vorstellbar. DHash etwa, ein
Speichersystem auf Basis von Chord, repliziert einen Wert auf
den r Nachfolgern des Knotens, der für den entsprechenden
Schlüssel verantwortlich ist. Zur Wartung der Replikate müssen zwei Maßnahmen regelmäßig durchgeführt werden:
•
V. S TRUKTURIERTE P2P-S YSTEME
Um in strukturierten P2P-Systemen zu replizieren, werden
in der Regel verteilte Hashtabellen (enlg. distributed hash
table, DHT) wie Chord1 , CAN2 , Pastry3 , Tapestry4 , oder
Kademlia5 als Primitiven benutzt. Dabei kann die logische
Struktur dieser Overlay-Netzwerke ausgenutzt werden, um
Replikate mehr oder minder geschickt zu über das Netzwerk
zu verteilen. Replikate können aber auch zufällig, je nach
Bedarf nach Daten (Last) oder gemäß der Verfügbarkeit von
Knoten platziert werden. Es werden im Folgenden Verfahren
beschrieben, die allgemein auf DHTs anwendbar sind, aber
auch solche, die nur mit speziellen DHTs funktionieren.
•
Zwecks Instandhaltung von Replikaten sendet jeder Knoten den Schlüsselbereich, für den er zuständig ist, an seine
r Nachfolger. Diese synchronisieren daraufhin ihre Daten,
sodass Replikate angelegt oder aktualisiert werden. Als
Optimierung können Hashbäume (engl. Merkle Tree)
verwendet werden.
Zwecks Prüfung der Zuständigkeit für Replikate sucht
jeder Knoten den Besitzer des entsprechenden Schlüssels
auf und prüft anhand dessen Nachfolgerliste, ob er selbst
innerhalb von r Hops liegt. Ist das nicht der Fall, etwa
weil neue Knoten zwischendrin beigetreten sind, löscht
er das Replikat.
Problematisch ist, dass der Ort der Replikate nicht bekannt
ist. Alle Anfragen müssen über den Knoten geleitet werden,
der für einen Schlüssel zuständig ist. Er leitet die Anfragen
dann an Replikate weiter.
2) Über Hashfunktion: Es wird, analog zum oben beschriebenen Verfahren, eine Hashfunktion h mit zwei Parametern
benutzt, um einen Wert r-mal (r = Replikationsfaktor) auf
die Knoten h(Index, Schlüssel) zu replizieren, wobei der
Index von 1 − r reicht. Der Knoten h(1, Schlüssel) ist
dabei der Besitzer. Die Methode reduziert zwar die Kosten
für das Nachschlagen, allerdings können die Kosten für die
Kommunikation zwischen replizierenden Knoten je nach Platzierung der Replikate hoch sein. Außderdem können Allokationskollisionen entstehen, wobei zwei Replikate auf dem
selben Knoten gespeichert werden – nicht gerade im Sinne
der Ausfallsicherheit.
Über die Hashfunktion können nun verschiedene Platzierungen realisiert werden:
A. Modifizierte Hashfunktion
Eine Methode, die bei allen DHTs andwendbar ist, besteht in der Modifizierung der Hashfunktion derart, dass
zu einem Schlüssel mehrere Werte (Replikate) gespeichert
werden können. Die Platzierung der Replikaten erfolgt auf
den Knoten h(Index, Schlüssel), wobei jeder Instanz ein
Index von 1 − r zugeordnet wird (r = Replikationsfaktor)
[BHW07]. Die zweiparametrige Hashfunktion h ist beispielsweise h(Index, Schlüssel) = H(Index ◦ Schlüssel) (◦ ist
die Konkatenation), sie wird also auf eine einparametrige
Hashfunktion H zurückgeführt. Beim Nachschlagen spielt es
eine Rolle, ob die DHT Lokalität unterstützt, also anhand eines
Schlüssels erkennen kann, wie weit der zuständige Knoten
entfernt ist.
• Unterstützt die DHT Lokalität, so kann zunächst das
Replikat angefragt werden, das vom nahe liegensten
•
1 siehe
http://pdos.csail.mit.edu/chord/
http://berkeley.intel-research.net/sylvia/cans.pdf
3 siehe http://www.freepastry.org/
4 siehe http://pdos.csail.mit.edu/~strib/docs/tapestry/tapestry_jsac03.pdf
5 siehe http://pdos.csail.mit.edu/~petar/papers/maymounkov-kademlia-lncs.
pdf
2 siehe
•
15
Nachfolger: Replikate werden durch die Nachfolger eines
Knotens gespeichert, was einer Nachbildung von DHash
entspricht. In Chord ist dies effizient implementierbar, es
kann allerings zu Allokationskollisionen kommen.
Vorgänger: Replikate werden durch die Vorgänger gespeichert. Dadurch kann das Nachschlagen (engl. Lookup)
effizienter bearbeitet werden, da Abfragen über die Vorgänger des Zielknotens geleitet werden, also genau über
6~
•
•
•
die replizierenden Knoten, von denen sie dann bearbeitet werden können. Allerdings treten ebenfalls verstärkt
Allokationskollisionen auf.
Finger: Replikate werden durch die Finger eines Knotens
gespeichert. Dies führt zu einer besseren Verteilung der
Replikate und zu einem schnelleren Nachschlagen.
Blockweise Platzierung: Der Schlüsselraum wird in r
gleichgroße Gruppen zerlegt, in denen jeweils alle Daten
der Gruppe durch alle Knoten repliziert werden. Dies
führt zu einer besseren Verfügbarkeit.
Symmetrische Platzierung: Replikate werden in gleichmäßigen Abständen im Ring gespeichert. Dadurch ist
die Replikation nicht von einer wechselnden Menge von
Knoten abhängig, außerdem besteht eine guten Verfügbarkeit, da Allokationskollisionen unwahrscheinlich sind.
erzeugen, da sie die Netzwerktopologie nicht kennen. Eine
Möglichkeit für eine statische Platzierung konvertiert das Problem zu einem kapazitätsbeschränkten Spezialfall des FacilityLocation-Problems (engl. Capacitated Facility Location Problem).
Es gibt Lokationen i, und die dortige Platzierung eines
Anbieters hat die Kosten fi . Ein Anbieter kann höchstens
li Verbraucher versorgen. Jeder Verbraucher j muss einen
Anbieter i haben, für ihn entstehen dadurch die Kosten dj cij ,
wobei dj die Last auf Knoten j ist und cij die Entfernung von
i nach j. Das Ziel ist nun, Anzahl und Standort von Anbietern
zu finden, sodass die Gesamtkosten am geringsten sind. Leider
ist das Problem NP-schwer, eine optimale Platzierung von
Anbietern kann daher in der Regel nur annähernd bestimmt
werden [CKK02].
D. Zeiger auf Replikate
Die bisherigen Verfahren verteilen Replikate möglichst so,
dass die Verfügbarkeit gewährleistet ist. Allerdings berücksichtigen sie nicht den tatsächlichen Bedarf nach den Daten.
Beispielsweise können Hotspots auftreten, wobei auf bestimmte Daten sehr oft zugegriffen wird. Für deren Bedienung die
bisherigen Verfahren denkbar schlecht geeignet. Eine Lösung
besteht darin, die DHT nur zu benutzen, um die Lokationen
von Replikaten verfügbar zu machen.
Im Folgenden wird dazu beispielhaft ein Algorithmus für
Chord vorgestellt, wobei ein Chord-Ring mit virtuellen Knoten und einer konsistenten Hashfunktion angenommen wird.
Benutzer (de-) registrieren Replikate (in Form einer Abbildung: Dateiname → Lokationen) bei einem lokalem Katalog, der über Updates verteilt wird. Der Wurzelknoten einer
Abbildung, also jener Knoten, der für den Schlüssel SHA1(Dateiname) zuständig wäre, speichert stattdessen das Tupel (Dateiname, Katalog). Diese Abbildungen werden wegen
möglicher Knotenausfälle auf r Nachfolgern des Wurzelknotens repliziert (r = Replikationsfaktor), vorstellbar wäre aber
auch eine andere Strategie. Bei der Fluktuation von Knoten
werden Abbildungen an neue Wurzelknoten übertragen, diese
aktualisieren wiederum ihre r Nachfolger, sodass die Kataloge
von Replikat-Lokationen erhalten bleiben [CCF04].
Das Problem ist, dass die Kataloge von Dateien aktualisiert
werden müssen, wenn Replikate hinzukommen oder entfallen.
DHTs können aber normalerweise keine Werte verändern,
sondern kennen nur Operationen wie Get() oder Set(). Allerdings können Updates über die Set-Operation emuliert werden
[CZ05].
Dazu beispielhaft ein modifizierter Lookup-Algorithmus für
Kademlia, der bei Lookups auch gleich veraltete Kataloge
auf den neusten Stand bringt: Zunächst findet der Initiator
eines Lookups alle nahesten Knoten zu einem angefragten
Schlüssel über die FIND_NODE-Nachricht, diesen schickt er
dann eine FIND_VALUE-Nachricht. Die Knoten antworten
mit dem gesuchten Wert oder, falls der Wert nicht bekannt
ist, mit dem kompletten Katalog. Der Initiator findet nun
die aktuellste Antwort (Wert), und aktualisiert Knoten mit
veralteten oder nicht vorhandenen Werten in ihrem Katalog
über STORE-Nachrichten. Das Löschen von Einträgen im
Katalog entspricht einem Update mit der Länge Null [CZ05].
C. Tapestry
Beim Routing einer Anfrage in Tapestry wird der Suffix des
Schlüssels in jedem Schritt um eine Stelle aufgelöst und die
Anfrage einen Knoten näher zum Zielknoten geleitet. Daher
rührt die Idee, über Tapestry nahe gelegene Knoten für die
Replikation zu finden.
Für den Aufbau eines Tapestry-Netzes wird von gut erreichbaren Servern in Rechenzentren der ISPs ausgegangen.
Sie bilden eine Art Verteilungsbaum für die Verbreitung der
Objekte. Aktualisierungen werden über einen Multicast auf der
Anwendungsschicht (engl. application-level multicast) verteilt.
Die Lebendigkeit des Baums, die Verfügbarkeit von dessen
Servern, wird durch Keepalive-Nachrichten von der Wurzel zu
den Kindern hin sichergestellt. Schicken diese keine RefreshNachricht innerhalb eines Timeouts zurück, werden sie aus
dem Baum entfernt.
Die mit j durchnummerierten Server haben die Beschränkung lj (Schwellwert) bezüglich der Last, Bandbreite und
Speicherkapazität. Die mit i durchnummerierten Clients haben
eine Beschränkung di (Schwellwert) bezüglich der Latenzzeit
für den Zugriff auf die Server. Das Problem lässt sich nun
formulieren: finde eine kleinste Menge von Servern S 0 , sodass
der Abstand zwischen jeglichem Client ci und seinem ElternServer sci ∈ S 0 durch di beschränkt ist. Clients und Server in
S 0 organisieren sich dabei in einem Multicastbaum (auf Anwendungsschicht) mit den Clients als Blattern und derartigem
Fanout f (si ) ≤ li der Server in S 0 , sodass sie nicht überlastet
werden.
Es sind verschiedene Platzierungen von Servern denkbar,
um die Daten zu replizieren. Eine naive Platzierung funktioniert folgendermaßen: Schickt ein Client c eine Anfrage
über Tapestry an den Server s, so schaut dieser, ob er der
Elternknoten von c ist, sprich seine verbleibende Kapazität
(engl. remaining capacity) rcs > 0 ist und sein Abstand zum
Client distIP (s, c) ≤ dc . Ist das nicht der Fall, versucht er,
ein Replikat auf einem Server möglichst nahe an c zu platzieren. Eine geschicktere Platzierung erweitert die Selektion
der Elternknoten eines Clients auf die Eltern, Geschwister und
Kinder des Servers s.
Beide Platzierungen haben das Problem, dass Clients
höchstwahrscheinlich keine optimale Anzahl von Replikaten
16
~
7
Die beiden Algorithmen beschreiben nur, wie die Lokationen vorhandener Replikate verteilt werden können. In einem
weiteren Schritt können auch die Replikate selbst in der DHT
abgelegt werden. Lookups erfolgen dann in einer zweischrittigen Prozedur; zuerst werden Lokationen ermittelt, dann die
eigentlichen Daten. Da die Replikate an keine DHT-Struktur
mehr gebunden sind, liegt es auf der Hand, das „Angebot“
strategisch gemäß der „Nachfrage“ zu platzieren.
ist. Die Replikation einer Datei läuft wie folgt ab: zunächst
werden Knoten (Kandidaten) ausgewählt, die eine ähnliche
NodeID wie der gleichlange Präfix der FileID haben. Für die
Auswahl wird eine Funktion und ein Schwellwert benötigt. Die
Kandidaten werden anhand der Tabelle bezüglich ihrer Verfügbarkeit sortiert. Nun wird auf gerade soviele der verfügbarsten
Knoten repliziert, dass die Gesamtverfügbarkeit der Datei im
Netzwerk einen festgelegten Schwellwert übersteigt [SKS09].
VI. H YBRIDE S YSTEME
E. Strategische Platzierung
In Overlay-Netzwerken ist die physikalische Lokation von
Daten teilweise überhaupt nicht feststellbar. Es ist dann aber
nicht möglich, Daten möglichst nahe an allen ISPs zu replizieren. Eine mögliche Lösung ist die Verwendung einer
hierarchischen, hybriden, zweistufigen Architektur. Auf der
höheren Ebene verhält sie sich wie ein klassisches CDN, Inhalte werden über das Backbone-Netz an Zwischnknoten verteilt,
welche strategisch in der Nähe von Internet-Knoten platziert
sind. Auf der niedrigeren Ebene verhält sich die Architektur
wie ein P2P-Netzwerk, die Inhalte der Zwischenknoten werden
über eine Art Zugangsnetz an die Benutzer verteilt [JLLB08].
Es werden einige Algorithmen vorgestellt, die Standort
und Anzahl erzeugter Replikate anhand bestimmter Kriterien
bestimmen.
1) Anhand des Zufalls: Ein randomisierter Algorithmus
(CDN-Random) wählt neue Knoten für Replikate zufällig aus
dem Overlay-Netzwerk aus. Dadurch werden die Replikate im
Netzwerk ungefähr gleichverteilt. Der Nachteil ist allerdings,
dass Replikate unter Umständen weit weg von überlasteten
Knoten platziert werden, sodass keine gute Lastverteilung
stattfindet. Außerdem ist der Algorithmus bezüglich der Anzahl angelegter Replikate relativ aggressiv. Dadurch werden
mehr Replikate erzeugt als wirklich nötig sind [AWZZ07].
2) Anhand des Bedarfs nach Daten: Ein möglicher Algorithmus (CDN-QueryStat) platziert Replikate auf oder nahe
von Knoten, von denen viele Anfragen herkommen. Dazu ist
allerdings eine Datenzugriffshistorie nötig. Replikate werden
möglichst entlang der Zugriffspfade von Queries erzeugt.
Bezüglich der Anzahl angelegter Replikate ist der Algorithmus
moderat. Es werden also nicht übermäßig viele überflüssige
Replikate erzeugt. [AWZZ07].
Eine Optimierung des Algorithmus (CDN-PriorityBased)
besteht darin, bereits replizierende Knoten möglichst mit
anderen Schlüsseln aufzufüllen. Ziel ist dabei, die Anzahl
replizierender Knoten und damit auch die Kosten für die Aktualisierungen von Replikaten (Traffic zwischen den Knoten)
zu minimieren. Was die Anzahl angelegter Replikate angeht,
ist der optimierte Algorithmus konservativ. Unter den drei
aufgeführten Algorithmen erzeugt er die beste Anzahl von
Replikaten. [AWZZ07].
Ein Algorithmus (Top-K Most Frequently Requested), bei
dem Knoten anhand der Last aktiv selbst replizieren, funktioniert wie folgt: jeder Knoten hält eine Tabelle für alle
Dateien, für die er Anfragen erhalten hat. Für jede Datei in
der Tabelle führt der Knoten eine Schätzung ihrer lokalen
Anfragerate. Eine einfache Schätzung wäre beispielsweise die
Anzahl Anfragen nach einer Datei geteilt durch die Uptime des Knotens, als Optimierung könnten jüngere Anfragen
stärker gewichtet werden als ältere. Jeder Knoten speichert
nun zunächst soviele der populärsten Dateien wie möglich.
Danach aktualisiert er laufend die Popularität von Dateien, und
ersetzen gegebenenfalls gespeicherte Dateien durch populärere
[KRT07].
3) Anhand der Verfügbarkeit von Knoten: Ein möglicher
Algorithmus (basiert auf Peer Availability Table) benutzt eine
Tabelle, um über längere Zeiträume die Verfügbarkeit von
Knoten im Netzwerk aufzuzeichnen. Für jede Datei wird eine
FileID vergeben, die länger als die NodeID eines Knotens
17
8~
VII. TAXONOMIE
die mit Hilfe der logischen Struktur des Netzwerks Replikate platzieren. Ob diese geeignet sind, um Belastungsspitzen
zu bedienen, ist allerdings zweifelhaft. Eine Tatsache, die
für P2P-Netzwerke spricht, ist, dass Last an die Benutzer
übertragen wird. P2P-basierte Content-Distributionssysteme
könnten dies verwirklichen, haben aber die üblichen Probleme
wie schnelle Fluktuation von Knoten und teilweise keine
Information über die physikalische Lokation von Knoten.
Die Fluktuation kann eingeschränkt werden, indem Benutzer
nicht Teil des P2P-Netzwerks sind, sondern Daten direkt von
Knoten beziehen. Dann wird allerdings wieder keine Last auf
die Benutzer übertragen. Die Beachtung der physikalischen
Lokation von Knoten sollte das Ziel zukünftiger P2P-basierter
Content-Distributionssysteme sein.
Replikationsstrategie
Client-Server
Zufällig
Baum-basiert
L ITERATUR
Greedy
[AWZZ07]
Dynamisch
[BHW07]
Ring-basierte
CDNs
[CCF04]
P2P
Strukturiert
[CDK05]
P2P
Unstrukturiert
[CKK02]
Über Struktur
[CZ05]
Über
Hashfunktion
[JLLB08]
Strategische
Platzierung
Abbildung 5.
[Kla06]
Taxonomie der verschiedenen P2P-Systeme.
[KMS09]
VIII. FAZIT UND AUSBLICK
Replikation dient generell dazu, Performanz und Verfügbarkeit verteilter Systeme zu erhöhen. Bei der Erfüllung
dieser Ziele spielt die Replikationsstrategie eine maßgebliche Rolle. Es existieren Strategien unterschiedlicher Güte
sowohl für Client-Server-Systeme als auch P2P-Netzwerke.
Bei Client-Server-Systemen wird in der Regel versucht, die
Daten möglichst nahe beim Verbraucher zu replizieren. Für
P2P-Netzwerke existieren ähnliche Ansätze, aber auch solche,
[KRT07]
[LCC+ 02]
18
A LQARALLEH, Bassam A. ; WANG, Chen ; Z HOU, Bing B. ;
Z OMAYA, Albert Y.: Effects of Replica Placement Algorithms
on Performance of structured Overlay Networks. In: Parallel
and Distributed Processing Symposium, 2007. IPDPS 2007.
IEEE International, 2007, S. 1 –8 V-E1, V-E2
BAUER, Daniel ; H URLEY, Paul ; WALDVOGEL, Marcel:
Replica Placement and Location using Distributed Hash Tables.
In: Local Computer Networks, 2007. LCN 2007. 32nd IEEE
Conference on, 2007. – ISSN 0742–1303, S. 315 –324 V-A
C AI, Min ; C HERVENAK, Ann ; F RANK, Martin: A Peer-toPeer Replica Location Service Based on a Distributed Hash
Table. In: Proceedings of the 2004 ACM/IEEE conference
on Supercomputing. Washington, DC, USA : IEEE Computer
Society, 2004 (SC ’04). – ISBN 0–7695–2153–3, 56– V-D
C OULOURIS, George ; D OLLIMORE, Jean ; K INDBERG, Tim:
Distributed Systems: Concepts and Design. 4th Edition. Addison Wesley, 2005 I
C HEN, Yan ; K ATZ, Randy H. ; K UBIATOWICZ, John: Dynamic
Replica Placement for Scalable Content Delivery. In: Revised
Papers from the First International Workshop on Peer-to-Peer
Systems. London, UK : Springer-Verlag, 2002 (IPTPS ’01). –
ISBN 3–540–44179–4, 306–318 III-A, V-C
C HAZAPIS, Antony ; Z ISSIMOS, Antonis: A Peer-to-Peer
Replica Management Service for High-Throughput Grids. In:
Proceedings of the 2005 International Conference on Parallel
Processing. Washington, DC, USA : IEEE Computer Society,
2005. – ISBN 0–7695–2380–3, 443–451 V-D
J IANG, Hai ; L I, Jun ; L I, Zhongcheng ; BAI, Xiangyu:
Performance Evaluation of Content Distribution in Hybrid
CDN-P2P Network. In: Future Generation Communication
and Networking, 2008. FGCN ’08. Second International Conference on Bd. 1, 2008, S. 188 –193 VI
K LAN, Daniel:
Replikation in Peer-to-Peer Systemen.
In: Workshop Grundlagen von Datenbanken, 2006, S. 90–
94. – http://www.dbis.prakinf.tu-ilmenau.de/papers/dbis/2006/
Witt06.pdf I, II
K HAN, Samee U. ; M ACIEJEWSKI, Anthony A. ; S IEGEL,
Howard J.: Robust CDN replica placement techniques. In:
Proceedings of the 2009 IEEE International Symposium on
Parallel&Distributed Processing. Washington, DC, USA :
IEEE Computer Society, 2009. – ISBN 978–1–4244–3751–1,
1–8 III-B, III-C, III-D
K ANGASHARJU, Jussi ; ROSS, Keith W. ; T URNER, David A.:
Optimizing File Availability in Peer-to-Peer Content Distribution. In: INFOCOM 2007. 26th IEEE International Conference
on Computer Communications. IEEE, 2007. – ISSN 0743–
166X, S. 1973 –1981 V-E2
LV, Qin ; C AO, Pei ; C OHEN, Edith ; L I, Kai ; S HENKER,
Scott: Search and replication in unstructured peer-to-peer
networks. In: Proceedings of the 16th international conference
on Supercomputing. New York, NY, USA : ACM, 2002 (ICS
’02). – ISBN 1–58113–483–5, 84–95 IV
~
9
[LDH06]
L ESLIE, Matthew ; DAVIES, Jim ; H UFFMAN, Todd: A
Comparison of Replication Strategies for Reliable Decentralised Storage. In: Journal of Networks 1 (2006), Nr. 6, S.
36–44. – http://www.academypublisher.com/jnw/vol01/no06/
jnw01063644.html V-B
[PPV07]
P RESTI, Francesco L. ; P ETRIOLI, Chiara ; V ICARI, Claudio:
Distributed Dynamic Replica Placement and Request Redirection in Content Delivery Networks. In: Proceedings of the
2007 15th International Symposium on Modeling, Analysis,
and Simulation of Computer and Telecommunication Systems.
Washington, DC, USA : IEEE Computer Society, 2007. – ISBN
978–1–4244–1854–1, 366–373 III-E
[SKS09]
S ONG, Gyuwon ; K IM, Suhyun ; S EO, Daeil: Replica Placement Algorithm for Highly Available Peer-to-Peer Storage
Systems. In: Advances in P2P Systems, 2009. AP2PS ’09.
First International Conference on, 2009, S. 160 –167 II, V-E3
[WCDT+ 06] WAUTERS, Tim ; C OPPENS, Jan ; D E T URCK, Filip ; D HOEDT,
Bart ; D EMEESTER, Piet: Replica placement in ring based
content delivery networks. In: Comput. Commun. 29 (2006),
October, 3313–3326. http://dx.doi.org/10.1016/j.comcom.2006.
05.008. – DOI 10.1016/j.comcom.2006.05.008. – ISSN 0140–
3664 III-F
19
~
1
P2P SERVICE DESCRIPTION LANGUAGE
P2P Service Description Language
Dimitar Goshev
Architecture(SOA), an architecture designed to support the
implementation of services.
Chapter 3 provides information about the role of a P2P
service description language and the speciffic issues, which a
P2P service description will address.
Chapter 4 gives a detailed view of OWL-S and how it could
be used for P2P service description and chapter 5 presents
briefly alternatives, which has been considered during this
research.
Abstract—P2P networks are increasingly used for different
kinds of services, which could be generally implemented in a
P2P cloud system.
Technologies known from the Service Oriented Architecture,
such as description languages for services could be a powerful
tool in such a P2P service cloud.
This paper gives an overview of the Service Oriented Architecture, describes the role of a P2P service description,
and introduces the Ontology Web Language for Services as a
description language for P2P services.
It illustrates that a description language for P2P services could
provide substantial value to the P2P computing paradigm and is
one of the technologies and machanisms that will allow transition
from file-sharing to service- and data-sharing in P2P networks.
II. S ERVICE O RIENTED A RCHITECTURE
When we deal with the notions of service and service
description, it is inevitable to have a look at the Service
Oriented Architecture(SOA), in order to gain knowledge about
the traditional approaches to service description, discovery and
invocation.
SOA is an architecture designed to support the implementation of services. It could be defined as a set of design principles
for building large loosely coupled systems, which package
functionality as inter-operable services.
SOA defines an interaction model between three primary
parties - the service provider, the service broker and the service
client [Figure 1].
I. I NTRODUCTION
In the recent years P2P netowrks are increasingly used
for a variety of services. The diversity among the types of
P2P services, along with the different kinds of P2P systems,
has made it difficult to establish a widely accepted set of
standards and protocols, that would facilitate the description
of P2P services. Each one of the contemporary P2P networks
accommodates its own proprietary set of protocols, which
are arbitrarily designed in a way to enable their specific
features and properties. They present limited or no capabilities
for automated service discovery, selection, composition and
invocation.
A description of P2P service, which provides sufficient information to enable mechanisms for publishing and discovery
of the service in the P2P network and facilitate interaction
between the peers, could be one way to address these issues.
An interpretaion of such a description must be consistent
among all the participants in a service interaction. Therefore
a necessity to establish a standartized approach for describing the services arises. In this paper this is addressed by
introducing the Ontology Web Language for Service(OWLS) as a description language for P2P services. Thus enabling
description of P2P services, that can be used unambiguously
across and between different implementations. OWL-S allows
the service description to answer questions, such as “What
does the service provide?”, “How is the service used?” and
“How to access the service?” in a machine-understandable
form. Descriptions in OWL-S are in no way limited to services,
which follow the client/server model. In fact the research
shows, that by introducing semantics to service description,
OWL-S enables mechanisms to discover and locate services
in P2P netwrorks and is powerful enough to describe details
on how to divide composite services into sections, which can
be executed by different execution peers.
Figure 1.
The three primary roles in the service interaction model.
The service provider creates the service description and
implementation and publishes its interface and access information to the service registry. The service broker manages
registries, and supplies information about services to enables
clients to discover the service. The service client locates entries
in the broker registry and binds to the service provider in order
to invoke the given service.
A. Overview of techologies in SOA
This paper is organized as follows: In order to present
traditional approaches to service description, discovery and
invocation, chapter 2 gives an overview of the Service Oriented
The traditional service solutions use a server-centric approach to manage all components. This limits their deployment
to static domains, since a service invocation will fail, if
20
2~
the server component changes its availability or location.
The services are typically defined by a set of standards,
including Extensible Markup Language(XML), Simple Object
Access Protocol (SOAP), Web Services Description Language
(WSDL), and Universal Description, Discovery and Integration(UDDI). These technologies are described bellow.
•
1) SOAP: Commonly an invocation of a service is accomplished through exchange of a series of messages, normally
encoded in XML. SOAP, a lightweight protocol for exchange
of information in a decentralized, distributed environment, is
the most widespread technology for exchanging these messages.
The protocol consists of three parts: an envelope that defines
a framework for describing what is in a message and how
to process it, a set of encoding rules for expressing instances of application-defined data-types, and a convention for
representing remote procedure calls and responses[8]. SOAP
typically depends on other Application Layer protocols, most
notably Remote Procedure Call (RPC) and Hypertext Transfer
Protocol (HTTP), for message negotiation and transmission.
However the SOAP/TCP[9] and SOAP-over-UDP[5] specifications, present an alternative approach, which eliminates the
need of application layer protocol.
SOAP also provides mechanism for binary data transfer.
That is the SOAP Message Transmission Optimization Mechanism(MTOM) - a W3C recommendation by Microsoft, IBM,
EBA and Canon.
MTOM makes use of the XML-binary Optimized Packaging(XOP) format for optimizing the transmission of SOAP
messages. It combines the composability of Base 64 encoding
with the transport efficiency of SOAP with Attachments(SwA).
Non-XML data is processed just as it is - the data is simply
streamed as binary data in one of the Multipurpose Internet
Mail Extensions(MIME) message parts.
Solutions for data transfer with MTOM, such as file transfer
in chunks, exist and demonstrate the feasibility of using this
technology for data transfer in P2P networks. Experiments
show that XOP/MTOM, keeps performance of binary data
transfers via service interface at a reasonable level[15].
Other alternatives for handling binary data in SOAP messages are also available: SwA and Direct Internet Message
Encapsulation(DIME).
•
•
•
•
3) UDDI: The discovery of the services is facilitated by
UDDI. It defines a standard method for publishing and discovering the network-based software components of a SOA.
The core information model used by the UDDI registries is
defined in an XML schema. The UDDI XML schema defines
four core types of information: business information, service
information, binding information, and information about specifications for services. UDDI provides only a central registry
[2].
Figure 2 illustrate a traditional scenario of development and
deployment of services.
Figure 2.
2) WSDL: The WSDL definition describes how to access
a service and what operations it will perform. The data-types
for the information passed between the service consumer and
provider are described using WSDL. The services are described as a set of endpoints operating on messages containing
either document-oriented or procedure-oriented information.
The operations and messages are described abstractly, and then
bound to a concrete network protocol and message format to
define an endpoint[3].
A WSDL document uses the following elements to describe
a service:
•
Operation - an abstract description of an action supported by the service. Four types of operations exist:
a “request-response”,where the client expects response
from the service, a “solicit-response”,where the service
expects a response from the client,“one-way” operation,
representing a call by the client to the service, and
a“notification”, representing a call by the service to the
client.
Interface - an abstract set of operations supported by one
or more endpoints.
Binding - a concrete protocol and data format specification for a particular port type.
Endpoint - defines the address or connection point to a
service.
Service - a collection of related endpoints, which has
been exposed to the web based protocols.
The traditional services development/deployment scenario.
B. P2P and SOA
From the described technologies above it is clear, that the
traditional service solutions, present an approach, where the
three main parties of the interaction model are commonly
thought of as separate entities.
However, it is more useful to consider the client, the
provider and the broker as simply different behavioral roles,
rather than separate pieces of software. In fact SOA doesn’t
impose a particular implementation style such as specifically a
client/server, request-response model. The alternative approach
to service interaction, namely services communicating in a P2P
fashion, requires each node to accumulate one, two or all of
the roles simultaneously.
Types - a container for data type definitions using some
type system. XML Schema is used (in-line or referenced)
for this purpose.
21
~
3
In a P2P SOA, each node should be able to act as a provider
of a set of services, a consumer of a service, and a broker,
which offers information about services presented by the node
and other nodes in the network. Of course, the nodes are
responsible for their own security, reliability, process, and
management capabilities.
how to divide the described composite service into sections, which can be executed by different execution peers.
•
III. D ESCRIPTION OF P2P S ERVICES
•
In order to provide a P2P service description language, first
we need clear definitions of “What is a P2P service?” and
“What is the role of the P2P service description?”.
A service is defined as a mechanism to enable access to one
or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints
and policies as specified by the service description[12]. In [10]
is stated that, the term P2P service has emerged as a result of
the merging of P2P and service oriented computing paradigms
and that the term itself has not yet reached consensus among
the P2P community.
The definition of a service is not restricted to services
following client/server approach. Therefore in this paper the
term P2P service is considered equivalent to the term service
defineded above, with the additional knowledge, that these
services are used in a P2P network.
IV. OWL-S
The Ontology Web Language for Services is an ontology for
services. It is often referred as a semantic markup language
for describing services, due to the fact that it provides a standard vocabulary to create service descriptions, comprehensive
enough to support the entire lifecycle of service tasks[4]. It
is formerly known as DARPA agent markup language for
services(DAML-S) and some of the researched materials reffer
it as such. OWL-S is based on the Ontology Web Language(OWL), a semantic markup language for publishing and
sharig ontologies. In OWL ontologies are primarily exchanged
as RDF documents(an RDF/XML serialization).
OWL-S presents a semantic markup to describe what is
being sent and why, not just how it is being sent. It has been
developed as a joint effort between Carnegie Mellon University, Nokia, Stanford University, SRI International and Yale
University as an aim to provide ontology, which automates the
discovery, invocation, composition, interoperation and monitoring of servicess. It complements existing technologies such
as SOAP, WSDL, UDDI, and Web Services Business Process
Execution Language (WS-BPEL) by providing rich typing and
class information that can be used to describe and constrain the
range of service capabilities much more effectively than XML
data types[13]. OWL-S supplies an abstract or application
level description absent in other description languages such
as WSDL.
The OWL-S ontology includes three primary subontologies: the service profile, service model, and grounding[
Figure 3 ].
Genrally the service profile provides information about what
does the service provide, the service model, also referred as
process model gives information on how to use the service,
and the service grounding supplies the necessary details about
accessing the service.
B. P2P Service Description
In general the description of a P2P service should present
sufficient information to enable mechanisms for publishing and
discovery of the service in a P2P network and facilitate interaction between the peers. While, there are certain elements that
are likely to be part of any service description, many elements
such as function and policy may vary.
The specific goals of the description could be summarized
as follows:
• Publication and Discovery - Describe what this service
does and how to locate it in the P2P network. Present such
a description, that could be used by discovery systems,
which perform on distributed registries on ad hoc and
managed networks. Specify the set of constraints and
policies, under which the service operates.
•
•
Security - Provide information about how to address
issues such as authentication, authorization and privacy,
evalute security parameters, etc.
In the next chapter is illustrated that description of P2P
services with OWL-S, accomplishes to supply the necessary
information to achieve all of the listed above goals.
A. P2P Service
•
Verification and Monitoring - Supply information about
how to verify the service execution and recognize when
errors occur, log and track progress of the execution.
Selection - Provide enough details about the service
capabilities and other critical information, that a client
needs in order to decide whether or not, the described
service is the most appropriate one for the given task.
Service invocation - Provide information on how the
client can interact with the service and how exactly to
access it. This information should be preferably presented
in a way understandable not just for developer of a client
agent, but for a software agent, to enable automated
invocation of P2P services.
A. Service Profile
The service profile is a high-level characterization of the
service. It defines explicitly what are the server capabilities
and what it provides. Its main purpose is to enable advertising,
discovery and selection for services. It contains two type
of properties, that describe the service - non-functional and
functional properties.
Composition - Present information on how to combine
multiple services in the P2P cloud to achieve the desired
goal. The description should contain enough detail on
22
4~
Figure 3.
Top level of the service ontology.
The non-functional properties describe what is achieved by
the service, its limitations and boundaries, as well as other
information such as location of the service, QoS features
describing its characterics, etc.
The functional properties consist of inputs, outputs, preconditions and effects.
1) Inputs, Outputs, Preconditions and Results: Inputs represent the the object descriptions that the service works on, i.e.
the information that the service will receive. Outputs represent
the object descriptions that it produces, i.e. the information
that the client will receive. Preconditions define what must
be satisfied in order the service to function as expected
and effects, also known as results, describe what conditions
will be changed after the service completes. Inputs, outputs,
preconditions, and effects are used, by all three components
of an OWL-S service model. The service profile could contain
only the ones that are necessary for the discovery and selection
of the service.
Figure 4.
•
•
•
Top level of the process ontology.
Any-Order - processes, which have to be executed in
some unspecified order but not concurrently.
If-Then-Else - conditional control constructs.
Iterate, Repeat-While, and Repeat-Until - for iteratation
over a given set until a condition becomes false or true
The process model could be used to automate the interaction with P2P services. There exist a working solution for
automatic automatic invocation of services described in OWLS, namely the OWL-S VM.
C. Grounding
The service grounding specifies the details on how to interact with the service. It enables service calls to be translated to
messages for use by transport protocol languages. For example
the grounding could be used to create mapping to WSDL[
Figure 5 ] or Universal Plug and Play (UPnP)
B. Process Model
All services described with OWL-S are represented by an
instance of the OWL class service, which properties associate
it with a process model. A process model[ Figure 4 ] describes
how the service is used, i.e. how it executes its tasks. It
contains all of inputs, outputs, preconditions and effects, to
describe precisely the behavior of the service.
The process model decribes three type of processes: composite, atomic and simple processes.
Atomic processes correspond to the actions a service can
perform by engaging it in a single interaction. Simple processes, can be used to provide abstracted, non-invocable
views of atomic or composite processes. Composite processes
are decomposable into other (non-composite or composite)
processes[1]. The composition is created through control constructs. The available control constructs are:
• Sequence - a list of control constructs to be done in order.
• Split - process components to be executed concurrently.
• Split + Join - same as Split with additional barrier
synchronization.
• Choice - for execution of a single control construct from
a given set.
Figure 5.
23
Mapping between OWL-S and WSDL.
~
5
D. Other Ontologies
V. A LTERNATIVES
Apart from the ontologies described above, OWL-S defines
an ontology for the required resources. This ontology covers
the description of physical resources, temporal resources and
computational resources related to the services.
In [23] is described a method for extending the monitoring
capabilities of OWL-S through event based monitoring. An
additional Event Ontology is introduced to achieve that and
enable further capabilities for logging, performance measuring, evaluations of security parameters and execution progress
tracking of services.
OWL-S also creates a layer of abstraction on top of the
various existing security standards, such as XML Signature,
WS-Security, etc, as well as abstraction for security notations
such as Authentication, Authorization, AccessControl, Confidentiality, Privacy, Anonymity, Negotiation, KeyDistribution,
etc. This is achieved through several security related ontologies. These are namely the Credential Ontology, Security
Mechanisms Ontology, Service Security Extensions Ontology,
Agent Security Extensions Ontology, Privacy Ontology and
Cryptographically Annotated Information Object Ontology.
In the course of this research several others alternatives
for service description were considered. These are WS-CDL,
WSCI, WSMO, WSDL-S, PSDL, to name a few. Here are
briefly presented two other languages, which were considered
as main alternatives of OWL-S.
A. WS-CDL
WS-CDL describes P2P collaborations of Web Services participants by defining, from a global viewpoint, their common
and complementary observable behavior, where ordered message exchanges result in accomplishing a common business
goal. WS-CDL is targeted for composing interoperable P2P
collaborations between any type of Web Service participant
regardless of the supporting platform or programming model
used by the implementation of the hosting environment[6].
In WS-CDL the collaboration between services takes place
within a set of agreements about the ordering and constraint
rules, through which messages are exchanged between participants. However it is widely accepted that the language has
several drawbacks which makes it impractical. It is lacking
separation between meta-model and syntax as well as comprehensive formal grounding[11]. As a further drawback it is
difficult to write WS-CDL specifications that can be considered elegant or intuitive and specifications of even smaller
interactions become rather lengthy[19]. Few implementations
exist s.a. WS-CDL Eclipse and LTSA WS-Enginee but both
were last updated in 2005. The last specification of the
language is from 2005 and the W3C Choreography Working
Group was closed in 2009.
E. P2P Service Discovery
Solutions for service discovery in a P2P network with
semantic descriptions support are described in several papers(
[20], [14], [21], [22], [18] and [17]). They all describe
capability-based service discovery in systems, which doesn’t
contain a central registry.
The described in [18] and [20] P2P service discovery
mechanisms use OWL-S for service description and rely on
the Gnutella P2P protocol.
An actual implementation of platform independent and
highly flexible service discovery system for ubiquitous peer-topeer networks is described in [17]. Again OWL-S is used for
service description, WSDL is used for interface descriptions,
and SOAP for remote invocation over a JXTA P2P infrastructure. The inference engine JTP (Java Theorem Prover)
is used as reasoner for evaluating the service capabilities.
The author of this paper concludes, that reasoning using an
inference engine and semantic descriptions, allows powerful
service discovery.
B. WSMO
Web Service Modeling Ontology(WSMO) is to some extend
similar to OWL-S. It is based on concepts from the Web
Service Modeling Framework(WSMF) It defines four components:
• Ontologies - provide the terminology and formal semantics for describing the other elements in WSMO.
• Goals - consist of non-functional properties, imported
ontologies, mediators used, post-conditions and effects.
• Web Services - provide a semantic description of Web
services, including their functional and non-functional
properties. The main descriptions are the capability and
the interface.
• Mediators - represent connectors that resolve heterogeneity problems in order to enable interoperability between
heterogeneous parties[16].
In contrast to OWL-S, at the moment software tools and
libraries for WSMO are rare.
F. Automated Service Invocation
OWL-S supplies declarative, computer-interpretable API
that includes the semantics of the arguments to be specified
when executing service calls, and the semantics of data returned, when the services succeed or fail. Therefore services
described in OWL-S could be automatically invocated in
contrast to the traditional approach, where an agent is preprogrammed to perform calls to the particular service. An
existing solution for automatic invocation is OWL-S VM. This
implementation also takes into account privacy and authorization constraints that cryptographic techniques can implement.
Peers using services implementing the OWL-S VM are able
to maintain secure communication with other peers. SOAP
security annotations are used to implement the actual message
encryption or signing. [7]
VI. C ONCLUSION
Contemporary P2P networks accommodate their own proprietary set of protocols and provide limited or no capabilities
for automated service discovery, selection, composition and
invocation. OWL-S and other service description languages
were examined as possible solution to address these issues.
24
6~
The research showed that OWL-S is capble to create description for services, which are comprehensive enough to
support the entire lifecycle of service tasks. Moreover it
accomplishes to provide descriptions, that enable mechanisms
for service discovery on ad hoc and managed networks, as
well as automated invocation of services.
A varieity of authoring tools, libraries and APIs for the
language, give this language another advantage over its competitors.
The research showed that a description language of P2P
services could provide substantial value to the P2P computing
paradigm and is one of the technologies and machanisms that
will enable transition from file-sharing to service- and datasharing in P2P networks.
R EFERENCES
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]
[17]
[18]
[19]
[20]
[21]
[22]
[23]
OWL-S Release 1.2 :: www.daml.org. IV-B
UDDI Technical White Paper. 9 2000. II-A3
WSDL Specification :: http://www.w3.org/TR/wsdl. 3 2001. II-A2
OWL-S: Semantic Markup for Web Services W3C Member Submission
:: http://www.w3.org/Submission/OWL-S/. 11 2004. IV
SOAP-over-UDP Specification :: http://specs.xmlsoap.org/ws/2004/09/soapover-udp/soap-over-udp.pdf. 9 2004. II-A1
Web Services Choreography Description Language Version 1.0 W3C
Candidate Recommendation :: http://www.w3.org/TR/ws-cdl-10/. 11
2005. V-A
OWL-S Technology for Representing Constraints and Capabilities of
Web Services :: http://www.w3.org/2004/08/ws-cc/dmowls-20040904. 7
2007. IV-F
SOAP
W3C
Recommendation
Version
1.2
::
http://www.w3.org/TR/soap/. 8 2007. II-A1
SOAP/TCP
Version
1.0
Reference
::
http://java.sun.com/webservices/reference/apis-docs/soap-tcp-v1.0.pdf.
5 2007. II-A1
M. Pantazoglou A. Tsalgatidou, G. Athanasopoulos. A P2P Service
Description Language Specification: Technical Report. III-A
Phillipa Oaks Alistair Barros, Marlon Dumas. A Critical Overview of
the Web Services Choreography Description Language (WS-CDL). 3
2005. V-A
F. McCabe P. Brown R. Metz C. Matthew MacKenzie, K. Laskey.
Reference Model for Service Oriented Architecture 1.0. III-A
Drew McDermott Sheila McIlraith Massimo Paolucci Katia Sycara
Deborah L. McGuinness Evren Sirin David Martin, Mark Burstein and
Naveen Srinivasan. Bringing Semantics to Web Services with OWL-S.
2007. IV
Valeria De Antonellis Devis Bianchini and Michele Melchiori. Servicebased Semantic Search in P2P Systems. IV-E
Andrew Wendelborn Donglai Zhang, Paul Coddington. Binary Data
Transfer Performance Over High-latency Networks UsingWeb Service
Attachments. II-A1
D.Roblek. Decentralized Discovery and Execution for Composite
Semantic Web Services. V-B
Daniel Elenius. Service Discovery in Peer-to-Peer Networks. IV-E
Ching-Chien Chen Farnoush Banaei-Kashani and Cyrus Shahabi.
WSPDS Web Services Peer-to-peer Discovery Service. IV-E
Lars Ake Fredlund. Implementing WS-CDL. V-A
Takuya Nishimura1 Naveen Srinivasan1 Massimo Paolucci1, Katia Sycara1. DAML-S for P2P Discovery. IV-E
Jian Yang Mike P. Papazoglou, Bernd J. Krämer. Leveraging webservices and peer-to-peer networks. IV-E
Marek Paralič and Gabriel Gécy. Web Services discovery in P2P registry
with semantic descriptions support. IV-E
Katia Sycara Roman Vaculín. Semantic Web Services Monitoring: An
OWL-S based Approach. IV-D
25
~
1
CHEATING DETECTION IN P2P-BASED MASSIVE MULTIPLAYER ONLINE GAMES
Cheating Detection in P2P-based Massive
Multiplayer Online Games
Georgi Hadshiyski
on the server. That way the game can scale well even with
million of people playing at the same time. This not only
saves money on servers and bandwidth, but also increases
the stability of the system. Although this approach solves the
scalability issues in MMOGs quite well, it also introduces
other problems. With this peer-to-peer decentralization the
server loses most of the control it has over the correctness
of the game state. With the computation of the next game
state happening in the clients themselves, it becomes easy to
manipulate and cheat inside the virtual game world.
Cheating prevention is very important in the development
of any multiplayer game. If there are cheaters in the game, the
normal players can easily become frustrated with the gameplay
and thus stop playing. This problem is even more serious
in MMOGs because most of them operate by requiring a
monthly subscription fee from the players. So the reduction
of the number of players means direct profit losses. Cheating
detection and prevention is extremely important to ensure
commercial viability of P2P-based MMOGs.
The rest of the paper is organised as follow: In the following
Section of the paper we review a typical game architecture in
order to better understand the relationships between the different entities both in centralized and decentralized MMOPGs.
In Section 3 we discuss the possible implementation types
of cheating detection architectures. After that we define and
review different categories of cheating. By providing this classification we can better understand the cheating possibilities
and then be able to tackle each of those problems separately.
The fifth Section makes comparisons with similar work in this
area done by other authors and in the end we make conclusions
about the plausibility of cheating prevention in this kind of
systems and the need for future work.
Abstract—In the recent years there has been a lot of development of Massive Multiplayer Online Games (MMOGs), which
has shown to be very profitable and is now a billion-dollar
industry. However because of the huge number of players, the
normal client-server architecture approach doesn’t scale well
and it becomes increasingly hard to support the traffic and
the computational power needed for the servers. A peer-to-peer
approach to the game development solves those scalability issues.
However this new approach is more cheating-prone because the
server loses most of the control over the game state. Cheating
in MMOGs is a serious issue because it can lead to player
dissatisfactions and losses for the companies providing games.
In this paper we review and compare different types of cheating,
discuss why cheating is a problem and look into the ways to
detect and prevent cheating in MMOGs.
I. I NTRODUCTION
In the recent years there has been an enormous growth in the
availability and the speed of the internet connection throughout
the globe. This enabled the creation of massive multiplayer
games where hundreds, thousands or even millions of people
can play together inside a virtual game world. This new genre
of computer games has been very successful and profitable.
The game called World of Warcraft (WoW) now has more
than 12 million subscribers worldwide and the company that
created the game (Blizzard Entertainment) collects revenue in
the billions each year.
Although the development of Massive Multiplayer Online
Games (or MMOGs) have shown to be quite profitable, the
huge number of people playing simultaneously introduces a
completely new set of problems. The main problem is the
difficulty to support the game server. On one hand big server
farms are needed just for the computation of the game state.
This is very expensive and can be error-prone because it
introduces a single point of failure. On the other hand the
sheer number of people playing at the same time requires a
huge amount of traffic going in and out of the server. This
can also become expensive with the growth of the number
of people simultaneously playing and can lead to game lag
if the server can’t support that many people. Game lag can
be very frustrating to players and thus can lead to players
dissatisfaction, resource misuses and profit losses. To tackle
the scalability problems, a peer-to-peer approach can be used
to decentralize the game. In the normal client-server approach
all of the information is transferred between the server and the
player and the game state is computed at the server. With the
peer-to-peer approach however, most of the game traffic and
game state computation goes between the players themselves,
thus relieving the huge computational and bandwidth pressure
II. G AME A RCHITECTURE
A typical server-client oriented MMOG has the architecture
shown on Fig.1. First, there is an authentication server which is
responsible for account management.(a) Then there is a game
server, which is responsible for maintaining the game state(b).
All of the clients(c,d,e) are communicating directly with the
game server after they have logged in.
As seen in Fig.2, in a P2P-oriented MMOG architecture
the management of the game state is outsourced to the client.
The only centralized server left is the authentication server(a).
The computational power and traffic needed for maintaining
a login system is not that high and thus decentralization of
account management is not needed. In this kind of architecture
however there is no longer a need for a game server. Instead,
26
2~
Fig. 1.
Client-Server based game architecture
Fig. 2.
P2P-based game architecture
server in order to create and maintain different constraints
on the clients. Although easily implemented, this approach
suffers from the scalability issues that come from the use of a
server-client oriented architecture. With an increased number
of players, the computational power needed for cheating
detection rises and becomes very costly.
Another possibility is to outsource the detection system
to the client nodes. This approach is better suited for a
peer-to-peer based game architecture because it enables good
scalability. In this kind of cheating detection architecture the
clients themselves are computing and verifying the validity of
other players actions. The general idea is that although a single
client node can’t be trusted, a consensus between few random
nodes can be trustworthy enough to provide good cheating
prevention. A few not affiliated client nodes are chosen as
monitoring nodes and are responsible for cheating detection
for a certain number of players. If inconsistencies are detected,
a majority vote is taken in order to determine the correct
action. [1] discusses the problems stemming from P2P-based
cheating detection and proposes a plausible implementation.
The third option for cheating detection is a hybrid between
previous two proposals. Such approaches try to minimize
the cheating risks that stem from a decentralized detection
system, while still maintaining low server computational and
traffic requirements. Log Auditing[4] is one such proposal.
This implementation outsources the game state to the client
machines in order to maintain good scalability. However the
cheating detection mechanism remains on the server. In order
to reduce traffic and computational server requirements, the
cheating detection is not computed in real time. Instead, the
different game state changes are recorded and analysed at
a later time. This reduces the computational power pressure
because the server can use periods of time with lower demand
in order to check for cheating. Although there is a delay
between the cheat and the cheat detection, with good logging
the game can easily be rolled back to revert the damage done
by the cheater.
IV. T YPES OF C HEATING
In order to better understand and defend against the different cheating possibilities, a classification of those cheating
attempts is needed. In this Section we review the different
categories of cheating according to the target of the attack.
First we review cheats that are possible in multiplayer games
in general. Every multiplayer game needs to deal with those
cheating possibilities (or at least part of them) regardless of
the types of architecture the game uses.
After that we review cheating that stems from the use of
a P2P-based architecture. A game client can exploit the fact
that the system is decentralized to get an advantage over other
player or players. Here we discuss what can be exploited and
show examples of different cheating attempts.
a number of game clients (with enough resources) are chosen
in order to maintain the game state(b). The game space is
divided into subareas and each subarea has a responsible node.
Other players(c,d) in this subarea are communicating with their
responsible node instead of the server. Thus the local state of
a sub-area is held at the responsible node and the whole game
state can be seen as the sum of the game states of each of
these subareas.
III. C HEATING D ETECTION A RCHITECTURES
There are three possible approaches to implement cheating
detection and prevention mechanisms.
The first approach is to detect cheating on the server side.
In this case the developing company provides a big server
(or server farms) that makes sure no cheating is taking place.
A possible approach [3] is the symbolic execution on the
A. Categories of cheating
Almost all multiplayer games suffer from cheating attempts
regardless of the number of players and the type of game
architecture. Although most games are not played for financial
27
or other gain, but only for entertainment instead, there are still
a lot of people that try to gain an illegal advantage over their
fellow players. This can frustrate a lot of people and thus the
game can lose its appeal.
In this Subsection we are categorizing the types of cheating
that can take place in multiplayer games in general, including
P2P-Based MMOGs. To better illustrate the problems, there
are examples for each of those categories.
1) Authentication Cheating: This is one of the most frequently seen security problems in network applications in general. In almost all multiplayer games the server provides some
kind of an authentication system with which the player can
identify himself (usually by providing user-name and password
or something similar). A cheater can exploit weaknesses in
this authentication system in order to gain access to somebody
else’s account and/or virtual assets.
One possibility is to exploit the fact that a lot of players use
weak passwords that can easily be cracked with a dictionary
attack or in some cases even by a brute force approach.
Another possibility is to exploit weaknesses in the implementation of the authentication system itself. For example
some games use a regular telnet connection (where the username and the password are transmitted as plain text between
the client and the authentication server). A cheater can snoop
this connection in order to get access to the login information
of another player’s account.
In some cases (if the server cannot authenticate himself to
the client) a hacker can get access to hundreds of accounts by
simulating the authentication server. In this case the clients are
unwillingly sending their account information to the cheater
instead of the real authentication system.
Although this kind of cheating can never be completely
prevented due to the possibility of human error, most of
this kind of cheating attempts can be evaded through good
authentication server design.
The server needs to authenticate itself to the client to prevent
server impersonation and all traffic between the client and the
server (especially the password) needs to be encrypted - this
way we can prevent account information snooping. In addition
the server can require the players to register with a longer and
more complicated password (for example containing at least
one number and at least one special character). Thus we can
prevent password guessing success with high probability.
2) Client Modification Cheating: This cheating possibility
arises when too much trust is put into the client. A cheater
can modify his game client or machine in order to perform
illegal actions or get access to information he is not supposed
to.
For example there are the so called "wall hacks" in the
game "Counter Strike"[cs]. In this case the cheater exploits
the fact that his client receives information about the position
of all other players regardless of who the player can actually
see in the game. With a slight client modification the cheater
can see all enemies (through the walls), although he is not
supposed to. This problem comes from the fact that the server
trusts every client with all player positions instead of only
those visible from the player’s current position. The cheater
can then exploit this knowledge to gain advantage over the
~
3
other players.
There are a few ways to prevent modification cheating. The
easiest way is to restrain the trust put on the client.
For most online games the actions of the player and the
results of those actions can be checked in the server against the
current game state to see if they are valid. With peer-to-peer
MMOGs however this becomes more complicated because a
lot of the game state management is outsourced to the clients
themselves - usually through the use of responsible nodes or
a similar approach. This problem can be solved by the use of
monitoring nodes that make sure all the players are playing
fair.
Another way to prevent this type of cheating is to introduce additional software that prevents any client modification.
Every client needs to install this additional software before
playing the game. If a cheater then attempts to modify his
game client or use some kind of helping tools, this additional
protection software can detect and prevent that. Although this
approach has already been implemented and shows promising
results, this piece of software is still on the client machine so
it is theoretically possible to hack it as well.
3) Outside Information Cheating: One of the biggest problems in multiplayer games is the fact that the server cannot
refrain a client from accessing information outside the game
architecture. In this type of cheating a player can gain advantage over the other clients by using access to information
outside of the game.
For example, a chess player can use an advanced computer
program to calculate his next move. This way his opponent
stands no chance since even the best chess players often lose
against those advanced chess programs. That way the cheater
gains a huge advantage by using outside information.
For another example let’s look at a four-person game of
poker. If three of the players are talking to each other over the
telephone and giving each other information about what cards
they have, then the forth person will definitely lose his money
sooner or later no matter how skilled he is, or how much
luck he has. In this case the three cheaters are exploiting an
outside line of communication to gain an advantage over the
unsuspecting forth player and thus win the game.
There is no plausible way to completely prevent this type of
cheating without invading user privacy. The only way to reduce
the risk of this type of cheating is to design the game in a way
to prevent it. For example, lets consider again the four-person
poker game. If the players in a game are chosen randomly
then it will be hard for three cheaters to collaborate against
the forth, because the odds are that they are all going to play
in different games (on different tables). This kind of solution
is however game specific and has its limitations both in terms
of success and in terms of reduction of game flexibility.
4) Server Attack Cheating: In some rare cases a hacker
can gain direct access to the server of a game if it is not well
protected.
One possibility is a direct attack. Although rare, in some
cases it is possible for a cheater to gain access to the server
by exploiting a security weakness on the target machine.
Another, more common possibility, happens when the
cheater has direct physical access to the server - for example
28
4~
if he is working for the company that makes the game.
If this happens the cheater can not only gain an advantage,
but basically decide everything in the game. In games with
a client-server architecture the hacker can directly change the
game state to do whatever he wants. Even in very decentralized
peer-to-peer games where the current game state is held mostly
at the clients, the cheater can still change the game state
because the server always has the authoritative say.
Server attacks can be prevented through good server security
design. If there are no major security flaws in the server then
an outside attacker will not be able to gain unrestricted access.
Good company policies against inside cheating can prevent
server attacks on the internal level as well.
With peer-to-peer approaches this problem becomes even
less dangerous, because most of the work is outsourced to the
clients. The server itself has less functionality and is therefore
less bug-prone because of the lower code complexity.
5) Client Attack Cheating: A cheater can directly attack
another player’s computer in order to gain advantage in the
game.
Although rare, sometimes a hacker can use vulnerabilities
on a target client machine to gain access to it. In most of the
cases the hacker uses a trojan horse or a worm in order to
control other people’s computers. With this access the cheater
has complete control over the other player and can easily beat
him in the game.
Another possibility is to attempt a Denial of Service attack.
This is especially dangerous in peer-to-peer oriented architectures. The cheater can flood the enemy player with packets,
thus slowing down his connection. This way the cheater gains
an advantage because he can stop the enemy player in key
moments or at least slow down his reactions because of the
slower connection.
A special case of client attacking is the use of social engineering methods to obtain certain information about another
player. (or to achieve a certain goal). For example the cheater
can ask a victim to see one of his items and then after that not
return it. Or in some extreme cases even obtain the victim’s
login and password by sending an e-mail pretending to work
at the company that created the game.
In the normal client-server architecture this is not a big
problem, because most clients are secure enough for these
types of attacks. The cheater doesn’t have direct access to
the target computer and unless the target has been somehow
infected with malicious software, the chances of attack success
are relatively small.
This problem however becomes a lot more complicated with
peer-to-peer MMOGs. This approach introduces the possibility of responsible and monitoring nodes sending misleading
packets to each other, to other clients or to the server.
There isn’t much to be done about the special case of social
engineering cheating attempts. The risk can be reduced by
warning all players about that possibility. However in the end
human error is always a factor, so a complete prevention of
social engineering attacks is not plausible.
6) Game Architecture Exploitation: In some games a
cheater can exploit general problems with the implementation
of a game. A player can use (known or unknown to the
developer) game features to gain an advantage over the rest
of the players.
For example, if there is a bug in a certain game that allows
the player to become immortal in very specific circumstances,
then a cheater can exploit that bug and gain unintended by the
developers advantage against the other players.
Some of those game architecture exploitation cheats are not
even bugs, but actually exist because of bad game design.
For example the ranking system of some multiplayer games
is calculated according to number of victories only. Two
cheaters can then collaborate to cheat the system by starting
and immediately ending hundreds of games. By taking turns
they can both record hundreds of victory points and thus go to
the top of the ranking lists without playing a single game. That
way the cheater is not exploiting a bug in the program, but is
taking an advantage of the badly designed ranking system.
This type of cheating can be circumvent by better software
quality control. Better project management and more testing
can reduce the chances of bugs in the game. Better game
design can prevent unintended abuse of the available game
features.
B. Cheating in P2P based MMOGs
It is a lot more complicated to prevent cheating that stems
directly from the use of a peer-to-peer game architecture. The
main problem is that with this approach the server loses most
of the information about the moves of the players. Even if the
server makes extensive checking of the validity of a certain
move, cheating is still possible because the server trusts the
information coming from a certain responsible node. This
information can contain a valid move but that doesn’t make
sure that this was the actual move the player made.
In this Subsection of the paper we review detection and
prevention strategies and discuss their limitations in terms of
success and performance.
1) Timing Cheating: In a MMOGs with a peer-to-peer
architecture most of the information transfer happens directly
between the players. However there is always a time delay
between the actions of the different players. Thus a cheater
can try to exploit the delay in order to gain an unfair advantage
against the others.
The most famous example of timing exploitation is the
Look-Ahead cheating. A cheater can try to delay his actions
until he knows what his opponents are going to play. Thus the
attacker can decide his next move by using this information
and thus gain an unfair advantage against the rest of the
players.
To prevent Look-Ahead cheating the Lock-Step protocol can
be implemented. The way this protocol works is to require
from all players to send only the hash of the move they
are going to make. The responsible node does this as well.
In the end of the timeslot the actual moves are sent and
the hash-codes are recalculated and compared. That way the
responsible node knows only the hashes of the other player’s
moves when generating its own hash. When the actual moves
become known to the responsible node it is too late for it to
change its move, because the hash was already generated and
29
~
5
sent. The use of monitoring nodes can prevent the responsible
node from completely dropping certain packets.
2) Authority Exploitation: In most peer-to-peer games a
certain number of nodes have more responsibility than the
others. Those responsible nodes usually take care of a number
of child nodes by coordinating them. If a responsible node is
a cheater he can try to exploit this authority he has over all
child nodes.
For example, the cheater can delay or completely drop
certain packets received from a child node. On the other hand
it is possible to fabricate completely certain information in
order to lie to the rest of the nodes about what a certain victim
player did.
In most cases those responsible nodes need to report to
the server about the game state. A cheater can exploit this
authority in order to lie to the server about what somebody’s
actions were.
To prevent authority exploitation, we can use a certain
number of nodes, which check whether a responsible node is
attempting to cheat or not. These nodes (also called monitoring
nodes) can either be chosen from the rest of the responsible
nodes, or more common directly from the normal players.
The player attempting to make a move sends the information
both to his responsible node and to the monitoring nodes
assigned to it. That way if the responsible node attempts to
modify, delay or completely drop certain packets, the rest of
the monitoring nodes can detect and prevent that by making a
majority vote and executing the action regardless of what the
responsible node did.
However this approach introduces traffic overhead for all
players and especially for the monitoring nodes. Big computation overhead is also possible if the monitoring nodes need
to check the validity of the move.
3) Lack of Central Control Exploitation: Even if the cheater
is not a responsible node but a regular node instead, he can
still attempt to exploit the decentralization of the game state
management.
For example, the cheater can try making an illegal move. On
normal client-server architectures the validity of the move can
be calculated on the server. In a peer-to-peer system however
the resources on the responsible node are somewhat limited,
so a complete calculation of the possibility of each move for
every child node becomes implausible. This becomes even
more problematic if there are also monitoring nodes involved,
because each of them need to calculate the validity as well.
To fight against this kind of cheating we need to make sure
that the moves attempted by all players are actually valid. This
can be done on the server, however by doing that we lose the
scalability advantage that a peer-to-peer system offers.
A possible way to deal with this problem is to only log all
the moves and make those checks later when the load on the
server is smaller. If cheating is detected then the server can
roll-back to the last secure point of the game. This solution
however introduces a delay between the cheating attempt and
the checking and thus the rolling back can be frustrating to
players that didn’t cheat but needed to lose hours of play
anyway because of somebody else.
A better possibility is to make those checks at the responsible (and the monitoring) nodes. Although this introduces a
significant performance overhead for those nodes that make
the validity checking, this solution is still a lot more scalable
than using a big server.
A middle-ground solution is also possible, where only the
responsible node calculates the validity of the move. The
server then checks a random limited number of the moves
to make sure that the responsible node is not lying. Although
this solution has limited ability to prevent cheating it is a good
trade-off between cheating prevention and performance.
4) Collusion Cheating: A few cheaters can collaborate to
exploit a security weakness, which is only possible when the
cheater is not acting alone.
Most peer-to-peer architectures depend on some kind of
monitoring nodes, which make sure that neither the responsible
node, nor the player himself is falsifying information. They
can then take a vote in order to make sure that cheating
attempts are prevented.
However if enough monitoring nodes are actually on the
cheater side then they can win the majority vote and thus go
around the cheating prevention system.
Collusion cheating can never be completely prevented without complete checks by the server, which would make the use
of peer-to-peer architecture meaningless.
However the chances of collusion cheating success can be
reduced with good game architecture design. For example
if the monitoring nodes are chosen randomly (instead of
choosing only people located in the surrounding area) it will
be a lot harder for the cheaters to succeed having the majority
of the monitoring nodes.
Increased number of monitoring nodes makes collusion
cheating even less probable, although it introduces considerate
overhead both for the monitoring nodes and for the normal
players.
In addition if the monitoring nodes are changed frequently
we can make sure that even if the cheaters have the luck to
gain the majority vote, that they will not have the control for
a long period of time.
Crosschecking between the different groups of monitoring
nodes can also detect cheating attempts, though it introduces
significant overhead as well.
V. R ELATED W ORK
The paper "A Systematic Classification of Cheating in
Online Games" by Jeff Yann and Brian Randell offers a
classification of the different cheating approaches that bares
similarities to the ones presented in this paper. The authors
classify all cheating attempts in multiplayer games into fifteen
categories and review each of them. Although the paper
doesn’t concentrate exactly on peer-to-peer architecture approaches, the information presented there is useful to better
understand the different types of cheats we see in online
games.
Takoto Izaiku and his team concentrate more on cheat
prevention in peer-to-peer games in the paper "Cheat Detection
for MMORPG on P2P Environments" that stem directly from
30
6~
the decentralization of the system. In the paper the authors
propose a method for cheat detection and prevention in Massive Online RPG games that uses strategies similar to the ones
proposed in this paper.
In the paper "Server-side Verification of Client Behavior in
Online Games" the author Darrell Bethea and his colleagues
propose a method for validity checking in normal server-client
frameworks. Although the work doesn’t concentrate on the
peer-to-peer approach, the paper proposes a good system for
validity checking that can be restructured to work with some
peer-to-peer MMOGs.
VI. C ONCLUSION
Although the prevention of cheating in the peer-to-peer
architecture approach to the development of MMOGs is a lot
more complicated than in the normal client-server approaches,
it still provides the traffic scalability needed for the huge
number of people playing the game simultaneously.
As discussed in the paper most of the problems that arise
from the decentralization of the system are quite manageable.
Although there probably are more undiscovered ways to attack
this kind of systems, most of the cheaters don’t have the
expertise to attempt something that complicated. On the other
hand there is also a number of administrators that watch for
anomalies in the game state, so a person suddenly gaining
enormous amounts of something valuable can easily be spotted
and stopped. This, together with the ease with which the
game can be rolled-back to a previous stable state, makes the
problem manageable. Thus at the moment the advantages of
using a peer-to-peer architecture outweigh the potential risks
of revenue losses due to cheating.
However, this kind of games are becoming more and more
popular and the number of people playing is increasing. Thus
in the future we will also see an increase in the number
of cheating attempts and the complexity of the cheating
approaches. The increase of the number of people playing will
also make it harder for the administrators to manually detect
cheating attempts. However this increase in player numbers
will also make the peer-to-peer approaches even more valuable
because of the scalability issues with the normal client-server
architectures.
Because of the importance of cheating prevention more
work in this field will be needed in order to ensure the fair
gameplay in the future.
R EFERENCES
[1] Takato Izaiku and Shinya Yamamoto and Yoshihiro Murata and Naoki
Shibata and Keiichi Yasumoto and Minoru Ito. Cheat detection for
MMORPG on P2P Environments. ACM Workshop on Network and
System Support for Games, 2005.
[2] Jeff Yan and Brian Randell A Systematic Classification of Cheating in
Online Games. ACM Workshop on Network and System Support for
Games, 2005.
[3] Darrell Bethea and Robert Cochran and Michael Reiter Server-side
Verification of Client Behavior in Online Games. University of North
Carolina at Chapel Hill, 2010.
[4] Patric Kabus and Wesley W. Terpstra and Mariano Cilia and Alejandro
P . Buchmann Addressing Cheating in Distributed MMOGs. Darmstadt
University of Technology, Germany, 2005.
31
~
1
P2P-BASED VIDEO-ON-DEMAND-STREAMING
P2P-Based Video-on-Demand-Streaming
Pablo Hoch
Video bereits während des Downloads abzuspielen. Außerdem
ist Video-Streaming besonders anfällig gegenüber Churn, also
dem Umstand, dass sich Peers immer nur eine gewisse Zeit
in dem Netzwerk aufhalten und sich dadurch die Netzwerkstruktur häufig ändert. Hierbei besteht die Gefahr, dass ein
Peer nicht mehr ausreichend Daten zum unterbrechungsfreien
Abspielen des Videos erhält.
Im Vergleich zu Live-Video-Streaming schauen zudem nicht
alle Benutzer gleichzeitig die selbe Stelle des Videos, weshalb
auch die dafür entwickelten Verfahren nicht direkt übernommen werden können. Außerdem will man oft das Springen
zu einer anderen Stelle im Video, insbesondere Vorspulen,
ermöglichen.
Dieses Paper gibt einen Überblick über verschiedene
Systeme, die Peer-to-Peer-Netzwerke für Video-on-DemandStreaming einsetzen. Der weitere Aufbau ist dabei wie folgt:
In Abschnitt II werden einige benötigte Hintergrundbegriffe
kurz erklärt, in Abschnitt III wird eine Klassifikation für die
verfügbaren Systeme vorgestellt und in Abschnitt IV werden
verschiedene Vertreter der jeweiligen Klassen betrachtet. Abschnitt V bietet neben einer Zusammenfassung ebenfalls einen
Ausblick in die aktuelle Forschung im Bereich P2P-basierter
Video-on-Demand-Systeme.
Zusammenfassung—Video-on-Demand-Streaming hat sich zu
einem der wichtigsten Angebote im Internet entwickelt. Durch
die enorme Popularität von Video-Plattformen wie YouTube und
die ständig wachsende Menge an Videos, ergeben sich hohe
Server- und Traffic-Kosten für die Betreiber solcher Angebote.
Mit dem Einsatz von Peer-to-Peer-Technologien können diese
massiv reduziert werden. Dabei sind besondere Anforderungen
wie eine Wiedergabe der Videos mit möglichst geringer Wartezeit
und ohne Unterbrechungen zu beachten. Dieses Paper gibt einen
Überblick über verschiedene Peer-to-Peer-Systeme für Videoon-Demand-Streaming. Dazu werden die Ansätze anhand der
Struktur des verwendeten Overlay-Netzwerks in zwei Klassen
unterteilt und jeweils mehrere Systeme vorgestellt.
I. E INLEITUNG
Video-on-Demand, also die Möglichkeit, Videos nach Bedarf und zu beliebigen Zeiten anzuschauen, hat in den letzten
Jahren große Popularität erlangt. So verzeichnet beispielsweise
alleine die Video-Plattform YouTube1 täglich zwei Milliarden
Videoanfragen sowie hunderttausende neue Videos2 .
Klassische Video-on-Demand-Angebote wie YouTube verwenden eine Client-Server-Architektur mit großen ContentDelivery-Networks. Durch die enorme Popularität entsteht
dadurch ein hohes Trafficaufkommen für die Betreiber. Dies
legt den Einsatz von Peer-to-Peer-Technologie (P2P) nahe, um
einen Teil der Last auf die Benutzer zu verlagern und damit
die Belastung der Streaming-Server zu verringern sowie die
Kosten zu senken.
Eine Untersuchung von YouTube [3] ergab, dass für den
Betreiber nur bei einem kleinen Teil der Videos durch den
Einsatz von P2P-Technologie Einsparungen erzielt werden
können. Dies liegt daran, dass ein Großteil der Videos zu selten
aufgerufen wird und diese Videos daher nicht von genügend
Benutzern über ein P2P-Netzwerk ausgetauscht werden. Insgesamt wird in der Studie jedoch eine mögliche Serverentlastung
von 41% berechnet, wenn die Benutzer sich lediglich während
der Wiedergabe des Videos in dem P2P-Netzwerk aufhalten,
und sogar eine Entlastung von über 98%, wenn Benutzer die
Videos einen Tag lang über das P2P-Netzwerk freigeben.
Jedoch kann für Video-on-Demand-Streaming nicht einfach
übliche P2P-File-Sharing-Technologie wie BitTorrent [5] eingesetzt werden, da Video-Streaming spezielle Anforderungen
stellt. So möchte man eine möglichst kurze Startverzögerung
erreichen und das Video anschließend möglichst ohne Unterbrechungen anschauen können. Traditionelle File-SharingProtokolle sind darauf ausgelegt, die Datei möglichst schnell
herunterzuladen. Dazu wird die Datei üblicherweise in kleine
Teilstücke unterteilt, die dann in beliebiger Reihenfolge empfangen werden. Dieses Vorgehen ist nicht geeignet, um das
II. H INTERGRUND
A. Application Layer Multicast
Multicast bezeichnet das Senden einer Nachricht an mehrere
Empfänger. Bei der Implementierung auf Anwendungsebene
gibt es einen Sender, der die Nachricht an einen Teil der
Empfänger sendet. Bei dem Sender handelt es sich dabei
um einen Streaming-Server, die Empfänger sind die Peers im
P2P-Netzwerk. Diese Peers leiten die Nachricht wiederum an
andere Peers weiter usw., bis die Nachricht alle Empfänger
erreicht hat. Dadurch entsteht ein Baum wie in Abbildung 1.
Man spricht deshalb von Application Layer Multicast Trees.
Abbildung 1.
1 http://www.youtube.com/
2 http://www.youtube.com/t/fact_sheet
(Zugriff am 29.12.2010)
32
Beispiel eines Application Layer Multicast Tree
2~
B. BitTorrent
Systemen in Abschnitt IV erklärt werden. Die Wurzel eines
solchen Baums bildet jeweils ein Streaming-Server, der das
komplette Video verfügbar hat. Diese Systeme verwenden
in der Regel push-basierte Kommunikation, d.h. der VideoStream wird ohne explizite Anfragen nach einzelnen Teilen
im Baum weitergeleitet.
Zu den speziellen Herausforderungen bei diesen Systemen
zählen u.a. die hohe Anfälligkeit gegenüber Churn, da beim
Verlassen eines Knotens – absichtlich oder durch Ausfall –
alle seine Nachfolger den Stream nicht mehr erhalten, sowie
die Behandlung von großen Unterschieden in der Uploadund Download-Bandbreite der Peers. Als ein möglicher Lösungsansatz des zweiten Problems wird z.B. Scalable Video
Coding [15] eingesetzt. Das Video wird dabei in mehrere
Streams aufgeteilt – der Basisstream enthält eine Version des
Videos in niedriger Qualität oder Auflösung, empfängt man
zusätzlich die weiteren Streams, ergibt sich eine Version in
höherer Qualität. Ähnlich ist Multiple Description Coding [1],
[9]. Dort wird das Video ebenfalls in mehrere Substreams,
sogenannte Deskriptoren, aufgeteilt. Zum Abspielen genügt
hier ein beliebiger Deskriptor und je mehr Deskriptoren man
empfängt, desto besser ist die Qualität des Videos. So kann
man beispielsweise für jeden Stream einen eigenen Baum
aufbauen und Peers können je nach verfügbaren Ressourcen
einen oder mehreren der Streams empfangen und weiterleiten.
Außerdem ist Multiple Description Coding beim Verlassen
des Elternknotens in einem der Bäume hilfreich, da dann
zumindest noch eine Version in niedrigerer Qualität verfügbar
ist.
Eines der bekanntesten und erfolgreichsten P2P-FileSharing-Systeme ist BitTorrent [5]. Dateien werden dort in
kleine Teile, auch Pieces oder Chunks genannt, aufgeteilt. Für
jede Datei, die über BitTorrent verteilt wird, wird ein eigenes
Netzwerk aufgebaut. Dazu gibt es zentrale Tracker-Server, die
eine Liste von Peers in dem Netzwerk verwalten. Peers verbinden sich mit einem Tracker-Server, um eine Liste von anderen
Peers zu bekommen, die ebenfalls die Datei herunterladen
oder bereits heruntergeladen haben und diese bereitstellen.
Einen großen Anteil an dem Erfolg von BitTorrent haben die
verwendeten Auswahl-Algorithmen, die festlegen, in welcher
Reihenfolge die Teile heruntergeladen werden und an welche
anderen Peers Daten hochgeladen werden.
Zur Auswahl der Reihenfolge für den Download der Teile
(Piece Selection) wird hauptsächlich die Rarest-First Strategie
verwendet. Dabei werden immer diese Teile zuerst angefragt,
die die wenigsten der anderen bekannten Peers besitzen. Dies
ist zum einen hilfreich, da dann die seltensten Teile bereits
heruntergeladen sind, falls andere Peers, die diese Teile anbieten, das Netzwerk verlassen. Andererseits erhöht sich dadurch
die Wahrscheinlichkeit, dass andere Peers diese Teile anfragen
und dadurch mit diesen Daten ausgetauscht werden können.
Um zu entscheiden, an welche anderen Peers Daten hochgeladen werden, verwendet BitTorrent einen sogenannten Unchoking-Algorithmus. Zunächst werden alle Peers choked, d.h.
keine Teile an sie gesendet. In bestimmten Intervallen wird
dann die Download-Geschwindigkeit des letzten Intervalls von
allen Peers überprüft, und die Peers, von denen die besten
Downloadraten erreicht wurden, unchoked, d.h. angefragte
Teile werden an diese Peers gesendet. Damit wird versucht,
Free-Riding, also das Downloaden von Daten ohne auch eine
gewisse Menge von Daten an andere Peers hochzuladen, zu
verhindern. Zusätzlich wird immer ein zufälliger Peer unchoked, um auch anderen Peers, von denen momentan nichts
heruntergeladen wird, eine Chance zu geben. Dies wird als
Optimistic Unchoke bezeichnet.
B. Mesh-basierte Systeme
Die zweite große Klasse bilden die Mesh-basierten Systeme.
Hier wird beim Betreten des Netzwerks keine feste Struktur
erzwungen – jeder Peer baut Verbindungen zu anderen Peers
auf und tauscht mit diesen Daten aus. Auch wird das Video
hier nicht entlang fester Kanten gestreamt, sondern in kleine
Teile aufgeteilt, die dann i.d.R. von verschiedenen Peers
angefragt werden. Hierbei handelt es sich um pull-basierte
Kommunikation, da jedes einzelne Teil des Videos explizit von
einem Peer angefordert wird und erst auf Anfrage zurückgesendet wird. Dieser Ansatz ähnelt etwa dem bei BitTorrent
verwendeten, weshalb auch viele Mesh-basierte Systeme auf
BitTorrent [5] aufbauen und das Protokoll für die speziellen
Video-on-Demand-Anforderungen verändern und erweitern.
Die Systeme unterscheiden sich hauptsächlich in der Piece
Selection, also der Auswahl, in welcher Reihenfolge die Teile
des Videos heruntergeladen werden, sowie darin, mit welchen
Peers Daten ausgetauscht werden.
III. K LASSIFIKATION
Die verschiedenen P2P-basierten Systeme zum Video-onDemand-Streaming lassen sich anhand des verwendeten Overlays grob in zwei Klassen unterteilen: Systeme, die Application Layer Multicast Trees aufbauen und Mesh-basierte
Systeme, die keine explizit festgelegte Topologie besitzen.
A. Application Layer Multicast Trees
Bei den Systemen, die Application Layer Multicast Trees
einsetzen, werden Bäume aufgebaut, bei denen das Video
entlang der Kanten von der Wurzel bis zu den Blättern
gestreamt wird. Dieser Ansatz wird u.a. auch für das LiveStreaming von Videos verwendet. Im Gegensatz zum LiveStreaming möchte man bei Video-on-Demand jedoch üblicherweise das komplette Video von Anfang an sehen, weshalb
zusätzliche Techniken nötig sind, um den Teil des Videos
vom Anfang bis zu der Abspielposition, an der sich der
Elternknoten gerade befindet, ebenfalls zu erhalten. Dafür
gibt es verschiedene Verfahren, die bei den entsprechenden
C. Vergleich der Ansätze
In [12] wird die Performance der beiden Ansätze des Treebasierten und Mesh-basierten Streamings verglichen. In beiden
Fällen wird dabei Multiple-Description-Coding verwendet.
Die Untersuchung kommt zu dem Fazit, dass Mesh-basierte
Systeme eine bessere Performance liefern. Die Hauptgründe
dafür sind, dass Auswirkungen von Peers mit niedriger oder
schwankender Bandbreite bei den Mesh-basierten Systemen
33
~
3
minimiert werden können, sowie die höhere Anfälligkeit von
Tree-basierten Systemen gegenüber Churn. Bei den Treebasierten Systemen ist in solchen Fällen immer ein ganzer
Teilbaum betroffen.
IV. S YSTEME
In diesem Abschnitt werden einige Systeme der beiden
Klassen vorgestellt und auf die Besonderheiten der einzelnen
Systeme im Vergleich zu den anderen Systemen eingegangen.
A. Application Layer Multicast Trees
Diese Systeme unterscheiden sich hauptsächlich bei den
verwendeten Algorithmen zum Aufbau der Bäume, bei der
Vorgehensweise zum Weiterleiten des Video-Anfangs, sowie
der Fehlerbehandlung.
1) P2Cast: P2Cast [10] baut einen Application Layer Multicast Tree auf, um das Video zu streamen. Dazu existiert ein
zentraler Server, der sowohl für den Aufbau der Topologie als
auch für das Streamen des Videos an einige Peers zuständig
ist. Die Peers werden dabei entsprechend ihrer Ankunftszeit in
Sessions gruppiert. Der erste Peer erzeugt eine neue Session,
weitere Peers, die innerhalb eines gewissen Zeitfensters nach
dem ersten Peer das Video aufrufen, treten der bestehenden
Session bei. Für Peers, die außerhalb des Zeitfensters der
letzten Session ankommen, wird wiederum eine neue Session angelegt. Innerhalb einer jeden Session bilden die Peers
zusammen mit dem Streaming-Server einen Multicast-Baum.
Peers einer Session sind dabei komplett unabhängig von denen
anderer Sessions. Der Server streamt das komplette Video
jeweils an den ersten Peer jeder Session, die Peers leiten
den Stream jeweils an ihre Kinder im Baum weiter. Dabei
handelt es sich um den Base-Stream. Zusätzlich müssen Peers,
die der Session erst später beigetreten sind, den Anfang des
Videos erhalten, da sie über den Base-Stream nur das Video
ab der aktuellen Abspielposition ihres Elternknotens im Baum
erhalten. Hierzu wählt ein Peer beim Betreten des Netzwerks
einen Patch-Server aus. Dabei handelt es sich entweder um den
Streaming-Server oder einen Peer aus der gleichen Session.
Von diesem Patch-Server erhält der Peer dann zusätzlich einen
Patch-Stream, der den Anfang des Videos, den der Peer im
Base-Stream verpasst hat, enthält. Nachdem der Peer den
Patch-Stream vollständig empfangen hat, wird nur noch der
Base-Stream benötigt. Um diesen Patch-Stream anbieten zu
können, muss jeder Peer den Anfang des Videos cachen.
Ein Beispiel eines P2Cast-Netzwerks mit zwei Sessions zeigt
Abbildung 2.
Zum Aufbau des Multicast-Trees verwendet P2Cast den
Best Fit (BF) Algorithmus. Dieser beruht auf einer Messung
der erreichbaren Bandbreite zwischen den Peers. Im Folgenden
wird der Fall betrachtet, dass der Peer einer bestehenden Session beitritt. Andernfalls wird eine neue Session angelegt, die
nur aus dem Server und dem neuen Peer besteht. So kontaktiert
ein neuer Peer zunächst den Server. Dieser misst dann die
Bandbreite zum Peer und fordert gleichzeitig seine Kinder
auf, ebenfalls deren Bandbreite zu dem neuen Peer zu messen.
Wenn ein Kindknoten die schnellste Anbindung zu dem neuen
Peer hat, wird er an diesen weitergeleitet und der Prozess dort
Abbildung 2. Beispiel eines P2Cast-Baums mit 2 Sessions zum Zeitpunkt
18. In den Kreisen ist jeweils die Ankunftzeit des Peers angegeben. Alle
Peers in Session 1 haben den Patch-Stream bereits vollständig empfangen
und benötigen nur noch den Base-Stream. In der 2. Session empfangen noch
3 Peers einen Patch-Stream.
rekursiv fortgesetzt. Wenn der aktuell angefragte Knoten – zu
Beginn also der Server – die schnellste Verbindung zu dem
Peer hat, betritt der neue Peer an dieser Stelle als Kind dieses
Knotens den Baum. Der gleiche Algorithmus wird sowohl zur
Auswahl eines Elternknotens für den Base- als auch für den
Patch-Stream verwendet. In dem Standardalgorithmus wird
bei mehreren Peers mit gleicher Bandbreite zufällig einer
ausgewählt. Zusätzlich werden Varianten vorgeschlagen, die
in diesem Fall den Peer mit der niedrigsten Latenz auswählen
(BF-delay), sowie einen Algorithmus, der keine aufwändigen
Bandbreitenmessungen durchführt, sondern lediglich beachtet,
ob ein Peer noch genügend Uploadkapazität für einen weiteren
Stream zur Verfügung hat und dann ebenfalls nach Latenz
einen Peer auswählt (BF-delay-approx). Dieser letzte Algorithmus hat somit einen deutlich niedrigeren Overhead als BF. In
allen Fällen kann es vorkommen, dass weder der Server, noch
einer der Peers genügend freie Bandbreite für einen weiteren
Peer zur Verfügung haben und der Peer deshalb abgelehnt
wird.
Sobald ein Peer dem Netzwerk beigetreten ist, muss sichergestellt werden, dass dieser den Base-Stream und, falls
nötig, den Patch-Stream mit einer ausreichenden Downloadrate erhält. Dies wird von den Peers ständig überwacht.
Sollte die Geschwindigkeit nicht mehr ausreichen, oder die
Verbindung abbrechen, wird ein Recovery-Prozess gestartet.
Dieser wird immer von dem Wurzelknoten des betroffenen
Teilbaums durchgeführt. Dazu versucht der Peer, dem Netzwerk neu beizutreten. Hierfür wird der gleiche Algorithmus
wie beim ursprünglichen Betreten des Netzwerks verwendet.
Zu beachten ist, dass nur solche Peers als Patch-Server in
Frage kommen, die der Session vor dem anfragenden Peer
beigetreten sind. Sofern dies gelingt, ist der gesamte Teilbaum
wieder ein Teil des Netzwerks. Sollte der Wurzelknoten des
abgetrennten Teilbaums dem Netzwerk nicht wieder beitreten
können, versuchen dies anschließend dessen Kinder.
2) P2VoD: P2VoD [7] benutzt ebenfalls Application Layer
Multicast Trees zum Streamen des Videos, unterscheidet sich
34
4~
erste Generation der Session. Da Peer C3 dem Netzwerk erst
zum Zeitpunkt 2 beigetreten ist, der erste Peer in der gleichen
Generation (C1 ) jedoch zum Zeitpunkt 0, ist der Cache von C3
um 2 R-Blöcke kleiner als der von C1 . Somit ist sichergestellt,
dass alle Peers einer Generation den gleichen ersten R-Block
im Cache haben. Würde zum Zeitpunkt 20 ein neuer Peer dem
System beitreten, würde eine neue Session angelegt, da in der
Session 1 kein Peer mehr den ersten Block des Videos im
Cache hat.
Falls beim Betreten des Systems durch einen neuen Peer
keine offene Session existiert, wird eine neue angelegt und das
Video direkt vom Server gestreamt. Andernfalls kontaktiert der
neue Peer einen Peer der jüngsten Generation einer offenen
Session. Von diesem bekommt er eine Liste von Peers der
nächstälteren Generation und wählt einen dieser Peers als
Elternknoten aus, falls möglich, d.h. falls dieser noch den
Anfang des Videos gecached hat. Andernfalls wird eine neue
Generation angelegt und einer der Peers aus der bis dahin
jüngsten Generation als Vater gewählt. Der Server streamt das
Video jeweils an die Peers der ersten Generation, diese leiten
es an die der zweiten Generation weiter usw.
Der Hauptgrund für die Verwendung von Generationen liegt
in der Fehlerbehandlung, die bei P2VoD im Gegensatz zu
P2Cast in der Regel ohne den zentralen Server durchgeführt
werden kann. Dazu werden bereits im Vorfeld zwischen den
Peers einer Generation Nachrichten ausgetauscht, um eine
Liste von anderen Peers in der gleichen Generation zu bekommen. Diese wird außerdem an die Kinder in der nächsten
Generation weitergeleitet. Im Falle dass der Stream zu einem
Peer abbricht, besitzt dieser dann eine Liste von anderen Peers
in der nächstälteren Generation. Wie bei P2Cast führt hier auch
wieder nur der Wurzelknoten des abgeschnittenen Teilbaums
die Recovery-Prozedur durch. Er kann jedoch nun direkt die
Peers aus der ihm bekannten Liste kontaktieren und versuchen,
dort dem System wieder beizutreten. Nur falls dies fehlschlägt,
muss der Server kontaktiert werden.
aber in einigen wesentlichen Punkten von P2Cast. So wird
bei P2VoD kein Patch-Stream für später ankommende Peers
benötigt. Um ohne diesen zusätzlichen Stream auszukommen,
cachen die Peers nicht den Anfang des Videos, sondern jeweils
die zuletzt empfangenen Daten. Somit kann ein Peer das komplette Video in einem Stream an einen später ankommenden
Peer weiterleiten, solange er zum Beitrittszeitpunkt des neuen
Peers noch den Beginn des Videos im Cache hat.
Das Video wird dazu in durchnummerierte Blöcke, sogenannte R-Blocks für retrieval blocks, unterteilt. Jeder Peer
hat einen Cache, der maximal eine bestimmte Anzahl Blöcke
aufnehmen kann. Um das Caching zu vereinfachen, enhält ein
R-Block immer die Videodaten für eine Zeiteinheit, z.B. für
eine Sekunde. Auch bei P2VoD gibt es Sessions: Wenn ein
Peer dem System beitreten will und keine sogenannte offene
Session, d.h. eine Session in der es Peers gibt, die noch den
ersten Block des Videos im Cache haben, mehr existiert, muss
eine neue Session erstellt werden. Neu ist die Gruppierung der
Peers innerhalb einer Session in Generationen. Dabei werden
die Peers anhand des R-Blocks mit der niedrigsten Nummer
in deren Cache in Generationen unterteilt. Zu beachten ist,
dass die Größe des Caches zwischen den Peers variiert. Der
erste Peer einer Generation benutzt immer die maximale Cachegröße, der Cache später ankommender Peers der gleichen
Generation ist jedoch kleiner, entsprechend der Differenz in
deren Ankunftszeiten.
B. Mesh-basierte Systeme
1) BASS (BitTorrent Assisted Streaming): Bei BASS [6]
handelt es sich um ein sehr einfaches System, das ein ClientServer-System zum Streamen des Videos durch einen parallelen Download von Teilen des Videos über BitTorrent ergänzt.
Wie bei BitTorrent üblich, wird das Video hierbei in kleine
Teile zerlegt. Die Clients verbinden sich mit einem StreamingServer, der dem Client zunächst die Teile des Videos von
Beginn an in Abspielreihenfolge sendet. Gleichzeitig wird
über einen Tracker-Server eine Verbindung zum BitTorrentNetzwerk aufgebaut und hierüber Teile des Videos ausgetauscht. BASS achtet dabei darauf, dass keine Teile doppelt, also vom Streaming-Server und zusätzlich über BitTorrent, heruntergeladen werden. Insbesondere werden von dem
Streaming-Server die Teile in Abspielreihenfolge heruntergeladen und dabei Teile, die bereits über BitTorrent empfangen
wurden, übersprungen. Weitere Veränderungen an BitTorrent
werden nicht vorgenommen. Es werden also die üblichen
Rarest-First-Piece-Selection sowie der Standard UnchokingAlgorithmus verwendet.
Abbildung 3. Beispiel einer P2VoD-Session zum Zeitpunkt 20. In den Peers
(Kreise) ist deren Ankunftszeit angegeben. Ein R-Block entspricht dabei einer
Zeiteinheit, d.h. Peer C3 ist z.B. dem Netzwerk beigetreten, als Peer C1
bereits zwei Blöcke empfangen hatte. Unter den Peers sind jeweils die Blöcke
angegeben, die sich zu diesem Zeitpunkt im Cache des Peers befinden.
In Abbildung 3 ist ein P2VoD-Netzwerk zum Zeitpunkt
20 gezeigt. Dort bilden die Peers C1 , C2 , C3 und C4 die
35
~
5
2) BiToS (BitTorrent Streaming): BiToS [16] ist ein weiteres BitTorrent-basiertes System. Im Gegensatz zu BASS ist
hierbei jedoch kein seperater Streaming-Server nötig. Stattdessen konzentriert sich BiToS auf eine Anpassung des PieceSelection-Algorithmus, um sowohl das Abspielen des Videos
während des Downloads zu ermöglichen, als auch gleichzeitig
immer noch eine gute Verteilung der einzelnen Teile des
Videos zu gewährleisten.
Die Grundidee hinter BiToS ist, Teile des Videos, die als
nächstes abgespielt werden sollen, bevorzugt herunterzuladen.
Dazu werden die Pieces, die noch heruntergeladen werden
müssen, in zwei Mengen aufgeteilt: Das High-Priority-Set
beinhaltet eine bestimmte Menge von Teilen, die direkt auf
die aktuelle Abspielposition folgen, aber noch nicht heruntergeladen wurden. Alle anderen, noch nicht empfangenen
Teile befinden sich im Remaining-Pieces-Set. Dabei gibt es
zwei veränderbare Parameter: die Größe des High-PrioritySets, sowie eine Wahrscheinlichkeit p, die bei der PieceSelection entscheidet, aus welcher Menge als nächstes ein
Teil heruntergeladen wird. Mit Wahrscheinlichkeit p wird ein
Teil aus dem High-Priority-Set heruntergeladen, mit Wahrscheinlichkeit 1 − p ein Teil aus dem Remaining-Pieces-Set.
Bei Simulationen hat sich ein Wert von p = 0.8 als gut
erwiesen [16]. Innerhalb des Sets wird dann ein Teil nach dem
Rarest-First-Prinzip ausgewählt – nur wenn es mehrere gleich
seltene Teile gibt, wird das mit der näheren Abspielposition
ausgewählt. Während die Größe des High-Priority-Sets bei
BiToS konstant ist (die Autoren haben durch Simulation einen
Wert von etwa 8% des Videos als optimal ermittelt), kann
die Wahrscheinlichkeit p auch zur Laufzeit angepasst werden.
Dies kann beispielsweise durchgeführt werden, wenn ein Teil,
der abgespielt werden soll, noch nicht heruntergeladen wurde.
Falls zu diesem Zeitpunkt bereits viele andere noch nicht
abgespielte Teile bereits heruntergeladen wurden, wird die
Wahrscheinlichkeit erhöht, um bevorzugt Teile aus dem HighPriority-Set anzufragen. Sind hingegen keine weiteren solche
Teile vorhanden, wird die Wahrscheinlichkeit heruntergesetzt,
um mehr zufällige Teile zu erhalten und somit attraktiver für
andere Peers zu werden.
3) Toward Efficient On-Demand Streaming with BitTorrent: In [2] wird ebenfalls eine Erweiterung des BitTorrentProtokolls für Video-on-Demand-Streaming vorgeschlagen.
Ähnlich wie bei BiToS wird der Piece-Selection-Algorithmus
ausgetauscht und die noch fehlenden Teile des Videos in zwei
Mengen aufgeteilt. Neu ist, dass hierbei die Größe des Fensters
(entspricht dem High-Priority-Set bei BiToS) zur Laufzeit
angepasst wird. So wird das Fenster vergrößert, wenn bereits
viele der als nächstes abzuspielenden Teile heruntergeladen
wurden, und verkleinert, wenn davon nur sehr wenige vorhanden sind. Dadurch, dass die Menge vergrößert wird, erhöht
sich die Verteilung der Pieces (Piece Diversity). Durch das
Verkleinern wird sichergestellt, dass die in Kürze benötigten
Teile möglichst schnell heruntergeladen werden.
Als weitere Verbesserung wird innerhalb des Fensters nicht
Rarest-First als Piece Selection verwendet, sondern eine sogenannte Portion-Policy, bei der mit einer gewissen Wahrscheinlichkeit Rarest-First und ansonsten In-Order Selection, d.h.
Download der Teile in Abspielreihenfolge, verwendet wird.
Untersucht wurde hier auch der Einfluss von Peers, deren
Uploadrate geringer als die Abspielrate des Videos ist. Dabei ergeben sich für die Peers mit ausreichender Uploadrate
kaum Nachteile, selbst wenn 30% der Peers keine ausreichende Uploadbandbreite zur Verfügung stellen – nur etwa
2-3% der Daten sind nicht rechtzeitig zum Abspielzeitpunkt
angekommen. Außerdem wurden Peers, die keinerlei Daten
hochladen, simuliert. Wie erwartet, erreichen diese nur geringe
Downloadraten, während die sich normal verhaltenden Peers
kaum beeinträchtigt werden.
4) Tribler: Bei Tribler [14] handelt es sich um ein P2PFile-Sharing-System, das auf BitTorrent aufbaut und dieses
um diverse Funktionen erweitert. Der Fokus liegt dabei auf
dem Aufbau eines sozialen Netzwerks, was sowohl das Finden
von Dateien vereinfachen, als auch die Downloadraten erhöhen
soll. Im Gegensatz zu vielen der anderen Systeme, die davon
ausgehen, dass ein Benutzer nur während der Wiedergabe des
Videos ein Teil des P2P-Netzwerks ist, ist Tribler mehr darauf
ausgelegt, dass Teilnehmer über einen längeren Zeitraum online sind. Die Peers werden anhand ihrer Interessen in Gruppen
eingeteilt, daraus ergeben sich die sogenannten Taste-Buddies.
Für das Streaming von Videos bietet Tribler zwei wesentliche
Neuerungen: Zum einen Collaborative-Downloading mit dem
2Fast-Protokoll, bei dem befreundete Peers bei dem Download
von Dateien helfen, und das Give-to-Get-Protokoll, welches
durch Überwachung der Peers versucht, Free-Riding zu verhindern und außerdem einige speziell auf Video-Streaming zugeschnittene Anpassungen enthält. Diese beiden Neuerungen
werden in den folgenden Abschnitten beschrieben.
5) 2Fast: Die Idee hinter 2Fast [8] ist, dass ein Peer,
Collector genannt, von befreundeten Peers, Helpers genannt,
Unterstützung beim Download einer Datei anfordert. Die
Helpers laden dann ebenfalls Teile der Datei herunter und
senden diese an den Collector. Sowohl der Collector als auch
die Helper laden die Datei normal über BitTorrent herunter.
Bevor jedoch ein Helper einen Teil der Datei herunterlädt,
fragt er beim Collector nach, ob dieser Teil noch benötigt
wird, d.h. noch nicht heruntergeladen wurde und kein anderer
Helper diesen Teil gerade herunterlädt. Anschließend sendet
der Helper den heruntergeladenen Teil an den Collector, ohne
eine Gegenleistung zu erwarten.
Mit 2Fast kann die Downloadgeschwindigkeit von Peers mit
asymmetrischen Internetanbindungen, d.h. solchen, bei denen
die verfügbare Upload-Bandbreite geringer als die DownloadBandbreite ist, gesteigert werden. In einem Test mit verschiedenen ADSL-Anschlüssen konnte damit eine Steigerung
der Downloadgeschwindigkeit um bis zu Faktor 2-6 erreicht
werden.
6) Give-to-Get: In Tribler wird außerdem Give-to-Get [13]
verwendet, um Free-Riding zu minimieren. Die Grundidee
dabei ist, dass Teile des Videos bevorzugt an solche Peers
hochgeladen werden, die diese Teile wiederum an andere Peers
weiterleiten. Free-Rider, also solche Peers, die keine oder
nur sehr wenige Daten an andere Peers senden, bekommen
dadurch nur dann eine akzeptable Downloadrate, wenn genügend Uploadkapazität im Netzwerk vorhanden ist. Der Vorteil
bezüglich Video-Streaming gegenüber dem standardmäßigen
BitTorrent-Unchoking-Algorithmus ist, dass nun Teile nicht
36
6~
dem Low-Priority-Set. Innerhalb des Mid- und Low-PrioritySets werden die Pieces wie bei BiToS nach dem Rarest-First
Prinzip ausgewählt, in dem High-Priority Set jedoch In-Order.
Eine Ausnahme davon ist die Prebuffering-Zeit: Bevor mit
dem Abspielen des Videos begonnen wird, werden zunächst
alle Pieces in dem anfänglichen High-Priority-Set in RarestFirst Reihenfolge heruntergeladen. Anhand der bisherigen
Downloadgeschwindigkeit wird dann die voraussichtlich verbleibende Downloadzeit ausgerechnet und mit der Wiedergabe
begonnen, sobald diese unter der Dauer des Videos liegt.
7) RINDY: Bei RINDY [4] liegt der Fokus auf effizienter Unterstützung von Änderungen der Abspielposition durch
Springen innerhalb des Videos. Hierzu besitzt jeder Peer eine
Liste von Peers mit weiter entfernter Abspielposition. Für
den Beitritt zum Netzwerk gibt es einen Tracker-Server, der
jedem Peer neben einer Liste von anderen Peers ebenfalls
einen von mehreren Streaming-Servern zuweist. Die Peers
speichern die zuletzt abgespielten Teile des Videos und tauschen diese untereinander aus. Um die Startup-Verzögerung
zu minimieren, speichert jeder Peer ebenfalls den Anfang
des Videos. Die Nachbarn eines Peers werden anhand der
Differenz der Abspielposition auf Ringe aufgeteilt. Der innerste Ring, Gossip-Ring genannt, beinhaltet andere Peers
mit ähnlicher Abspielposition und überlappendem Buffer. Die
äußeren Ringe, Skip-Ringe genannt, beinhalten Peers, deren
aktuelle Abspielposition weiter entfernt ist.
mehr nur an Peers hochgeladen werden, von denen auch Teile
heruntergeladen werden können. Da beim Video-Streaming
bevorzugt Teile in der Nähe der eigenen Abspielposition
angefragt werden, eignet sich der Standardalgorithmus hauptsächlich für Peers mit ähnlicher Abspielposition, weil diese
viele Teile untereinander austauschen können. Wenn sich aber
ein Peer erst am Anfang des Videos befindet, ist dieser zwar
an den Teilen eines anderen Peers, der bereits fast das gesamte
Video heruntergeladen hat, interessiert, aber nicht umgekehrt.
Deshalb ist ein Unchoking-Algorithmus, der auf der Anzahl
der weitergeleiteten Teile basiert, für Video-Streaming besser
geeignet.
Der Unchoking-Algorithmus wird so modifiziert, dass immer die drei besten Forwarder unchoked werden. Wie bei
BitTorrent wird auch immer ein zufälliger Peer unchoked
(Optimistic Unchoke). Die Bewertung eines Peers q durch
einen Peer p geschieht dabei nach der Anzahl der Pieces, die
q innerhalb des letzten Intervalls an andere Peers hochgeladen
hat. Dabei werden zunächst nur solche Teile berücksichtigt,
die q von p erhalten hat. Sollten mehrere Peers die gleiche
Anzahl an Teilen weitergeleitet haben, werden alle von diesen
hochgeladenen Teile berücksichtigt. Um an diese Zahlen zu
kommen, sendet q an p eine Liste der Peers, an die er Teile
hochlädt. Peer p fragt dann bei diesen Peers nach. Dadurch
soll verhindert werden, dass Peers falsche Angaben über die
Anzahl der hochgeladenen Pieces senden. Dieses Szenario ist
in Abbildung 4 dargestellt. Peer p lädt zu q Daten hoch, dieser
leitet sie an die Peers x und y weiter. Der Peer p fragt dann
x und y nach den von q weitergeleiteten Teilen.
Abbildung 4. Beispiel eines Give-to-Get Netzwerks. Peer p lädt Teile an
Peer q hoch, der diese wiederum an x und y hochlädt. Peer p erhält durch
Nachfrage bei x und y die Informationen darüber, wieviele Teile q an andere
Peers weitergeleitet hat.
Abbildung 5. Beispielausschnitt aus einem RINDY-Netzwerk. Gezeigt ist
ein Peer p sowie andere Peers, die in Ringe um p aufgeteilt sind. Bei dem
inneren Ring handelt es sich um den Gossip-Ring, bei den äußeren Ringen
um Skip-Ringe.
Neben dem neuen Unchoking-Algorithmus kommt bei
Give-to-Get ebenfalls ein neuer, auf Video on Demand zugeschnittener, Piece-Selection-Algorithmus zum Einsatz. Ähnlich wie bei BiToS werden die Teile in verschiedene Mengen
eingeteilt. Give-to-Get verwendet hier jedoch drei Mengen:
Ein High-Priority-Set für die als nächstes abzuspielenden Teile, ein anschließendes Mid-Priority-Set und ein Low-PrioritySet für alle restlichen Teile am Ende des Videos. Die Mengen
haben hier eine feste Größe und beginnen immer direkt an der
aktuellen Abspielposition, können also auch bereits heruntergeladene Teile enthalten. Bei der Piece-Selection werden immer zuerst alle Teile aus dem High-Priority-Set heruntergeladen, dann aus dem Mid-Priority-Set und erst anschließend aus
Jeder Peer verwaltet eine Liste mit einer gewissen Anzahl
von Peers aus dem Gossip-Ring, sogenannte Near-Neighbors,
sowie aus jedem Skip-Ring, sogenannte Far-Neighbors. Für
jeden Skip-Ring wird außerdem eine Liste mit Backup-Peers
verwaltet, um Ersatz für Far-Neighbors zu haben, die das
Netzwerk verlassen. Die Ringe eines Peers p und dessen Verbindungen zu anderen Peers sind in Abbildung 5 dargestellt.
Innerhalb des Gossip-Rings tauschen die Peers regelmäßig
Nachrichten mit ihren Abspielposition und Buffer-Zustand
37
~
7
(vorhandene Pieces etc.) mit ihren Nachbarn aus. Diese Nachrichten werden auch an andere Peers in dem Ring weitergeleitet, um neue Nachbarn zu finden.
Wenn ein Peer seine Abspielposition durch Springen innerhalb des Videos verändert, benötigt er neue Nachbarn in der
Nähe der neuen Position. Hierzu wird eine Lookup-Operation
über die Ringstruktur gestartet. Befindet sich die neue Position
außerhalb des Gossip-Rings, wird eine Anfrage an den bekannten Peer gesendet, der am nächsten an der neuen Position
liegt. Wenn sich die gewünschte Position in dessen GossipRing befindet, wird eine Nachricht an den suchenden Peer mit
einer Liste von Peers aus dem entsprechenden Gossip-Ring
gesendet. Andernfalls wird das Verfahren rekursiv fortgesetzt,
bis die Anfrage einen Peer aus dem gesuchten Ring erreicht.
Einschränkung auf Kunden aus bestimmten Ländern denkbar.
Außerdem soll es einen seperaten Payment-Provider geben,
so dass die Zahlungsinformationen nur diesem und nicht dem
Video-Produzenten oder gar anderen Benutzern des Netzwerks
bekannt sind. Ein weiteres bei P2P-Next betrachtetes Problem
ist, dass P2P-Netzwerke in der Regel keine Kenntnis der
unterliegenden Netzwerk-Topologie haben. Hier wäre es insbesondere wünschenswert, in ISP Caches ausgetauschte Daten
zu speichern und somit den Traffic zu reduzieren.
Als Lösungsansatz für diese Probleme setzt P2P-Next auf
ein verteiltes System, das neben dem P2P-Netzwerk zum
Übertragen des Contents zwei zusätzliche Komponenten enthält: Ein Payment-System, bei dem Benutzer für Content bezahlen können und ein entsprechendes Token enthalten, sowie
ein Access-Control-System, das den Benutzern gegen Vorzeigen des Tokens nach Überprüfung beim Payment-System
einen Schlüssel zum Dekodieren des Contents zur Verfügung
stellt. Der Content wird dabei, ähnlich wie beim Satellitenfernsehen, mit einem Schlüssel für alle Benutzer verschlüsselt,
so dass die verschlüsselten Daten frei verteilt und in Caches
zwischengespeichert werden können. Um die Daten jedoch
zu benutzen, ist ein entsprechender Schlüssel nötig, den nur
authorisierte Benutzer erhalten.
Dadurch, dass die Verschlüsselung bei P2P-Next optional
ist, können auch andere Geschäftsmodelle realisiert werden.
So kann das Video beispielsweise unverschlüsselt übertragen
werden, und Benutzer können nach dem Anschauen freiwillig
spenden. Auch eine Einschränkung anhand geografischer Position der Benutzer ist implementierbar, indem nur das AccessControl-System ohne Payment-System verwendet wird.
V. Z USAMMENFASSUNG UND AUSBLICK
Durch den Einsatz von P2P-Technologie bei Video-onDemand-Streaming können Serverlast und Trafficaufkommen
für die Betreiber von Video-Angeboten deutlich gesenkt werden. Dazu gibt es verschiedene Ansätze, die sich in zwei
grundsätzliche Klassen einteilen lassen.
Eine Klasse von P2P-basierten Video-Streaming-Systemen
sind die Application-Layer-Multicast-Systeme, bei denen Clients, die das Video in einem gewissen Zeitfenster anfragen,
zusammen mit einem Streaming-Server einen Multicast-Baum
zum Streamen des Videos bilden. Hier gibt es verschiedene
Techniken um das Streaming trotz unterschiedlicher Ankunftszeiten und somit anderer Abspielpositionen zu ermöglichen.
P2Cast verwendet dazu einen Patch-Stream, über den Clients
beim Betreten des Systems den verpassten Anfang des Videos
erhalten, bei P2VoD cachen die Peers hingegen immer die
zuletzt empfangenen Teile des Videos und leiten neuen Clients
einen kontinuierlichen Stream ab Beginn des Videos weiter.
Daneben gibt es Systeme, die keine explizite NetzwerkTopologie aufbauen, sondern das Video in kleine Teilstücke
unterteilen und diese Teilstücke untereinander austauschen.
Viele dieser Systeme basieren auf dem für File-Sharing bewährten BitTorrent-System, verändern jedoch Komponenten
davon, um die Wiedergabe des Videos zu ermöglichen, bevor
es vollständig heruntergeladen ist. Hierfür gibt es verschiedene
Ansätze, die versuchen, eine Balance zwischen dem Download
der Teile in der Abspielreihenfolge und einer möglichst guten
Verteilung der Teile über die Peers zu erreichen.
Auch Funktionen wie das Springen zu bestimmten Stellen
in einem Video ist mit P2P-Systemen realisierbar. Systeme wie
RINDY bauen entsprechende Verbindungen auf, um solche
Operationen möglichst effizient zu unterstützen.
Ein weiterer interessanter Aspekt ist der Einsatz von P2Pbasierten Video-Streaming-Systemen für die Verteilung von
kommerziellen Videos. Mit den besondern Anforderungen für
solche Anwendungsszenarien beschäftigt sich u.a. P2P-Next
[11], ein von der EU unterstütztes Projekt, dessen Ziel die
Entwicklung einer P2P Content Delivery Plattform ist. In [11]
werden dabei insbesondere die folgenden Anforderungen aufgeführt: Zum einen möchte der Produzent einschränken, wer
das Video sehen kann. Neben der Beschränkung auf Kunden,
die für die Inhalte bezahlt haben, ist beispielsweise auch eine
L ITERATUR
[1] E. Akyol, A.M. Tekalp, and M.R. Civanlar. A flexible multiple
description coding framework for adaptive peer-to-peer video streaming.
IEEE Journal of Selected Topics in Signal Processing, 1(2):231–245,
2007. III-A
[2] Y. Borghol, S. Ardon, N. Carlsson, and A. Mahanti. Toward Efficient
On-Demand Streaming with BitTorrent. NETWORKING 2010, pages
53–66, 2010. IV-B3
[3] M. Cha, H. Kwak, P. Rodriguez, Y.Y. Ahn, and S. Moon. I tube,
you tube, everybody tubes: analyzing the world’s largest user generated
content video system. In Proceedings of the 7th ACM SIGCOMM
conference on Internet measurement, pages 1–14. ACM, 2007. I
[4] B. Cheng, H. Jin, and X. Liao. RINDY: a ring based overlay network
for peer-to-peer on-demand streaming. Ubiquitous Intelligence and
Computing, pages 1048–1058, 2006. IV-B7
[5] B. Cohen. Incentives build robustness in BitTorrent. In Workshop on
Economics of Peer-to-Peer systems, volume 6, pages 68–72. Citeseer,
2003. I, II-B, III-B
[6] C. Dana, D. Li, D. Harrison, and C.N. Chuah. Bass: Bittorrent
assisted streaming system for video-on-demand. In Multimedia Signal
Processing, 2005 IEEE 7th Workshop on, pages 1–4. IEEE, 2006. IV-B1
[7] T.T. Do, K.A. Hua, and M.A. Tantaoui. P2VoD: Providing fault
tolerant video-on-demand streaming in peer-to-peer environment. In
Communications, 2004 IEEE International Conference on, volume 3,
pages 1467–1472. IEEE, 2004. IV-A2
[8] P. Garbacki, A. Iosup, D. Epema, and M. van Steen. 2fast: Collaborative
downloads in p2p networks. In Peer-to-Peer Computing, 2006. P2P
2006. Sixth IEEE International Conference on, pages 23–30. IEEE,
2006. IV-B5
[9] V.K. Goyal. Multiple description coding: Compression meets the
network. Signal Processing Magazine, IEEE, 18(5):74–93, 2002. III-A
[10] Y. Guo, K. Suh, J. Kurose, and D. Towsley. P2Cast: peer-to-peer patching scheme for VoD service. In Proceedings of the 12th international
conference on World Wide Web, pages 301–309. ACM, 2003. IV-A1
38
8~
[11] R. Jimenez, L.E. Eriksson, and B. Knutsson. P2P-Next: technical and
legal challenges. Research funded by Seventh Framework Programme,
2009. V
[12] N. Magharei, R. Rejaie, and Y. Guo. Mesh or multiple-tree: A comparative study of live p2p streaming approaches. In INFOCOM 2007. 26th
IEEE International Conference on Computer Communications. IEEE,
pages 1424–1432. Ieee, 2007. III-C
[13] JJD Mol, JA Pouwelse, M. Meulpolder, DHJ Epema, and HJ Sips.
Give-to-get: Free-riding-resilient video-on-demand in p2p systems.
Proceeding of the 15th SPIE/ACM Multimedia Computing and
Networking (MMCN’08), 2008. IV-B6
[14] J.A. Pouwelse, P. Garbacki, J. Wang, A. Bakker, J. Yang, A. Iosup,
D.H.J. Epema, M. Reinders, MR Van Steen, and H.J. Sips. Tribler:
A social-based peer-to-peer system. Concurrency and Computation:
Practice and Experience, 20(2):127–138, 2008. IV-B4
[15] H. Schwarz, D. Marpe, and T. Wiegand. Overview of the scalable video
coding extension of the H. 264/AVC standard. IEEE Transactions on
Circuits and Systems for Video Technology, 17(9):1103–1120, 2007.
III-A
[16] A. Vlavianos, M. Iliofotou, and M. Faloutsos. BiToS: Enhancing
BitTorrent for supporting streaming applications. In INFOCOM 2006.
25th IEEE International Conference on Computer Communications.
Proceedings, pages 1–6. IEEE, 2007. IV-B2
39
SKYPE - EIN ÜBERBLICK ÜBER DIE PROTOKOLLE, DAS OVERLAY-NETZWERK UND DIE SICHERHEITSMASSNAHMEN
~
Skype - Ein Überblick über die Protokolle, das
Overlay-Netzwerk und die Sicherheitsmaßnahmen
Marius Hornung
Nutzerverhaltens werden bewusst zurückgehalten und effektiv
verschleiert.
Diese Arbeit fasst die Resultate von Forschern und Forschungsgruppen, die Interesse an Skypes Protokollen und dem
Overlay-Netzwerk haben, zusammen und versucht so diese
zentralen Fragen zu beantworten. Dabei wird ihr Vorgehen und
ihre Analyseansätze vorgestellt und die Probleme, welchen sie
sich stellen mussten, beschrieben. Danach werden allgemeine
Begriffe, die zum weiteren Verständnis notwendig sind, eingeführt. Es folgt eine Zusammenfassung der Ergebnisse, die
zu einem Überblick über die Struktur des Overlay-Netzwerks
und die darin involvierten Entitäten führt. Weiterhin werden
wichtige Begriffe, die zur korrekten Funktionalität eines SC
essentiell sind, erläutert. Am Beispiel der Funktionen Login
und Sprachtelefonie werden Methoden zur Umgehung von Firewalls und Network Address Translators (NAT), sowie Sicherheitsmaßnahmen zum Schutz der Privatsphäre, exemplarisch
gezeigt. Das Paper schließt ab mit einer Zusammenfassung.
Zusammenfassung—Skype ist eine Voice-over IP Software basierend auf einem Peer-to-Peer Netzwerk. Es ist die erfolgreichste
Software seiner Art, bietet kostenlose und auch kostenpflichtige
Dienste, ist aber proprietär und damit Closed-Source. Forscher
haben ein grosses Interesse daran herauszufinden, wie Skype
funktioniert, um die Ergebnisse für die eigene Forschung zu
nutzen. Dabei werden sie vor viele Probleme gestellt, die Skype
absichtlich mit sich bringt, um das eigene Know-how zu schützen. Die vorliegende Arbeit stellt diese Probleme vor, fasst die
bisher erfahrenen Resultate von Forschern zusammen und gibt
einen Überblick bezüglich des verwendeten Overlay-Netzwerks.
Weiterhin werden dem Endbenutzer verborgene Details, wie das
Umgehen und Durchdringen von Firewalls und NATs, sowie die
Maßnahmen zum Schutz der Privatspähre von Skype-Nutzern,
beschrieben. Auf Grund der Closed-Source-Taktik, die Skype
nutzt, sind die Ergebnisse vage.
I. E INFÜHRUNG
Skype ist eine Voice over Internet Protokoll (VoIP)Software, die in 2003 erstmals veröffentlicht und von ehemaligen Mitarbeitern von Kazaa [6] entwickelt wurde. Es
handelt sich um die weitverbreitetste und erfolgreichste Software dieser Art mit 519 Millionen registrierten Benutzern
(2009) [5]. Im November 2010 waren erstmals 25 Millionen Benutzer gleichzeitig online [15]. Die Software bietet
kostenlose Features, wie Sprach- und Videotelefonie, InstantMessaging, Datei-Transfer und Screensharing. Darüber hinaus
werden kostenpflichtige Dienste angeboten zu welchen Anrufe
aus und in traditionelle Telefonnetze (SkypeIn, SkypeOut),
Skype To Go-Nummern und Videokonferenzen gehören.
Die zentralen Fragen, welche sich Forscher, Sicherheitsadministratoren und Konkurrenten von Skype stellen, beziehen sich
auf die Gründe des großen Erfolgs, die verwendeten Technologien und beschäftigen sich mit Sicherheitsfragen. Allerdings
liegt die Motivation dieser Interessengruppen in verschiedenen
Bereichen: Während Forscher gerne die Erfahrung von Skype
bei der Unterhaltung von großen Peer-to-Peer (P2P)-Netzen
öffentlich zugänglich hätten, um sie für Ihre eigene Forschung
nutzen zu können, liegt der Interessenschwerpunkt von Konkurrenten direkt auf den verwendeten Technologien, um ihre
eigenen Produkte zu verbessern. Sicherheitsadministratoren
können nicht nachprüfen, ob die Angaben, die Skype zum
Schutz der Privatsphäre der Nutzer macht, stimmen oder ob
vielleicht im Skype-Client (SC) ein Trojaner/eine Backdoor
eingebaut ist. Trotz des hohen Interesses ist noch sehr viel über
Skype im Dunklen. Die Gründe lassen sich in der Tatsache
finden, dass Skype versucht das eigene Knowhow, so weit
wie möglich, vor dem Zugriff Dritter zu schützen, um die eigene Marktposition zu stärken. Informationen zur Architektur
des Overlay-Netzwerks, den Sicherheitsmechanismen und des
II. AUFDECKEN DER P ROTOKOLLE
Dieses Kapitel fasst die Ansätze von verschiedenen Forschern, die herausfinden möchten wie Skype im Detail funktioniert, zusammen. Prinzipiell lassen sich diese in zwei Gruppen
einteilen:
Der erste Ansatz sammelt von Skype generierten NetzwerkTraffic in großen Mengen unter verschiedenen Netzwerkbedingungen, variiert in Testszenarien hinsichtlich öffentlicher
IP-Adresse, Firewalls und NATs. Diese gesammelten Pakete
werden dann einzeln und/oder in Bezug auf eine bestimmte
Skype-Funktion (zum Beispiel Login, Benutzersuche, ...) als
Message-Flows betrachtet und ausgewertet. Während Guha,
Daswani und Jain in [10] und Baset und Schulzrinne in [14]
so versucht haben die einzelnen Funktionen von Skype zu
analysieren, um ein tieferes Verständnis der Protokolle und des
Overlay-Netzwerkes zu erlangen, haben Ehlert und Petgang
in [11], Bonfiglio et al. in [6] und Branch et al. in [8]
ihr Augenmerk auf das Detektieren von Skype generierten
Netzwerk-Traffic gelegt.
Der zweite Ansatz, genutzt von Biondi und Desclaux in [3]
geht einen anderen Weg. Sie beschäftigen sich mit der Analyse
des Quellcodes des Skype-Binarys1 und stellen die Ergebnisse
in Bezug zu Netzwerkpaketen und Funktionen von Skype,
um an Einblicke zu gelangen. Nebenresultat dieses Ansatzes
ist die Identifikation der Schutzmechanismen von Skype gegen Reverse-Engineering-Angriffe. Bei diesen Angriffen wird
durch die genaue Untersuchung der Strukturen, Zustände und
1 Binary:
40
Ausführbare Datei in Maschinensprache oder Bytecode
~
Verhaltensweisen eines fertigen Systems versucht die Konstruktionselemente und –details zu extrahieren.
E. Verschlüsselung der Netzwerkpakete
Der Payload von Netzwerkpaketen, die Skype erzeugt, wird
RC42 verschlüsselt. Der RC4-Schlüssel wird durch die Zielund Quell-IP, der Skype Packet-ID und einem nicht weiter
bekannten Initialisierungsvektor erzeugt. Anzumerken ist, dass
diese RC4-Verschlüsselung einzig der Verschleierung des Inhalts der Netzwerkpakete dient. Der Schutz der Privatsphäre
wird durch andere Methoden, siehe Abschnitt VII, sichergestellt [3].
III. S CHUTZMECHANISMEN SEITENS S KYPE
Im letzten Abschnitt wurden Schutzmechanismen angedeutet, die verhindern, dass man Skypes Funktionsweise schnell
erfassen kann und weswegen noch viele Details im Dunklen
liegen. Im Folgenden werden diese beschrieben und somit
begründet, warum die Ergebnisse der Arbeiten sehr vage sind.
Die Mechanismen werden nur kurz angedeutet, aber nicht in
der Tiefe erläutert.
IV. G RUNDLEGENDES
Dieser Abschnitt erläutert grundlegende Begriffe, die für das
Verständnis des weiteren Verlaufs des Papers notwendig sind,
sich aber nicht direkt auf Skype beziehen. Dazu gehören die
beiden Protokolle UDP und TCP, sowie durch Firewalls und
NATs auftretende Probleme.
A. Binary Packing
Einige Teile des Skype-Binarys sind mit einem festkodierten
Schlüssel per XOR verknüpft. Erst zur Laufzeit werden diese
Teile des Codes entschlüsselt. Um das Dumping des Codes
aus dem Speicher zu verhindern löscht Skype den Anfang
des eigenen Codes und überschreibt teilweise die original
Import-Table mit einer eigenen Import-Table. Weiterhin finden
Imports von Bibliotheken dynamisch während der Laufzeit
statt [3].
A. TCP und UDP
TCP und UDP sind zwei auf der Transportschicht [2],
[12] des ISO/OSI-Referenzmodels angesiedelte Protokolle zur
Übertragung von Daten im Internet.
TCP ist ein zuverlässiges, verbindungsorientiertes und paketvermitteltes Transportprotokoll. Nachrichten werden in kleinere Pakete aufgespalten und über eine vorher hergestellte
Verbindung mit der Gegenseite ausgetauscht. Die Übertragung
aller Pakete wird durch das Protokoll sichergestellt. Im Gegensatz dazu ist UDP verbindungslos und unzuverlässig, dass
heißt die Übertragung der Daten wird nicht sichergestellt. Da
UDP keinerlei Fehlerkorrekturen vornimmt, ist es im Vergleich
zu TCP schneller und ressourcenschonender. Dadurch reduzieren sich Bandbreitenverbrauch und Latenzzeiten maßgeblich
[4]. Aus diesem Grund wird für Internettelefonie bevorzugt auf
UDP zurückgegriffen, da kleinere Ungenauigkeiten im Sprachund Videostream vom Menschen nicht wahrgenommen werden
können.
B. Integritätschecks des Codes zur Laufzeit
Um Veränderungen im Binary, wie zum Beispiel das Ersetzen eines bestimmten Code-Bereiches um fremde CodeFragmente, zu erkennen wird der Code von Skype zur Laufzeit
ständigen Integritätschecks unterzogen. Unter normalen Umständen werden diese Integritätschecks zur Identifikation von
Schadcode verwendet. In [3] haben die Autoren 300 solcher
Tests gefunden, was stark darauf hinweist, dass Skype diese
Tests nur durchführt, um das Reverse-Engineering zu erschweren. Zu diesen vielen kleineren Integritätschecks fügt sich noch
ein finale Überprüfung durch einen RSA-Integritätscheck an.
B. NAT und Firewall
NAT erlaubt es private Netzwerke an öffentliche Netze, wie
zum Beispiel das Internet, anzubinden. Der Grund liegt in
der Knappheit der IPv4-Adressen. Dabei teilen sich mehrere
Hosts in einem privaten Adressraum eine öffentliche IPAdresse. NAT-Router, die an der Grenze zwischen privaten
und öffentlichen Netzen liegen, ersetzen automatisiert Adressinformationen in Datenpaketen, um beide Netze miteinander
zu verbinden. Dabei unterhält der NAT-Router eine Tabelle zur
Zuordnung von Verbindungen zu privaten Hosts. Verbindungen, die nicht von der privaten Seite aufgebaut oder explizit
von einem Administrator in der Tabelle vermerkt werden,
können von dem NAT-Router keinem Host in dem privaten
Netz zugeordnet werden. Somit ist ein Host in einem privaten
Netz faktisch nicht von außen zu erreichen. Ein ähnliches
Problem stellt sich für Firewalls dar: Es werden explizit
von außen und innen kommende Verbindungen blockiert, um
Sicherheit zu gewährleisten. Dies führt, wie in [7] beschrieben,
zu einigen Problemen bezüglich der Erreichbarkeit von SkypeKnoten in privaten Netzen .
C. Anti-Debugging Techniken
Skype verhindert effektiv das Nutzen eines Kerneldebuggers
durch generische und konkrete Tests. Da das Setzten von
Breakpoints das Binary verändert, schlagen die Integritätschecks fehl. Konkret testest Skype auf den Debugger Softice,
in dem es versucht dessen Treiber zu laden. Erkennt Skype das
Mitlaufen eines Debuggers werden Zufallssprünge im Code
gemacht und Register randomisiert, was das Erkennen von
Strukturen im Code unmöglich macht [3].
D. Quelltextverschleierung
Quelltextverschleierung (Code Obfuscation), soll das Entwenden und Studieren des Codes so schwer wie möglich
machen. Skype erreicht dies durch dynamisches Aufrufen von
Funktionen und gewollte Sprünge im Quellcode, die nicht der
Funktionalität dienen, sondern nur zur Verschleierung getätigt
werden. [3].
2 RC4
41
oder ARC4 ist eine Stromverschlüsselung
~
C. STUN und TURN
Session Traversal Utilities for NAT (STUN) [9] ist ein
Protokoll, welches das Vorhandensein und die Art von Firewalls und NATs, hinter welchen sich ein Host eventuell
befindet, erkennt und durchdringen kann. Dabei werden nach
bestimmten vorher definierten Abläufen Pakete zwischen dem
Host und einem STUN-Server verschickt. Je nach Erfolg oder
Misserfolg des Sendens bzw. veränderter Adressinformationen
in den Paketen lassen sich Rückschlüsse auf eine Firewall oder
das verwendete NAT ziehen.
Traversal Using Relay NAT (TURN) [13] ist ein Protokoll,
welches einen Host hinter einer Firewall oder einem NAT
erlaubt Daten über eingehende TCP- oder UDP-Verbindungen
zu empfangen. Die Hauptmethodik, welcher sich TURN bedient, basiert auf einer dritten Partei, dem TURN-Server, der
als Proxy zwischen zwei kommunizierenden Hosts dient.
Mit Hilfe von STUN und TURN lassen sich NATs und Firewalls erkennen und dadurch auftretende Probleme umgehen.
Allerdings benötigt man dazu eine dritte Partei mit einer
öffentlichen IP-Adresse.
Ordinary Node
V. DAS OVERLAY
Im folgenden Abschnitt werden die teilnehmenden Entitäten
im Skype-Netzwerk, Ordinary Nodes (ON), Super Nodes
(SN), Bootstrap Super Nodes (BSN) und der Login-Server,
sowie der für die Funktionalität von Skype wichtige Host
Cache (HC), erläutert.
Super Node
Login-Server
A. Skype Client
Abbildung 1. Das Skype-Overlay-Netzwerk. ONs verbinden sich mit SNs,
die untereinander ein Overlay bilden. SNs und ONs verbinden sich zum Login
mit dem LS, der einzigen zentralen Komponente im Netzwerk.
Ein Skype-Client (SC) ist ein im Skype-Netz teilnehmender
Knoten. Er bietet die grundlegenden Funktionen, wie Eintreten
in das Netz, Instant-Messaging, Annahme und Initierung von
Sprach- und/oder Videoanrufen, Abmelden aus dem Netz,
Datentransfer und Benutzersuche. Ein SC kann, abhängig von
bestimmten Umständen, entweder ein ON oder ein SN sein
[14].
umgehen ist das Hauptkriterium, um zu einem SN zu werden,
eine öffentliche IP-Adresse. Nebenkriterien sind ausreichender
RAM, CPU und Bandbreite.
Es existieren mehr ONs als SNs und SNs sind mit ONs im
Verhältnis 1 zu n assoziiert. Abbildung 2 lässt Vermuten, dass
es im Durchschnitt weniger als 3 sind. Dass ein oberes Limit
existiert erkennt man daran, dass mit steigender Zahl an ONs
auch die Anzahl der SNs steigt.
B. Ordinary Node
Ein Ordinary Node ist ein SC und bietet keine weiteren
oder besonderen Funktionen. Zum erfolgreichen Eintritt in
das Skype-Netz ist jedoch eine TCP-Verbindung zu einem SN
notwendig [14].
D. Skype Login-Server
Der Skype Login Server (LS) ist die einzige zentrale Entität
im Skype-Netzwerk [14], [11] ist dabei aber nicht am OverlayNetzwerk selbst beteiligt. Der LS speichert die Buddy-Liste,
Benutzernamen und deren zugehörigen Passwörter und ist für
die Authentifizierung von Benutzern während des Netzeintritts
verantwortlich. Des Weiteren sorgt der LS dafür, dass Benutzernamen im Skype-Namensraum Unikate sind.
C. Super Node
SNs bilden untereinander ein Overlay-Netzwerk (Abbildung
1). Mehrere ONs verknüpfen sich mit einem SN. SNs bieten,
im Gegensatz zu ONs, weitere Funktionen, die dem Endbenutzer aber nicht direkt zur Verfügung stehen. Diesen sind ihm
aber von Nutzen, falls er sich hinter einer Firewall und/oder
einem NAT befindet und deshalb nicht von aussen kontaktiert
werden kann. ONs, die nicht direkt mit dem Internet über
eine öffentliche IP-Adresse verbunden sind, nutzen SNs, um
ihre Erreichbarkeit zu sichern [14], [11]. Eine genauere Erläuterung findet im nächsten Abschnitt statt. Jeder in das Netz
eintretende SC ist, wie schon erwähnt, potentiell ein SN. Auf
Grund der eben vorgestellten Methodik Firewalls und NATs zu
E. Host Cache
Jeder SC verwaltet eine Liste mit höchstwahrscheinlich
erreichbaren anderen SCs, den Host Cache (HC) [14]. Der
HC beinhaltet Paare von IP-Adressen und Ports von SNs.
Der Eintritt in das Overlay-Netzwerk ist ein kritischser Punkt
42
~
Start
UDP-Pakete
zu BSNs
Anwtort in 6
Sekunden
Ja
Nein
TCP
Verbindungsversuche
zu BSNs
Abbildung 2. Anteil der SNs auf die Gesamtzahl der SCs. Der Bereich xAchse bis blaue Linie gibt den Anteil der SNs an. Von der blauen Linie aus
nach oben gehend zur roten Linie zeigt den Anteil der ONs. Abbildung von
[10].
Verbunden
Ja
Erfolg
Nein
und mindestens ein Knoten im HC muss erreichbar sein, um
erfolgreich in das Netz einzutreten. In [14] wird angegeben,
dass ein HC nach zwei Tagen etwa 200 Einträge vorzuweisen
hat. Diese Anzahl steigt bei weiterer Beobachtung nicht mehr.
6 Sekunden
warten
F. Bootstrap Supernodes
Nach der Installation von Skype ist der HC leer. Da der SC
in diesem Fall keinen SN zum Eintreten in das Netz kennt,
existieren im Quellcode fest codierte Bootstrap Super Nodes
(BSN). Diese Knoten werden bei leerem HC als Bootstrapnode, bei Unerreichbarkeit der Knoten als Backup genutzt.. S.
A. Baset und H. G. Schulzrinne vermuten in [14], dass es 8
solcher BSN gibt und diese fest in den Skype-Client eincodiert
sind.
Abbildung 3. Der Loginalgorithmus beim ersten Start eines SCs (HC ist
leer) vor dem Authentifizieren am LS.
problemlos und für den Nutzer verborgen NATs und Firewalls
zu umgehen. Skype verwendet dazu wahrscheinlich STUN
und TURN ähnliche Protokolle [14]. Hinweise darauf
lassen sich im Loginprozess finden (Abbildung 3). Dieser
stellt eine kritische Funktion in Skype dar, weil der SC
mindestens einen SN erreichen und sich gegenüber dem
LS authentifizieren muss. Nach dem Start schickt der
SC UDP-Pakete an die BSN und versucht danach erst,
unabhängig ob diese erfolgreich versendet wurden oder nicht,
die notwendige TCP-Verbindung zu einem BSN aufzubauen.
Der Sinn dahinter lässt sich in STUN finden. Wahrscheinlich
versucht der SC das Vorhandensein und die Art eines NATs
und/oder einer Firewall, hinter welcher er sich ggf. befindet,
festzulegen, bevor er einen Verbindungsversuch startet.
Im folgenden Abschnitt werden drei Netzwerkszenarien
betrachtet, um die Verwendung von einem TURN ähnlichen
Protokoll und den Rückfall auf TCP-Kommunikation, sollte
UDP nicht möglich sein, zu zeigen.
VI. KOMMUNIKATIONSPARADIGMEN
Der folgende Abschnitt erläutert exemplarisch am LoginProzess und der Sprachtelefonie in welcher Form SCs untereinander kommunizieren und welche Rolle dabei STUN
und TURN spielen. Im zweiten Teil werden die Transferraten
beleuchtet.
A. Kommunikation zwischen zwei Knoten
In Skype erfolgt die Kommunikation zwischen zwei
Knoten ausschließlich über UDP oder TCP, wobei
Kontrollinformationen immer über TCP und Sprachpakete,
wenn möglich, immer über UDP transportiert werden. In
besonderen Fällen kann aber auch Sprache via TCP übertragen
werden. Im Gegensatz zu anderen VoIP-Lösungen, wie zum
Beispiel Google Talk 3 , schafft es Skype augenscheinlich
a) Anrufer und Angerufener haben öffentliche IPAdresse: Gesetz dem Fall, dass Anrufer und Angerufener
eine öffentliche IP-Adresse haben und deshalb beide
3 http://www.google.com/talk/
43
1
noch die Ports 80 (HTTP) und 443 (HTTPS), um Firewalls
zu durchdringen [14]. Des Weiteren legt Skype einen zufällig
gewählten Port während der Installation fest, auf welchem
es auf TCP- und UDP-Verbindungen lauscht. Dieser Port
kann vom Benutzer beliebig geändert werden [14]. Zwei SCs
erkennen, falls sie sich hinter demselben NAT befinden. Dann
wird die Sprachkommunikation komplett in dem privaten Netz
realisiert [14]. Die Nutzersuche, die es ermöglicht andere
Teilnehmer zu finden, ist dezentral organisiert und erfolgt
über das Peer-2-Peer-Netz. Skype gibt an eine Peer-to-Peer
Technologie der dritten Generation („3G P2P„oder GI für
„Global Index „) entwickelt zu haben, die jeden Benutzer findet, sollte er sich innerhalb der letzten 72 Stunden im SkypeNetzwerk angemeldet haben [17]. Auch bei der Nutzersuche
werden die schon bei Anrufen vorgestellten Techniken zur
Überwindung von NATs und Firewalls genutzt. Suchen SCs
hinter einer Firewall oder einem NAT einen Benutzer, dann
führt der mit diesem Knoten assoziierte SN die Suche durch
[14]. Des Weiteren lassen sich Hinweise auf ein Caching von
Suchergebnissen finden [14].
Internet
Public IP
Anrufer
2
Public IP
Angerufener
Public IP
SN
NAT
Public IP
Private IP
Anrufer
Internet
Public IP
Angerufener
TCP - Steuerinformationen
UDP - Sprachtelefonie
3
Public IP
SN
Internet
NAT / Firewall
Public IP
Private IP
Anrufer
NAT / Firewall
Public IP
~
Public IP
Angerufener
TCP - Steuerinformationen & Sprachtelefonie
Abbildung 4.
Die Kommunikation zwischen SCs unter verschiedenen
Netzwerkszenarien. In 1 erfolgt eine normale Kommunikation direkt zwischen
beiden Parteien. In 2 und 3 dient ein dritter SCs als Proxy. In 3 fällt Skype
komplett auf die Kommunikation via TCP zurück.
B. Transferraten
Haben beide SCs eine öffentliche IP-Adresse fließen
Sprach- und Videodaten zwischen ihnen direkt über UDP.
Die Größe eines UDP-Sprachpakets variiert dabei zwischen
40 und 110 Bytes. Folglich beträgt die gesamte Uplink- und
Downlinkbandbreite für Sprachdaten ca. 5 kilobytes/s [14]
(Fall 1 in 4).
Befinden sich entweder Anrufer oder Angerufener hinter einem port-restricted NAT (Fall 2 in 4), tauschen beide Teilnehmer Sprachdaten direkt miteinander aus. Die Paketgröße
von Sprachpaketen variiert zwischen 40 und 110 Bytes. Die
benutzte Bandbreite beträgt in etwa 5 kilobytes/s [14].
Sind beide SCs, Anrufer und Angerufener, hinter einem portrestricted NAT und einer UDP-restricted Firewall tauschen
beide Daten via TCP über einen dritten SC aus. Die Paketgröße
von Sprachdaten variiert zwischen 30 und 90 Byte. Die totale
Uplink- und Downlinkbandbreite, die dabei genutzt wird,
beläuft sich in etwa auf 5,5 kilobytes/s.
uneingeschränkt von außen über TCP und UDP erreichbar
sind (Abbildung 4 Punkt 1), erfolgt die Kommunikation für
Steuersignale über TCP und für Sprache über UDP.
b) Anrufer hinter port-restricted NAT und angerufener
hat öffentliche IP-Adresse: Besitzt nur der Angerufene eine
öffentliche IP-Adresse und der Anrufer befindet sich hinter
einem port-restricted NAT4 (Abbildung 4 Punkt 2) wird die
Kommunikation für Steuerinformationen über einen dritten
Knoten (einem SN) geleitet. Die Sprachkommunikation wird
weiterhin via UDP übertragen.
c) Beide Benutzer hinter port-restricted NAT und
UDP-restricted Firewall: Sind beide Benutzer, Anrufer und
Angerufener, hinter einem port-restricted NAT und einer
UPD-restricted Firewall5 (Abbildung 4 Punkt 2) wird ein
dritter Knoten für die komplette Kommunikation, Sprachund Steuerdaten, herangezogen. Es kommt nur noch TCP
zum Einsatz.
VII. S ICHERHEIT
Skype nutzt Authentifizierungs und Verschlüsselungstechniken, um die Privatsphäre seiner Nutzer zu schützen [16].
In diesem Abschnitt wird die von Skype verwendete Security
Policy und die eingesetzte Kryptografie bei der Registrierung
eines neuen Benutzers, sowie zwischen 2 Knoten, erläutert.
Während in A die Kommunikation standardmäßig verläuft,
zeigen sich in B und C Hinweise auf ein TURN ähnliches
Protokoll, welches durch die Nutzung eines dritten Knotens
als Proxy den Datenverkehr zwischen beiden vermittelt.
Neben den eben vorgestellten Techniken nutzt Skype auch
A. Security Policy
Eine Security Policy definiert, was Sicherheit bezogen auf
ein konkretes System, in diesem Fall Skype, bedeutet. Nach
einer Security Evaluation bei Skype gibt Tom Berson in [1] die
Skype Security Policy wie folgt an: Skype Benutzernamen sind
Unikate. Benutzer oder Applikationen müssen einen Skype
Benutzernamen und dessen assoziierte Authentifizierungsdaten vorweisen, bevor sie die zum Benutzernamen gehörende
Identität oder deren Rechte annehmen dürfen. Jeder Peer liefert
4 Port-restricted NAT: Möchten A und B kommunizieren und A befindet
sich hinter einem port-restricted NAT, so ist A nur von außen erreichbar, falls
A vorher eine Verbindung nach außen aufgebaut hat und dies auch nur über
den Port, von welchem aus die Verbindung aufgebaut wurde.
5 UDP-restricted Firewall: Möchten A und B kommunizieren und befindet
sich B hinter einer UDP-restricted Firewall, blockt diese alle ein- und
ausgehenden UDP-Verbindungen. Verbindungen via UDP sind in diesem Fall
komplett ausgeschlossen.
44
~
A, H(PA), VA
SC von A
1
Login-Server
Internet
Public IP
Anrufer
Identity Certificat
Abbildung 5.
Der Registeriungsprozess.
2
einem anderen Peer einen Nachweis seines Benutzernamens
und seiner Rechte, immer wenn eine Skype-Session hergestellt
wird. Beide Peers verifizieren diesen Nachweis, bevor der Session gestattet wird Nachrichten auszutauschen. Nachrichten,
die während einer Skype-Session übertragen werden, sind von
einem SC zum anderen SC verschlüsselt. Keine zwischengeschalteten Knoten haben Zugriff auf diese Nachrichten.
Die eben genannte Security Policy wird wie folgt umgesetzt:
SC B
SC A
Ende-zu-Ende verschlüsselt
Abbildung 6. Ende-zu-Ende Verschlüsselung auch über einen dritten Knoten
mittels Session-Key SKAB .
VIII. C ONCLUSION
Für den großen Erfolg von Skype sind viele Dinge verantwortlich. Hier ist vor allem die Peer-to-Peer-Struktur hervorzuheben, die wenige zentrale Instanzen benötigt und so dem Benutzer kostenlose Dienste ermöglicht. Andere Punkte sind die
einfache Bedienung, da durch Firewalls und NATs auftretende
Probleme fast unsichtbar für den Benutzer umgangen werden,
aber auch die kostenpflichtigen Angebote, die in Unternehmen Mehrwert schaffen, wie zum Beispiel Videokonferenzen.
Anderseits aber auch Kritikpunkte, wie den Fakt, dass Skype
Closed-Source ist. Zwar garantiert Skype die Sicherheit seiner
Software, aber wirklich nachprüfen lässt sich das nicht. Fragen, wie zum Beispiel, ob die verwendeten Verschlüsselungsund Authentifizierungsverfahren korrekt implementiert sind
und ob sich nicht vielleicht in der Software eine Backdoor
oder ein Trojaner befindet, können nicht zufriedenstellend beantwortet werden. Für Wissenschaftler aber ist der größte Negativpunkt, dass sie nicht auf die Erfahrungswerte von Skype
im Umgang mit sehr großen Peer-to-Peer-Netzwerken für ihre
eigene Forschung zugreifen können. Hinsichtlich zukünftiger
Forschungsarbeiten ist einiges zu tun: Die in diesem Paper
zusammengefassten Ergebnisse wurden mit alten Versionen
von Skype gesammelt und sind nicht mehr aktuell. Diese gilt
es aufzufrischen, aber auch neue Aspekte, wie zum Beispiel
ob Zentralität im Skype-Netzwerk eine immer größere Rolle
spielt, sollten geklärt werden. Hinweise darauf gibt es, da sich
ein Benutzer an mehreren SCs gleichzeitig anmelden kann,
aber alle Anrufe und Messages an jedem angemeldeten SC
erhält. Die Technik, welche zur Replikation eines Ereignisses
auf mehreren SCs genutzt wird, ist völlig unbekannt.
Natürlich ist es zu verstehen, dass ein Unternehmen sein
Know-How schützen möchte. Es wäre jedoch sehr wünschenswert, wenn Skype sich gegenüber den Benutzern und vor
allem gegenüber den Forschern auf dem Gebiet Peer-to-PeerSysteme offener zeigen würde. Auch Skype könnte von diesem
Prozess profitieren, da sich das Vertrauen in die Software
steigern würde und auch Skype selbst von Forschungsergebnissen anderer Wissenschaftler, basierend auf den eigenen
Erfahrungen und Ergebnissen, Mehrwert schaffen könnte.
C. Peer-to-Peer Key Agreement
Um den Austausch von Daten zwischen 2 Knoten zu
verschlüsseln, wird zu Beginn einer neuen Session zwischen
zwei SCs, A und B, ein 256-bit Session-Key, SKAB , ausgehandelt. Dabei folgen beide einem nicht weiter bekannten
Key-Agreement-Protokoll, im Zuge dessen die Identität von
A und B verifiziert und SKAB festgelegt wird. Dieser SKAB
existiert solange, wie Daten zwischen A und B ausgetauscht
werden und noch kurze Zeit danach. Beim Schliessen eines
SCs wird der Session-Key gelöscht.
D. Verschlüsselung einer Session
Der komplette Verkehr einer Session ist verschlüsselt. Der
Klartext wird mit einem Geheimtextblock per XOR verknpüft,
der aus einem 256-bit-AES-Schlüssel generiert wird. Als
Schlüssel wird hier der vorher ausgehandelte Session-Key
SKAB benutzt. Wie in Abbildung 6 zu erkennen ist wird
auch die Kommunikation über einen dritten SC, der als Proxy
dient, Ende-zu-Ende verschlüsselt. Der Proxy-Knoten kann die
Datenpakete nicht lesen, da er nicht im Besitz des zwischen
A und B ausgehandelten Session-Key SKAB ist.
3S
SN
Internet
B. Registrierung
Mit Hilfe der Hashfunktion H wird der zum von Benutzer A
gewählten Passwort PA korrespondierende Hashwert berechnet
Während der erstmaligen Registrierung eines Benutzers A
am LS erstellt dieser für A ein „Identity Certificate“(IC),
welches zur Authentifizierung zwischen SCs dient: Mit Hilfe
der Hashfunktion H wird der zum von Benutzer A gewählten
Passwort PA korrespondierende Hashwert berechnet und auf
dem Client als H(PA ) gesichert. Dann erstellt der SC ein RSAKey-Paar SA und VA 3 . Danach stellt der SC eine mit 256-bitAES-Verschlüsselung gesicherte Verbindung zu dem LS her
und verifiziert diesen. Im nächsten Schritt sendet der SC A,
H(PA ) und VA an den LS. Daraus generiet der LS ein IC
und sendet es zurück an den SC [1]. Abbildung 5 visualisiert
diesen Ablauf in zusammengefasster Form.
sel
Public IP
Angerufener
repräsentiert hier den privaten Schlüssel und V den öffentlichen Schlüs-
45
L ITERATUR
[1] Tom Berson. Skype security evaluation, 2005.
[2] Marina del Rey. Transmission control protocol. Technical report,
Information Sciences Institute, University of Southern California, 1981.
[3] Biondi; Desclaux. Skype fingerprint. BlackHat Europe, March 2006,
2006.
[4] Prof. Dr. Evren Eren Dr. Kai-Oliver Detken. Voip-security - standards,
evaluierung und konzeptbeispiele anhand von asterisk, 2007.
[5] Ebay. Q3 09 financial highlights. Website, 2009. http://www.scribd.com/
doc/21415469/eBay-Q309EarningsSlides-FINAL; Seite 15; besucht am
01.02.2011.
[6] Bonfiglio; Mellia; eMeo; Rossi; Tofanelli. Revealing skype traffic: When
random. SIGCOMM’07, August 2007, 2007.
[7] Robert Fehrmann. Your are skyping - but how does it work? Seminararbeit - FU Berlin, 2010.
[8] Branch; Heyde; Grenville. Rapid identification of skype traffic flows.
International Workshop on Network and Operating System Support for
Digital Audio and Video, 2009.
[9] R. Mahy J. Rosenberg et al. Stun - session traversal utilities for nat.
Technical report, Network Working Group, 2008.
[10] Guha; Daswani; Jain. An experimental study of the skype peer-to-peer
voip system. Proc. of IPTPS, 2006.
[11] Ehlert; Petgang. Analysis and signature of skype voip session traffic.
CIIT 2006: 4th IASTED International Conference on Communications,
Internet, and Information Technology, 2007.
[12] J. Postel. User datagram protocol. Technical report, ISI, 1980.
[13] J. Rosenberg R. Mahy, P. Matthews. Traversal using relays around nat
(turn). Technical report, Internet Engineering Task Force (IETF), 2010.
[14] Baset; Schulzrinne. An analysis of the skype peer-to-peer internet
telephony protocol. Proceedings IEEE INFOCOM 2006. 25TH IEEE
International Conference on Computer Communications, 2005.
[15] Skype. Skype Blog: http://blogs.skype.com/de/2010/11/wir_feiern_25_
millionen_gleich.html, besucht am 14.02.2011.
[16] Skype.
available at http://www.skype.com/intl/de/security/
detailed-security/; visited on February 1st 2011.
[17] Skype. P2p telephony explained — for geeks only. Website, 2010. http:
//www.skype.com/intl/en-us/support/user-guides/p2pexplained/; besucht
am 01.2.2011.
46
~
~
1
ÜBERSICHT ÜBER DATENORIENTIERTE NETZWERKLÖSUNGEN
Übersicht über datenorientierte Netzwerklösungen
Bastian Laur
Abschließend werden die
zusammengefasst präsentiert.
Zusammenfassung—Heutzutage wird das Internet hauptsächlich
genutzt um Daten wie Websites, Musik und Filme zu beziehen.
Dafür war es jedoch bei seiner Entstehung nicht gedacht. Das
Ergebnis sind zahlreiche Ad-hoc-Protokolle und -Architekturen.
Diese aus der Not entstandenen Lösungen haben viele Wissenschaftler motiviert Forschungen anzustellen und Ansätze zu
entwickeln, die das Internet den aktuellen Bedürfnissen der
Benutzer anpasst.
In diesem Text wird eine Übersicht der aktuell populärsten
Lösungsansätze vorgestellt.
Ergebnisse
des
Vergleichs
II. Ü BERBLICK ÜBER DIE A RCHITEKTUREN
In diesem Kapitel geht es darum, einen Einblick in die jeweiligen Ideen und Strukturen der einzelnen Architekturen zu
geben. Die Architekturen werden der Reihe nach vorgestellt,
wobei jeweils zuerst die Idee und anschließend die Struktur
beschrieben wird.
Es wird unbedingt empfohlen dieses Kapitel vor den Folgenden zu lesen, da hier Basiswissen vermittelt wird, das für
die Kapitel 3 bis 5 benötigt wird. Andernfalls kann es zu
Verständnisproblemen kommen.
I. E INLEITUNG
Das Internet stellt zurzeit wohl das wichtigste
Kommunikationsmittel der modernen Gesellschaft dar.
Sowohl Firmen als auch Privathaushalte benutzen es um
untereinander zu kommunizieren und sich zu informieren.
Dabei ist das Datenvolumen in den vergangen Jahren drastisch
gestiegen. Wurden vor einigen Jahren lediglich Texte über
das Internet verschickt, handelt es sich heutzutage bereits
um ganze Filme. Und die Zukunft lässt noch größere Inhalte
wie 3D-Filme, virtuelle Arbeitsplätze und Onlinespiele mit
High-End Grafik vermuten.
Dabei ist es für Benutzer meist uninteressant von welcher
Quelle sie ihre Daten beziehen, so lange sie sich sicher sein
können, dass die Verbindung sicher und die Daten sowohl
verifiziert als auch authentifiziert sind.
Der Benutzer legt also primär Wert auf die Daten an sich und
nicht deren Herkunft.
Das Internet dagegen wurde für Client-Server Verbindungen
mit festgelegten Endpunkten entworfen. Es wird also primär
auf die Herkunft der Daten und nicht auf deren Inhalt
geachtet.
Diese Diskrepanz hat viele Wissenschaftler motiviert,
datenorientierte Netzwerklösungen für ein modernes,
angepasstes Internet zu entwickeln.
Die Lösungsansätze „Content-Centric Networking“ (CCN)
[9], „A Data-Oriented (and Beyond) Network Architecture“
(DONA) [8], „An Architecture for Content Routing Support
in the Internet“ (CR) [7], „Freenet: A Distributed Anonymous
Information Storage and Retrieval System“ (Freenet) [6] und
„The Publish/Subscribe Internet Routing Paradigm“ (PSIRP)
[12] werden in diesem Text vorgestellt.
Dabei werden die einzelnen Lösungsansätze und ihre
Funktionsweise zunächst im zweiten Kapitel vorgestellt.
Anschließend werden sie in den Kapiteln 3-5 jeweils auf
einen speziellen Aspekt hin untersucht.
Das dritte Kapitel beschäftigt sich damit, wie Benutzer Daten
im Internet finden.
Das vierte Kapitel beschäftigt sich damit, wie die Daten
anschließend vom Host zum Client transferiert werden.
Das fünfte Kapitel beschäftigt sich damit, wie neue Daten in
das Netz eingespeist und publiziert werden.
A. CCN
CCN ist eine Netzwerkarchitektur bei der Daten und nicht
Hosts adressiert werden. Um das zu realisieren, werden sogenannte CCN-Knoten, Interest- und Data-Pakete eingeführt.
Ein Interest-Paket spiegelt eine Datenanfrage wider. Will ein
Client also Daten beziehen, sendet er ein Interest-Paket, dass
den Namen der Datei und eventuelle Filter enthält.
Ein Data-Paket ist die Antwort auf ein Interest-Paket. Es enthält ebenfalls den Namen der Datei, dazugehörige Signaturen
und natürlich den Inhalt.
Abbildung 1.
Data- und Interest-Paket [9]
Ein CCN-Knoten ist ähnlich wie ein IP-Router und verfügt
über eine Forwarding Information Base (FIB), einen Content
Store und eine Pending Interest Table (PIT).
Die FIB wird genutzt um Interest-Pakete an potentielle Datenquellen weiterzuleiten. Sie funktioniert ähnlich wie eine IP
FIB, allerdings können hier mehrere Datenquellen pro Name
gespeichert werden.
Der Content Store ist äquivalent zum Puffer Speicher eines
IP-Routers, bedient sich allerdings einer anderen Ersetzungsstrategie.
Während IP-Router eine MRU Ersetzungsstragie verfolgen,
47
2~
Will ein Benutzer heutzutage eine Datei beziehen, kennt er
von ihr in der Regel lediglich die URL. Diese wird dann
an den nächsten Root-Nameserver gesendet, um die Adresse
des zuständigen DNS-Servers zu erhalten, z.B. microsoft.com.
An Diesen wird anschließend wieder eine Anfrage gesendet,
um die Adresse eines nahe gelegenen Servers zu erhalten,
der die benötigten Daten enthält. Nun können die Daten
angefragt werden. Abbildung 3 veranschaulicht das Vorgehen
nocheinmal.
orientiert sich der Content Store am LRU oder LFU Algorithmus. MRU wäre nicht sinvoll, da der CCN-Knoten immer
über möglichst aktuelle Daten verfügen soll.
In der PIT wird gespeichert, welche Interest-Pakete an welche
Adressen weitergeleitet wurden.
Abbildung 2.
CCN-Knoten [9]
Abbildung 3.
B. DONA
CCN-Knoten [7]
Beim Content Routing dagegen gibt es sogenannte ”Content
Router” (CR). Diese können als normale IP-Router benutzt
werden, haben aber darüber hinaus noch eine Routing Tabelle
in der Name-To-Next-Hop Einträge gespeichert sind. So kann
ein Client eine URL direkt an den nächsten CR senden. Dieser
extrahiert aus der URL die Serverkomponente und sucht in
seiner Routing Tabelle den ”besten” benachbarten CR um die
Anfrage effizient weiter zu leiten.
Durch diese Konstruktion entfällt das initiale Auflösen einer
URL komplett. Des Weiteren können die CRs selbstständig
entscheiden, von wo die Daten am Effizientesten bezogen
werden. Will ein Client z.B. ein Video von youtube.com beziehen, können zwischenliegende CRs entscheiden, ob sie die
Anfrage an youtube1.com, youtube2.com oder youtube3.com
weiterleiten.
DONA schlägt eine komplett neue Namensgebung innerhalb
des Internets vor. Dazu führt es sogenannte DONA-Namen
ein.
Sie sind flach, selbstzertifizierend und jede Datei, jeder Service, Host, jede Domain usw. verfügt über einen. Jeder Name
hat einen Namensvorsteher, der für jede seiner Dateien einen
öffentlichen und einen privaten Schlüssel besitzt.
DONA-Namen haben die Form P:L, wobei P der Hashwert
des Namenvorstehers ist und L der Name der Datei.
Beispiel: ”SHA-1(Bastian Laur):p2pReferat.txt”. Um die globale Einzigartigkeit des Namens muss sich der Namensvorsteher kümmern. Ebenso bestimmt er die Granularität der Namen
und welche Server seine Daten anbieten dürfen.
Granularität meint hier, dass der Vorsteher bei einer Webpräsenz z.B. lediglich der kompletten Website einen Namen gibt.
Er könnte aber auch jede Unterseite einzeln benennen.
Welche Server die Daten des Vorstehers anbieten dürfen,
bestimmt dieser, indem er sie dazu explizit mittels eines
REGISTER Befehls autorisiert (siehe Abschnitt V.B).
Des Weiteren gibt es einen FIND Befehl, mit dem Benutzer Daten anfordern können (siehe Abschnitt IV.B). Treffen
anschließend die Daten ein, handelt es sich dabei immer um
Tripel der Form <Inhalt, Öffentlicher Schlüssel des Vorstehers,
Signatur des Vorstehers>.
Statt auf DNS-Servern beruht DONA auf einer neuen Art
von Knotenpunkten. Den sogenannten ”Resolution Handlers”
(RHs). Diese sind für die Verarbeitung der FIND und REGISTER Befehle zuständig.
D. Freenet
Bei Freenet handelt es sich um die Idee eines verteilten
Informationsspeichers, bei dessen Design besonderen Wert
auf die Privatsphäre der Benutzer und die Verfügbarkeit von
Daten gelegt wurde.
Um genau zu sein hat Freenet fünf große Ziele:
C. Content Routing
Die Content Routing Architektur adressiert speziell das Problem des Routings.
48
•
Anonymität sowohl für die Ersteller als auch
Konsumenten der Daten soll gewährleistet werden
•
Die Quelle einer Datei soll bei Bedarf unerkannt bleiben
können
•
Dritten soll es nicht möglich sein den Zugang zu Daten
zu blockieren
~
3
•
•
Das Speichern und Routen von Daten soll dynamisch
und effizient sein
Familienmitgliedern bzw. Arbeitskollegen zugänglich.
Jeder Bereich ist mit einer Datei assoziiert, in der gespeichert
ist, welche Daten in ihm verfügbar sind und in welchem
Unterbereich diese liegen.
Das Internet kann bei PSIRP als azyklischer Graph von in
Beziehung stehenden Daten betrachtet werden. Jede davon
wird durch verschiedene Bezeichner identifiziert und einem
Bereich zugeordnet. Die Bezeichner bestimmen die Beziehung
der Daten zueinander auf den verschiedenen Ebenen (z.B.
Anwendungsebene und Netzwerkebene).
Die Bezeichner sind:
• Application Identifiers (AID): Wird direkt von Autor und
Abonnent genutzt und ist der Bezeichner einer Anwendung.
• Rendezvous Identifiers (RID): Wird genutzt um Bezeichner der höheren Ebenen mit den Bezeichnern von niedrigeren Ebenen zu verbinden. Kann auch als Bezeichner
einer Datei auf der Netzwerkebene angesehen werden.
• Scope Identifiers (SID): Der Bezeichner eines Bereichs.
Er wird genutzt um die Erreichbarkeit von Daten zu
begrenzen.
• Forwarding Identifiers (FID): Der Bezeichner eines oder
mehrerer Knotenpunkte. Er wird genutzt um den Pfad
von Daten zu bestimmen. Es kann sich lediglich um
den nächsten Knotenpunkt oder um ganze Bäume für
Multicasts handeln.
Jede Datei verfügt typischerweise über mindestens einen AID
und mindestens einen SID. Eine Anwendung löst zunächst den
AID in einen RID auf. Dieser RID wird anschließend dem
Netzwerk übergeben. Da eine Datei immer in einem Bereich
liegen muss, ist ein RID auch immer mit einem SID assoziiert.
Aus diesem lässt sich dann ein FID ermitteln. In diesem kann
die Adresse des nächsten Routers oder auch ein ganzer Pfad
gespeichert sein.
Somit wird zum Anfordern von Daten nicht mehr die IP
Adresse des Endpunktes benötigt. Sämtliche Kommunikation
erfolgt direkt über den Dateinamen bzw. den RID.
Auf diesem Paradigma soll die komplette Komunikation des
Internets aufbauen.
Alle Netzwerkfunktionen sollen dezentral sein.
Freenet ist als ein adaptives Peer-To-Peer Netzwerk aufgebaut,
das aus Knoten besteht, die untereinander Nachrichten
versenden um Daten zu erhalten oder zu speichern.
Jeder Knoten verfügt über einen lokalen Datenspeicher und
eine dynamische Routing Tabelle, in der gespeichert ist,
welche Knoten über welche Daten verfügen.
Daten werden über Schlüssel identifiziert. Um den Schlüssel
einer Datei zu bestimmen gibt es drei Möglichkeiten.
1) Keyword-Signed Key (KSK)
Der Name der Datei wird gehasht. Das Ergebnis bildet den
Schlüssel der Datei.
2) Signed-Subspace Key (SSK)
Da die Methode aus 1) schnell zu Kollisionen führen kann,
hat jeder Bereitsteller von Daten die Möglichkeit einen
eigenen Namensraum zu definieren, unter dem er seine Daten
veröffentlicht. Bei Bedarf können auch mehrere Namensräume
definiert und so Ordnerstrukturen abgebildet werden.
Um den Schlüssel einer Datei zu ermitteln hasht man zunächst
den Bezeichner des Namenraums und den Bezeichner der
Datei. Die beiden Hashwerte werden anschließend mit einer
weiteren Hashfunktion vereinigt. Das Ergebnis dieser letzten
Berechnung bildet den Schlüssel der Datei.
3) Content-Hash Key (CHK)
Wie der Name schon sagt, wird hier nicht der Bezeichner,
sondern der Inhalt einer Datei gehasht. Das Ergebnis bildet
den Schlüssel der Datei.
Zum Hashen wird z.Zt. ein 160 Bit SHA-1 Algorithmus
verwendet.
E. PSIRP
III. AUFFINDEN VON DATEN
Bei PSIRP handelt es sich um eine schichtenlose Architektur.
Hinter ihr steht die Idee, dass eines der größten Probleme des
derzeitigen Internets das zu große Vertrauen in den Sender von
Informationen ist. Das Netzwerk leitet alles weiter, was der
Sender sendet. So kommt es zu Problemen wie Spam Mails
und Distributed Denial of Service Attacken.
Deshalb verfolgt PSIRP ein Publish/Subscribe Paradigma, bei
dem Sender Daten lediglich publizieren und nicht senden
können. Empfänger können diese Daten abonnieren (z.B. bei
Programmupdates).
Zur besseren Strukturierung der Daten soll das Internet in
Bereiche unterteilt werden, die zur Einteilung von Daten
dienen und Zugriffsbeschränkungen ermöglichen. Zum Beispiel könnte ein Server einen Bereich ”Familie” und einen
Bereich ”Arbeit” einrichten. Diese enthalten dann entsprechend nur familienrelevante Daten (z.B. Familienfotos) bzw.
arbeitsrelevante Daten (z.B. Sitzungsprotokolle) und sind nur
In diesem Kapitel geht es darum, wie die einzelnen Architekturen mit der Anfrage eines Clients nach einer oder mehreren
Dateien umgehen.
Dabei wird davon ausgegangen, dass ein Client den Bezeichner
der Datei kennt, unabhängig davon, ob es sich dabei um
eine URL, einen Hashwert, einen eindeutigen Namen oder
sonstiges handelt. Mit Hilfe dieses Bezeichners, wird eine
architekturspezifische Anfrage gesendet. Um den anschließenden Algorithmus zu erläutern, reicht es meistens aus den
Ablauf im nächsten Knotenpunkt zu erläutern. Der Ablauf
in den anderen Knotenpunkten verläuft dann äquivalent oder
eventuell auch rekursiv.
Ist die Anfrage beim entsprechenden Server angelangt und
die Daten sind bereit zum Übertragen, gilt dieses Kapitel als
abgeschlossen. Wie die Daten anschließend vom Host zum
Client übertragen werden, wird im nächsten Kapitel behandelt.
49
4~
A. CCN
Will ein Client Daten finden, muss er per Broadcast ein
Interest-Paket verschicken. In diesem ist unter anderem der
Name der gesuchten Daten enthalten.
Da jeder CCN-Knoten über einen lokalen Speicher verfügt, in
dem er Daten zwischenspeichern kann, überprüft er, sobald er
ein Interest-Paket empfängt, ob sich die angeforderten Daten
bereits in seinem lokalen Speicher befinden.
Wenn ja, sind die Daten gefunden und können an den Client
zurück gesendet werden. Das Interest-Paket wird anschließend
verworfen.
Liegen keine entsprechenden Daten im Speicher des CCNKnotens vor, geht er seine Pending Interest Table (PIT) durch,
in der alle weitergeleiteten Interest-Pakete gespeichert sind.
Findet er in der Liste einen Client, der bereits die gleichen
Daten angefragt hat, verwirft er die Anfrage und erstellt dafür
einen weiteren Eintrag in der PIT.
Da zwei Clients die gleiche Datei angefragt haben, wäre es eine Ressourcenverschwendung beide Anfragen weiterzuleiten.
Stattdessen leitet der Knoten nur die erste Anfrage weiter und
speichert die zweite Anfrage. So kann er bei einer Antwort
diese vervielfältigen und an alle Interessierten weiterleiten.
Liegt auch in der PIT kein entsprechender Eintrag vor, leitet
der CCN-Knoten das Paket an den entsprechenden Eintrag der
Forwarding Information Base (FIB) weiter. Ist kein entsprechender Eintrag vorhanden leitet er das Paket an alle seine
Nachbarn, ausgenommen den Client selbst weiter und erstellt
einen entsprechenden Eintrag in der PIT. Sollte nach dem
Ablauf einer gewissen Zeitspanne keine Antwort kommen,
wird der Eintrag wieder aus der PIT entfernt.
Abbildung 4.
Möglicher Weg einer FIND-Anfrage [8]
hat jeder CR eine Menge von Name-To-Next-Hop Einträgen.
Dieses geht der CR durch und bestimmt so, an welchen Hop
er die Anfrage weiterleiten muss.
Abbildung 5.
B. DONA
Routing [7]
Erreicht die Anfrage einen CR der direkt mit dem Zielserver
verbunden ist, antwortet dieser mit der Adresse des Zielservers. Dabei geht die Antwort den gleichen Weg wieder zurück.
Kommt nach einer gewissen Zeitspanne keine Antwort von
dem CR oder Server an den die Anfrage weitergeleitet wurde,
geht der CR von einem Fehler aus und die Verbindung wird
dann als nicht mehr gültig betrachtet.
Die Anfrage kann anschließend zu einem alternativen CR
oder Server weitergeleitet werden. Da immer nur zu Servern und nicht zu deren Inhalt geroutet wird müssen dadurch eventuell Ordnerstrukturen in die Server URL eingebunden werden. Aus http://foo.com/bar/index.html wird somit
http://bar.foo.com/index.html
Will ein Client Daten finden, benötigt er dafür den entsprechenden DONA-Namen. Diesen sendet er verbunden mit einer
FIND-Anfrage an den nächsten Resolution Handler (RH).
Erhält der RH die Anfrage, prüft er in seiner RegistrationTable, wie weit es von ihm aus bis zu der angeforderten Datei
ist und den nächsten RH.
Um die Entfernung anzugeben gibt es verschiedene Möglichkeiten, wie die Anzahl der zwischen liegenden Hops, die RTT
(Round-Trip-Time) oder auch die physische Entfernung.
Anschließend wird die Anfrage an den nächsten RH weitergeleitet.
Liegen mehrere Einträge mit identischer Entfernung vor, ist es
dem RH überlassen, welchen er zur Weiterleitung wählt.
Liegt kein entsprechender Tabelleneintrag für den DONANamen vor, leitet der RH die Anfrage an seinen Parent,
sprich den in der AS-Hierarchie übergeordneten RH (z.B. der
Provider) weiter.
Die FIND-Anfrage des Clients enthält neben der angefragten
Datei auch dessen Domain-Namen. Gelangt die Anfrage zu
einem RH oder Server, fügen diese ihre eigenen DomainNamen an den des Clients an.
D. Freenet
Benötigt ein Client Daten, benötigt er zuerst deren Keys. Diese
Keys bzw. diesen Key sendet er, verbunden mit einem Hopsto-live Limit an den nächsten Router, der zunächst prüft, ob die
Datei bereits in seinem lokalen Speicher vorhanden ist. Ist die
Prüfung erfolgreich, antwortet er mit der Datei. Andernfalls
leitet er die Anfrage an den Router weiter, der am nächsten an
der angeforderten Datei liegt. Dazu sucht er in seiner Routing
Tabelle den Key, der dem angeforderten am nächsten kommt
und leitet die Anfrage an den zugehörigen Router weiter.
Antwortet der Router an den die Anfrage weitergeleitet wurde
C. Content Routing
Benötigt ein Client Daten, sendet er eine Anfrage an den
nächsten Content Router (CR). Wie die RHs von DONA
50
~
5
nicht, oder mit einem Fehler, wird die Anfrage an einen
alternativen Router weitergeleitet.
Das gleiche passiert, wenn durch das Weiterleiten die Anfrage
wieder zum Sender gelangt, also eine Schleife entsteht.
Haben alle Kandidaten zu einem Fehler oder einer Schleife
geführt, gibt der Router einen Fehler zurück.
Abbildung 7.
Zusammenarbeit der PSIRP-Komponenten [12]
IV. B EZIEHEN VON DATEN
In diesem Kapitel geht es um alles, was auf das „Auffinden von
Daten“ folgt. Der Schwerpunkt liegt dabei, wie die Antwort
des Servers den Weg zurück zum Client findet. Also wie die
Knotenpunkte mit der Antwort auf die Anfrage umgehen, die
sie soeben weitergeleitet haben.
Abbildung 6.
A. CCN
Erhält ein CCN-Knoten ein Interest-Paket und kann die Anfrage befriedigen, verwirft er das Interest-Paket und antwortet
dem Absender mit einem entsprechenden Data-Paket.
Handelt es sich bei dem Absender um den Client ist der
Vorgang beendet. Handelt es sich bei dem Absender um einen
weiteren CCN-Knoten, prüft dieser anhand seiner PIT-Tabelle
an wen das Data-Paket weitergeleitet werden muss.
Haben mehrere Clients bei ihm die gleichen Daten angefragt,
vervielfältigt der Knoten das Paket und leitet dieses an alle
wartenden Clients bzw. CCN-Knoten weiter (Multicast). Der
bzw. die betreffenden PIT Einträge werden anschließend gelöscht.
Der Hinweg des Interest-Pakets ist also der Rückweg des DataPakets.
Routing [6]
Ist die Datei gefunden, wird sie über den gleichen Weg zurück
geleitet. Dabei kopieren sich alle Router, die auf dem Weg
liegen die Datei in ihren lokalen Speicher und tragen einen
entsprechenden Eintrag in ihre Routing Tabelle ein.
B. DONA
Erhält ein Server eine FIND-Anfrage, ist in dieser nicht nur
der Name der gesuchten Datei, sondern auch der akkumulierte
Pfad den die Anfrage gegangen ist, enthalten.
Diesen dreht der Server um und gibt ihn seiner Antwort mit.
Bekommt ein RH so eine Antwort, bestimmt er die Position
seines Domain-Namens in dem Pfad und kann daraufhin den
nächsten RH identifizieren.
Der Pfad bleibt dabei vollständig erhalten. Denn diesen kann
der Client wiederum umdrehen und für seine Antwort an den
Server verwenden.
E. PSIRP
Benötigt ein Client Daten, braucht er dazu deren Rendezvous
Identifiers (RIDs). Diese kann er über Freunde, Suchmaschinen, Webseiten, usw. erhalten. Die RID wird an den Router
gesendet, der für den Bereich des Clients zuständig ist.
Aus der RID kann man den Bereich bestimmen, in dem die
Datei liegt. Für diesen Bereich bestimmt der Router dann
einen Forwarding Identifier (FID), mit dem er die Anfrage
weiterleitet. In dem FID könnte lediglich der nächste Hop aber
auch der komplette Pfad zur Datei enthalten sein.
C. Content Routing
Stellt ein Client eine Datenanfrage an seinen nächsten CR,
erhält er als Antwort die Adresse der Daten.
Diese kann er anschließend beliebig verwenden, um auf die
Daten z.B. mittels HTTP- oder FTP-Verbindung zuzugreifen.
51
6~
D. Freenet
kann. Die Adresse kann dann über Suchmaschinen, Links,
Foren, Social Networks, usw. bekannt gemacht werden. Da
die Adresse des Servers bereits in den Routern gespeichert
ist, sind hier keine weiteren Modifikationen nötig.
Erhält ein Router/Server eine Datenanfrage, die er befriedigen
kann, Antwortet er mit der gewünschten Datei.
Die Antwort geht dabei den gleichen Pfad zurück, den die
Anfrage gekommen ist. Sämtliche Router, die auf dieser Strecke liegen, kopieren sich die Antwort, also die Datei, in ihren
lokalen Speicher. So können sie bei einer erneuten Anfrage
direkt mit der Datei antworten.
Gegebenenfalls wird auch die Routing-Tabelle aktualisiert,
falls zunächst erfolglos probiert wurde, die Datei von anderen
Routern zu beziehen.
D. Freenet
Will ein Benutzer neue Daten veröffentlichen, muss er zunächst einen zugehörigen binären Schlüssel, wie in II.D beschrieben, erstellen.
Anschließend sendet er eine Pre-Insert Nachricht, die den
Schlüssel und einen Hops-to-live Wert enthält, an den nächsten
Router. Der Hops-to-live Wert gibt hier an, bis zu welcher
Tiefe der Router die Datei verteilen soll.
Erhält der Router die Nachricht, behandelt er sie ähnlich wie
eine normale Suchanfrage. Zunächst prüft er, ob der Schlüssel
bereits in seiner Storage Table vorhanden ist. Wenn vorhanden,
sendet er die Datei als Antwort. So weiss der Benutzer, dass
eine Kollision aufgetreten ist und er einen neuen Key wählen
muss.
Ist der Key nicht im Storage-Table vorhanden wird die Nachricht wie eine Suchanfrage an andere Router weitergeleitet, die
ebenfalls mit der Datei antworten, wenn eine Kollision auftritt.
Ist das Hops-to-live Limit erreicht und es wurde keine Kollision entdeckt, bekommt der Benutzer eine ”all clear” Nachricht.
Das bedeutet für ihn, dass sein gewählter Schlüssel noch nicht
vergeben ist und er beginnen kann die Daten hinzuzufügen.
Dazu sendet er wieder den Schlüssel und Hops-to-live Wert.
Diesmal als Insert Nachricht. Die Insert Nachricht geht die
gleichen Wege, wie die Pre-Insert Nachricht. Nun betrachten
die auf dem Weg liegenden Router die Nachricht jedoch nicht
als Anfrage, sondern als Antwort. Demzufolge speichern sie
die Datei in ihrem lokalen Speicher und aktualisieren ihre
Routing Tabellen. Damit gilt die Datei als hinzugefügt.
E. PSIRP
Stellt ein Client eine Datenanfrage, hinterlässt diese eine
”Brotkrumenspur” bei den Routern, die die Anfrage weitergeleitet haben. Über diese Spur wird die Antwort wieder zurück
geleitet.
V. H INZUFÜGEN VON DATEN
A. CCN
Erhält ein Server bzw. CCN-Knoten neue Daten, bleibt diese
Information der restlichen Welt zunächst unbekannt. Dadurch
können Server beliebig viele neue Daten aufnehmen, ohne dass
das Netzwerk unnötig belastet wird, wenn keine Clients an den
Daten interessiert sind.
Sind die Daten jedoch für die restliche Welt von Interesse,
wird es nicht lange dauern bis verschiedene Clients diese
anfragen. Sobald ein Client die neuen Daten anfragt, werden
diese per Broadcast gefunden und wie unter IV.A beschrieben,
übermittelt.
Beim Übermitteln des Data-Pakets trägt sich jeder CCNKnoten, der auf dem Pfad liegt in seine FIB-Tabelle ein, von
wo er eine Antwort auf die Anfrage bekommen hat.
So kann der Knoten eine erneute Anfrage gezielt weiterleiten.
E. PSIRP
In der zugehörigen Quelle finden sich hierzu keine speziellen
Angaben.
Allerdings lässt die Architektur darauf schließen, dass ein Server wie gewohnt Daten seinem lokalen Speicher hinzufügen
kann. Die Adresse kann dann über Suchmaschinen, Links,
Foren, Social Networks, usw. bekannt gemacht werden. Da der
zugehörige Bereich des Servers bereits den Routern bekannt
ist, sind hier keine weiteren Modifikationen nötig.
B. DONA
Hat ein Server ein Upate oder eine neue Datei erhalten, die
veröffentlicht werden soll, schickt er einen REGISTER-Befehl
an seinen lokalen RH.
Vorausgesetzt der REGISTER-Befehl weist auf eine neue
Datei oder einen kürzeren Weg zu einer bereits bekannten
Datei hin, aktualisiert der RH seine Registration-Table und
leitet den Befehl an seinen Parent und alle seine Peers weiter,
was ein rekursives Update der einzelnen RHs zur Folge hat.
Sollte eine Weiterleitung an den Parent oder bestimmte Peers
nicht erwünscht sein, kann dies im REGISTER-Befehl vermerkt werden.
Ist die Datei, die registriert werden soll bzw. ein kürzerer Weg
zu ihr dem RH bereits bekannt, wird der Befehl verworfen.
VI. FAZIT
Der Vergleich der verschiedenen Architekturen zeigt, dass
es bereits einige vielversprechende Ansätze gibt, um einige
der derzeitigen Probleme des Internets zu lösen. Dabei haben
verschiedene Architekturen verschiedene Schwerpunkte.
Bei CCN fällt auf, dass man eine Datei von mehreren Quellen
gleichzeitig beziehen kann, DONA will das Namenssystem
des Internets revolutionieren, Freenet bemüht sich stark um
die Privatsphäre der Nutzer, Content Routing sieht die Latenz
beim Umwandeln einer URL in eine IP Adresse und die
damit verbundene Anfrage bei einem DNS Server als eines
der größten Probleme an.
C. Content Routing
In der zugehörigen Quelle finden sich hierzu keine speziellen
Angaben.
Allerdings lässt die Architektur darauf schließen, dass ein Server wie gewohnt Daten seinem lokalen Speicher hinzufügen
52
~
7
Doch trotz der unterschiedlichen Ansätze fiel beim Vergleich
auf, dass zwei grundsätzliche Ideen immer wieder aufgegriffen
wurden. Zum einen der Gedanke, dass die zwischen Client und
Host liegenden Entitäten Daten zwischenspeichern können, um
bei einer erneuten Anfrage direkt mit den geforderten Daten
antworten zu können und so das restlichen Netz zu entlasten.
Und zum andern die Idee, Daten global eindeutige Bezeichner
zu geben, die aber nur vom Inhalt und nicht vom Ort der Datei
abhängig sind, was beim momentanen System mit URLs nicht
gegeben ist.
Gerade der zweite Gedanke liegt nahe, wenn man Daten
auf mehrere Server verteilen aber trotzdem serverunabhängig
darauf zugreifen will.
Abschließend lässt sich feststellen, dass keiner der Ansätze
den Anspruch erhebt eine vollständige, implementationsfähige
und realistische Lösung zu sein. Die hohe Anzahl von Publikationen in den letzten Jahren lässt jedoch vermuten, dass
die Forschungen weiter gehen und die Lösungsansätze immer
präziser und umsetzungsfähiger werden.
L ITERATUR
[1] M. Alduán, F. Álvarez, Th. Zahariadis, N. Nikolakis, F. Chatzipapadopoulos, D. Jiménez, and J. Manuel Menéndez. Architectures for future
media internet. In 2nd International Conference on User Centric Media,
Palma de Mallorca, September 2010.
[2] Future Internet Assembly. Why do we need a Content-Centric Future
Internet? European Future Internet Portal, 2009.
[3] Hari Balakrishnan, Karthik Lakshminarayanan, Sylvia Ratnasamy, Scott
Shenker, Ion Stoica, and Michael Walfish. A Layered Naming Architecture for the Internet. In ACM SIGCOMM 2004, Portland, OR, September
2004.
[4] M. Caesar, T. Condie, J. Kannan, K. Lakshminarayanan, I. Stoica, and
S. Shenker. Rofl: Routing on flat labels. In ACM SIGCOMM 2006, Pisa,
Italy, 2006.
[5] D. Cheriton and M. Gritter. Triad: A new next-generation internet
architecture. In 3rd USENIX Symposium on Internet Technologies and
Systems, San Francisco, California, USA, March 2001.
[6] Ian Clarke, Oskar Sandberg, Brandon Wiley, and Theodore W. Hong.
Freenet: A distributed anonymous information storage and retrieval
system. Lecture Notes in Computer Science, 2009:46+, 2001. I, 6
[7] Mark Gritter. An architecture for content routing support in the internet.
In 3rd USENIX Symposium on Internet Technologies and Systems, San
Francisco, California, USA, March 2001. I, 3, 5
[8] T. Koponen (ICSI/HIIT), A. Ermolinskiy M. Chawla, B.-G. Chun,
K. H. Kim (UCB), S. Shenker (ICSI/UCB), and I. Stoica (UCB). A
data-oriented (and beyond) network architecture. In ACM SIGCOMM
2007, Kyoto, Japan, August 2007. I, 4
[9] V. Jacobson, D. Smetters, J. Thornton, M. Plass, N. Briggs, and
R. Braynard (Palo Alto Research Center). Networking named content.
In CoNEXT 2009, Rome, Italy, December 2009. I, 1, 2
[10] John Kubiatowicz, David Bindel, Yan Chen, Steven Czerwinski, Patrick
Eaton, Dennis Geels, Ramakrishna Gummadi, Sean Rhea, Hakim Weatherspoon, Westley Weimer, Chris Wells, and Ben Zhao. Oceanstore:
An architecture for global-scale persistent storage. In ASPLOS-IX Proceedings of the 9th International Conference on Architectural Support
for Programming Languages and Operating Systems, Cambridge, MA,
USA, November 2000.
[11] U. Lee, I. Rimac, and New Jesey U.S.A. V. Hilt (Bell Labs, AlcatelLucent. Greening the internet with content-centric networking. In eEnergy 2010, 1st International Conference on Energy-Efficient Computing and Networking, University of Passau, Germany, April 2010.
[12] Kari Visala Sasu Tarkoma, Mark Ain. The Publish/Subscribe Internet
Routing Paradigm (PSIRP): Designing the Future Internet Architecture,
pages 102–111. IOS Press, 2009. I, 7
[13] T. Zahariadis, P. Daras, J. Bouwen, N. Niebert, D. Griffin, F. Alvarez,
and G.Camarillo. Towards a Content-Centric Internet. IOS Press, April
2010.
53
~
1
TRAFFIC ANALYSIS OF P2P APPLICATIONS
Traffic Analysis of p2p Applications
The An Binh Nguyen
[19] discussed three reasons based on domain knowledge, why
it is necessary for P2P traffic analysis. First of all for network
operators, a large distributed amount of traffic from P2P may
reduce the performance of the whole network, which is why
network operators want to analyze and monitor behaviors of
such applications, in order to adjust network under different
circumstances. . Second of all, for P2P application designers,
it’s important for them to evaluate their implementation and
do improvements, so comes the role of P2P traffic analysis.
For end users it might be interesting to control incoming and
outgoing traffic of their systems, to be able to detect suspicious
attempts of P2P applications and also be able to balance load
in their local machine. In summary the quality of service, load
balancing, P2P based attack prevention and detection encourage the need of P2P analysis and monitoring. In the early
day, monitoring was often done in centralized manner, where
a centralized monitoring entity exists to monitor the network.
The scale of monitoring has now become larger. For a big scale
P2P network, a centralized scheme is inefficient. Usually a
decentralized or hybrid monitoring scheme is preferred in P2P
applications. Some approaches were introduced in [12] [20]
[1]. To detect particular behaviors of P2P networks, particular
metrics should be considered. Some of metrics can be named
such as: flow size, flow inter-arrival time, duration, number of
destination ports, traffic volume etc. In this paper we will see,
how these metrics are used in research works.
There have been many contributions in analyzing P2P
traffic. In this paper some methods will be considered and
reviewed to see the developments of P2P traffic analysis
methods and their future. In order to analyze P2P traffic the
first thing needs to be done is distinguish P2P traffic from the
other traffic. The first generation of P2P applications was not
so complex, they often used default ports and default protocols,
thus it was able to look into payload to determine P2P traffic.
This so-called payload based technique was mentioned in
[18] [13] [14] [2]. Through time P2P application got more
complex. They can even disguise themselves as usual traffic
by randomizing port or use default ports of other traffic. P2P
applications can also encrypt their transmitted content, so a
fully payload-based technique is not always possible. Using
payload-based technique we can detect known P2P traffic,
but to discover unknown P2P traffic and overcome many
disadvantages of payload-based non-payload-based techniques
are necessary. Non-payload techniques or heuristic based techniques are based on common behavior patterns to identify P2P
traffic due to nature of P2P. Common characteristics of P2P
traffic are, for instance the use of both TCP/UDP, same number
of distinct ports and destinations connect to host [13], [14],
peer node acts in both roles as “client“ and “server“ [6]. Other
approach based on machine learning to learn the behavior of
P2P traffic is applied in [8], but it is still in development and in
Abstract—The popularity of P2P applications is continued to
grow. Parallel to this growth, P2P protocols are getting more
complex. Nowadays the problem of Quality of Service is often
in question of P2P research field. A peer node has to store data,
receives queries from other peer nodes, and distributes its content
for other peers. Such processing peer node can generate bulky
traffic to the network. Also for each node we have to reserve
enough resources for this peer node to function. P2P is not only
used in many legal applications, but also finds its place for illegal
doing e.g., DDoS attack. The need of P2P application analysis
and traffic monitoring therefore have become mandatory. P2P
traffic needs to be analyzed in order to optimize load of P2P
traffic. When P2P node consumes too much resources, we need to
monitor P2P traffic and detect this problem in runtime, in order
to perform load balancing in right time and prevent corruption
of P2P networks. Monitoring P2P traffic also helps prevent
malicious attempt, for instance DDoS attack based on P2P. There
have been many works for P2P traffic analysis. This paper
considers some of them, describes their approaches and tries
to address advantages and disadvantages of each method. We
analyzed the approaches and believe that each approach can be
useful for a particular interest. Also machine learning would be
more important in the future for P2P traffic analysis. Monitoring
P2P traffic is still a challenge due to dynamic properties of P2P
networks, a great number of new P2P applications and the big
scale of the network. Monitoring of P2P is often decentralized. We
tend to believe hybrid approach (combination of both centralized
and decentralized) would be a good solution for P2P monitoring,
which compromise advantages of both centralized and distributed
monitoring scheme.
I. I NTRODUCTION
P2P is a network architecture, where a group of computer users can communicate with each other and directly
access files from other’s hard drive in a decentralized manner.
P2P introduces some advantages compared to other classic
architectures such as decentralized organizing systems, high
scalability. Therefore P2P has been widely used in many
applications for file sharing, content distribution (BitTorrent,
EMule etc.), chat, Voice over Internet protocol (VoIP) e.g.
Skype and also for malicious attempts, for instance malware
distribution (botnet) or DDoS. The growth of P2P implies a
lot of consequences. Basher et al. [4] analyzed network traffic,
which were generated from classic web applications and from
P2P applications. They found out that compared to web traffic,
P2P traffic contributes many large-sized and many small-sized
packets. P2P flows also last longer, inter-arrival time between
two P2P flows is longer than web traffic, packet size of P2P is
often larger [17]. These findings indicate, that a large amount
of network traffic is contributed by P2P traffic. This result is
confirmed in [2], [8], [10], [14], [18].
Due to decentralized manner, P2P might be deployed not
only to share illegal file contents, but also to attempt DDoS
attacks [7], [22]. Because of its complexity and widely used,
it has become mandatory to analyze P2P traffic. Torres et al.
54
2~
some cases inefficient. But use of machine learning to extract
traffic patterns of P2P can be further improved and would get
more efficient in the future.
The rest of the paper is structured as follows. The second
section will summarize analysis methods. This section contains
of three main parts, how P2P traffic can be identified, how can
we monitor P2P traffic and how P2P traffic were analyzed in
research papers. The third section will discuss the summaries
from this paper. The last section is the conclusion.
characteristics. These kinds are for the time being outside
scope of this paper, and should be considered in future papers.
For an overview of overlay characteristics of P2P streaming
applications refer in [21].
In order to identify P2P traffic, two main approaches are
possible. The paper will introduce 6 methods which will
be called MI1, MI1’, MI2 to MI5 (stand for Method for
Identification). Methods can be categorized as payload-based,
non-payload-based (or heuristic-based) and machine learning
technique. Payload-based technique is applied to identify traffic, where it is possible to look into the content of network traffic. Non-payload-based technique or heuristic-based technique
makes use of common characteristic to identify P2P traffic. A
classification of introduced methods and their category can be
found in Figure 1. MI1 and MI1’ are payload-based technique.
MI2 to MI4 are heuristic-based technique. The last introduced
method MI5 is machine learning technique. For further details
of each method, refer in next coming text.
II. A NALYSIS M ETHODS
A. P2P Traffic Identification
Although P2P applications are heterogeneous in term of
specification of their protocols, they still have many things in
common. The nature of P2P is equality among peers. In file
sharing P2P applications, each peer gets a part of wanted data
from other peers, and offers a part of this data for other peers
as well. It implies the roles of “server“ and “‘client“. A peer
must therefore satisfy the function of both roles. This nature
indicates some common characteristics of P2P applications.
These characteristics can be made used for identifying P2P
traffic, especially when it comes to unknown P2P protocols.
Some of the most used characteristics of P2P traffic can be
listed as followed:
• C1: Nowadays P2P applications use both TCP/UDP to
exchange control message and data. UDP is often used
for queries, control messages or responses, while TCP
is often used for transmission. Because of that IP pairs
which use both TCP/UDP should be the first candidate
of P2P traffic network. This characteristic is widely used
in almost every heuristic based P2P identifying methods.
• C2: In many P2P applications the number of distinct ports
is equal to the number of distinct destinations, since peer
node often choses an arbitrary port to connect to other
nodes, which implies another heuristic for identifying
P2P flows.
• C3: Many P2P applications can disguise their used ports
as default ports from other web traffic. Still the difference
is web traffic tends to open many parallel connections
to host. On the contrary P2P data transmission consists
of many consecutive connections, there is at most one
connection at one time. Based on this heuristic it is able
to separate disguised P2P from web traffic
• C4: P2P is in major used for file sharing, P2P traffic often
contains many large sized flow or long duration flow.
• C5: In P2P file sharing, the file is divided in many smaller
chunks. Therefore if source and destination peers use
fixed ports for data transfer, it should exist many identical
flows with similar flow identities <SourceIp, SourcePort,
DestIp, DestPort, protocol, etc.>
• C6: A set of classic P2P applications often use fixed ports
to transfer data. This heuristic is despite of its simplicity
quite useful to identify the well-known P2P traffic in the
first step.
Besides the use of P2P for file sharing, chat, P2P is also used
for streaming data. The characteristics of these kinds are quite
different to P2P file sharing applications, especially for overlay
•
•
55
MI1: Karagiannis and Broido [13] proposed a payloadbased method to identify P2P traffic, using C6. The
method consists of three steps. The first step is to compare
source port and destination port of a flow to a table of
well-known P2P applications. This step is quite common
since it is quite simple to perform this step, and these
well-known P2P applications are often well-documented.
With this all known P2P applications with fixed ports are
identified. The second step is to look into the payload
of each packet in a flow and compare these strings
against a table of known protocols. In case of a match
we can identify the flow to the corresponding known
P2P applications. The third step considers the host IPs
which were identified as P2P flows from step two, and
classifies all flows that contains one of these identified
IP addresses as “possible“ P2P. In this step all known
services such as E-mail, DNS, FTP are excluded to
reduce the false positive rate. MI1 is simple but exposes
many drawbacks. MI1 can only identify well-know P2P
applications, unknown P2P traffic are still not to be
identified. Payload matching is still difficult since the
limit size of capturing packets doesn’t allow to fully look
into payload. In case applications encrypt the payload, it
will be impossible to look into the true content. Another
problem of this approach is privacy issue. There is privacy
law, which often forbids researcher to look into real
content of network traffic.
MI1’: Technique of MI1 was improved in [14]. MI1’
holds the first two steps as in MI1 with two additional
steps to improve step three. In MI1’ step three will
consider UDP flows and step four will consider TCP
flows. As in MI1, in step three all source and destination
IPs of UDP flow will be hashed in a table, and all the
flows, which contain IP address from this table will be
considered as “possible“. Step four does the same thing
as in step three for all TCP flows, to retrieve the second
IP address tables. For these two steps the exclusion of
web traffic as in MI1 still remains to reduce the false
rate. As for advantage MI1’ uses not only C6 but also
~
3
Fig. 1.
•
•
Classification of P2P Identification Methods
C1. Step three and step four help to partially overcome
limit packet size problem and a better “upper bound“ for
identified P2P traffic. Still for general the upper bound
of these payload-based technique is still too great, and
fully overcome the problem of encryption is still far from
possible.
MI2: As seen from these two payload-based techniques,
there are still many drawbacks with such techniques.
Fully looking into a packet is due to privacy issue usually
forbidden, and the need of identifying new P2P traffic
became greater. Therefore the creation of non-payloadbased techniques was necessary. In [13] the authors,
besides payload-based approach, also contributed a nonpayload based technique (MI2) of identifying P2P traffic,
using heuristics based on characteristics C1 and C2.
Based on C1 all IP sources and destinations which
concurrently use both TCP/UPD during a time t will be
considered as P2P. All well-known other services like
NETBIOS, IRC, DNS, which have similar behaviors will
be excluded. For C2 all flows which have the difference
of numbers of distinct connected IPs and distinct used
ports larger than a threshold (in this paper 10) will
considered P2P flows. This technique compared to MI1
and MI1’ provides a new way to efficiently identify new
kind of P2P traffic. But still the false positive problem
is an opened question. The first heuristic of this method
depends on viewed time t, the ratio of UPD and TCP in
a P2P application may vary. For the second heuristic if
threshold is chosen too big or too small, it can affect the
result, thus it may still generate false determination of
non-P2P traffic.
MI3: Constantinous and Mavrommatis [6] used the same
idea as MI2, which is based mainly on C1 and C2 to
discover new P2P traffic ports. Their implementation is
•
•
56
a little different to MI2. MI3 introduced term “diameter“.
Diameter is used to measure the interaction rate between
peers. Each host is assigned a level, the level means the
time when host receives first connection from another,
or first time to be “touched“. A host is assigned one
level greater than its “parents“. For the classification,
the number of hosts that acts in both roles “server“ and
“client“ at a port should exceed a threshold thus satisfies C1, network diameter should greater than two, and
number of host, which are present in network should also
exceed a threshold. Advantages and disadvantages of MI3
is similar to MI2, since it uses the same characteristics
and quite the same idea.
MI4: Perenyi et al. [18] used all mentioned characteristics to identify P2P traffic. In preparation MI4 tries
to exclude all web traffic that have the same behaviors
with TCP/UPD based on their default ports. The first step
is identify flow with characteristic C1. The second step
tries to refine separation from web traffic and P2P traffic
which disguise as web traffic using C3. Some of flows can
be identified using default ports(C6). C5 is then applied
to identify identical flows which might belong to P2P
applications. The next step is empirical experience of the
authors. They found out, that if an IP uses TCP/UPD port
more than 5 times in a period time, this IP,port indicate
P2P traffic. The last step chooses flow where flow size
is larger than 1MB or flow duration is longer than 10
minutes. Advantage of this technique, like other heuristicbased technique is to be able to discover unknown traffic,
but also introduces less accurate results, however because
of its consistencies, it is still suitable for P2P traffic
analysis.
MI5: Another approach should be mentioned is machine
learning based technique. An example of such approach
4~
TABLE I
C HARACTERISTICS VERSUS P2P IDENTIFICATION METHODS
Method Identification
MI1/MI1’
MI2
MI3
MI4
MI5
C1
C2
x
x
x
x
x
x
Characteristics
C3
C4
C5
x
x
x
x
misidentification, especially in case P2P is behind NAT. In
case P2P applications use tracker like BitTorrent, the behaviors
of monitoring agent (crawl and monitor all) is likely to be
identified as attempt of denial of service attack and would be
blocked. The risk of exposing P2P agent is therefore high,
which implies task for designing such monitoring agents, is
to assign these agents multiple IP addresses. The monitoring
scheme in [5] can be classified as a hybrid scheme. The authors
proposed monitoring approach for chord based protocols. In
this approach the overlay of P2P network is divided in many
subparts. Each subpart is monitored and measured as desire.
Data are sent back to a central collecting point. One distributed
monitoring scheme was P2PML, which can be deployed not
only in P2P monitoring, but also in monitoring web services as
well. This idea of distributed monitoring was introduced in [1].
The monitor system itself is a P2P network that coexists with
monitored P2P network. Each peer can be member of monitoring and monitored network. The system uses a declaration
subscription language, P2PML to describe monitoring tasks.
Monitoring tasks are described using P2PML, a description
language based on XML. Thus is easy to implement and adapt,
since XML is a widely-used standard. Peers in monitored
P2P system observe activities, publish information stream. A
peer may host alerter, which intercepts inbound and outbound
and detects changes, stream processor which does operation
on streams, publisher which publishes stream generated from
stream operation. When a user is interested in a specific
monitoring task, he can subscribe to a channel, which will
publish the stream. The filter bases on Atomic Event Set Algorithm and YFilter Algorithm to match pattern. By defining
condition the desired information can be filtered. A subscriber,
who is interested in a part of network can subscribe to a
channel, which was published by monitoring peers. Although
this idea is interesting for monitoring task not only for P2P
systems, but also for web services call, it still has drawbacks.
Alerters have to be implemented for each type of monitored
system. Furthermore for analysis purpose the use of another
P2P system as monitoring system may introduce confusion. As
stated in introduction for P2P monitoring task, distributed and
hybrid schemes are often applied. Other distributed monitoring
scheme can be found in [9], [11], [15]
C6
x
x
can be found in [8]. MI5 uses clustering technique,
defines cluster with interesting metrics, such as flow size
etc. MI5 only needs statistic of unidirectional flow. With
the help of training data, which were achieved from both
payload-based and non-payload-based techniques. For
each flow it can determine to which class (P2P, or other
web traffic) the flow should belong. MI5 is also useful to
learn the new behaviors of P2P traffic, as well as classify
them. MI5 is still in development, since MI5 concentrated
mainly on TCP and lets UDP out of concern. Through
empirical experiments MI5 works better for better for
“server-to-client“ statistic. The result from “server-toclient“ direction often has higher accuracy. In the future
work, the authors intended to extend their technique, so
that it will be able to classify UDP traffic and also work
better with “client-to-server“ direction.
For the end of this section, a table for an overview which
characteristics were used by which methods, is provided in
Table I. For recall MI1 and MI1’ are payload-based technique.
They used the port-based characteristic and content of the
traffic to identify P2P traffic. C1 and C2 are the most common
used characteristics in heuristic-based methods. The machine
learning based method MI5 often uses the statistic of large
flow size to identify P2P.
B. P2P Traffic Monitoring
Monitoring is an important task not only for P2P traffic analysis, but also for administration purpose. Monitoring scheme
in general can be classified in three categories, centralized
scheme, decentralized scheme (distributed scheme) and hybrid
scheme [16]. Normally for monitoring purpose, monitoring
agent is needed. The centralized monitoring scheme results
accurate information. But centralized scheme is often not
scalable, since a central entity has to take responsible to monitor the whole network. Decentralized or distributed scheme
can overcome the problem of scalability, but introduces other
problems. In such scheme peers are responsible for monitoring
each other. This can be a problem, if one peer provides false
information, it can affects the global conclusion for the state
of the network. Also a peer can attempt malicious doing,
such as injecting malicious code etc. A better solution for
monitoring problem would be a hybrid scheme, where we
should use centralized scheme if possible, and decentralized
if not. The combination of two major monitoring schemes
might overcome disadvantages of each of them. The current
state of P2P monitoring is still not perfect. The risk of
false positives is still high. Use of arbitrary address in P2P
applications makes it difficult to identify peer and cause
For the end of this section, a list of common used metrics
are provided. In section of traffic analysis we will see, how
these metrics are differently considered in each different work.
•
•
•
•
•
•
•
57
Traffic volume or throughput (traff_vol): The whole P2P
traffic volume, which was captured.
flow size (flow_size): Size of P2P flow
flow duration (flow_duration): Time begins when one P2P
flow started, until this flow ends.
flow inter-arrival time (flow_inter_arr_time): Time between each arrival of two consecutive P2P flows.
packet size (pkt_size): size of a packet, which belongs to
P2P traffic.
Live connection or number of TCP connections from
a host (live_conn): Number of TCP connections, which
belong to P2P traffic in a period of time
Geographical distribution of peer (geo_distr): how peers
~
5
•
•
•
are geographically distributed.
Bit rate (bit_rate)
P2P population or number of peers (peers_popu): Number
of P2P peers.
Popularity distribution (how traffic is distributed among
IP address) (poplr_distr): the number of distinct IP addresses among peers.
C. P2P Traffic Analysis
Traffic analysis generally consists of identification, choice
of interesting metrics (filter of them from the identified traffic)
and the analysis result based on the metrics. In the following
the methods will be called as MA (method of analysis)
• MA1: Karagiannis et al. [14] used MI1’ to identify
P2P traffics and collect P2P traffic traces. The traces
were collected by monitoring traffic of two commercial
backbone links San Jose - Seattle in US. The authors
collected the traces and learned P2P traffic characteristics, by measuring the following metrics: bitrate of P2P
traffic, population of P2P traffic (number of distinct IP
mapped to Autonomous systems), traffic volumes of P2P
traffic relative to all traffic columns. With their results
the authors also concluded that P2P trend changed but
never died. Since MI1’ is payload-based technique, as
described above, it can not identify all P2P traffic, but the
identifiable P2P protocols were in time the most traffic
contributed. This means for the purpose of the paper, the
method was sufficient.
• MA2: Louis et al. [17] contributed an early analysis work
in field of P2P traffic analysis. MA2 used only characteristic C6, compared flow ports with famous applications
default ports, to identify P2P traffic. Although it was
restricted only to some famous P2P applications, but these
application in time contributed most P2P traffic to the
Internet. Furthermore MA2 only wanted to analyze the
most famous protocols. MA2 captures all TCP packets
between BAS 1 and the IP Backbone. MA2 analyzed
and also compared some famous P2P protocols such as
eDonkey, BitTorrent, FastTrack, WinMX. These protocols
are compared with regards to the following metrics: traffic
volumes, connection duration, geographical distribution
of peers, termination of connections, whether the connection ended normally, connectivity of peers (number
of local peers and non-local peers) and from this result
described the different behaviors of each application type.
MA1 still had many restrictions, w.r.t. P2P identification.
With the growth of P2P network nowadays, MA2 is not
really efficient anymore. Nevertheless MA2 gave us many
interesting behaviors of P2P traffic in early time, which
is also contribution for P2P traffic analysis.
• MA3: Baset et al. analyzed the most famous P2P VOIP
Skype in [3]. Since Skype is not open-sourced, its protocol is not clear. Skype’s used port can be altered,
so it is impossible to use approach like in MA1 or in
MA2. Instead of monitoring to capture traffic of skype,
1 Broadband
•
•
•
Access Server
58
MA3 uses shared library and system call redirection
technique to overload shared library functions. With the
overloaded share functions, when Skype client calls a
function from shared library (this is applied for Linux
OS) the called function can redirect the input parameter to
output. Thus it is able to get interesting information from
Client behaviors, targeted modify calls and then analyze
interesting results/behaviors from called parameters. In
this work the authors are interested in protocol aspect
of Skype client. One common viewed metric is also
analyzed here, namely geographical distribution. MA3 is
an efficient approach if using Linux as OS for analysis
purpose, since the manipulation of called share library is
nature part of Linux OS. But with approach like MA3,
other measurements like flow size, flow duration etc.
will not be considered. Only behaviors of peer client is
analyzed. The characteristic of overlay network in this
case is missed.
MA4: In [18] data for analysis were collected from two
Cisco routers at one large Internet provider in Hungary.
MA4 used NetFlow to collect traffic flow information
and also some packet-level information. The method MI4
was applied to identify P2P traffic. MA4 focused on
comparison between P2P and non-P2P traffics. Therefore
following metrics were considered: P2P traffic volume
compared to total traffic, number of P2P users/total active
users, and in order to reduce error MA4 associated an
individual IP address to a user, flow size and flow duration, packet size, thus to analyze the properties of P2P
traffic in data transmission and the differences between
P2P protocols, and popularity distribution. MA4 used
MI4 which is easy to implement, like other heuristicbased techniques, MI4 might introduce false positives.
The author proposed a solution by assigning individual
IP address to a user, which might reduce accuracy. But for
interest of Internet Provider, and the whole purpose for
comparison P2P and non-P2P traffic, this less-accuracy
can be tolerated.
MA5: Basher et al. [4] dedicated their work to compare
P2P traffic and network traffic. The traces were collected
by using lindump, which monitors ports and captures
all TCP/IP packets from the commercial Internet link
of the university Calgary. For identification of P2P
flows/applications MA5 uses port-based and payload
signature-based technique. MA5 considered flow size,
flow duration, flow inter-arrival time, maximum number
of TCP flows from a single host, transfer volume
and geographic distribution. As other methods the
less-accuracy problem of signature-based technique is
not a non-tolerated problem. The traces in MA5 were
not collected continuously, thus might not cover all
abnormal behaviors of traffics, but either way the most
common characteristics of P2P are already covered.
MA6: Torres et al. [19] focused on analyzing and finding
undesirable behavior from P2P traffic. All TCP and UDP
traces were collected by using Tstat at a MiniPoP router,
where all traffics go into Internet backbone. Tstat is a
6~
TABLE II
C OMMON USED METRICS VERSUS A NALYSIS M ETHODS
traff_vol
flow_size
flow_duration
flow_inter_arr_time
pkt_size
live_conn
geo_distr
bit_rate
peers_popu
poplr_distr
MA1
x
MA2
x
MA3
x
MA4
x
x
x
x
x
x
x
x
x
MA5
x
x
x
x
x
x
many works for P2P traffic identification, they can be general
categorized as payload-based, non-payload based and machine
learning based methods. Non-payload based has advantage,
that it might be able to discover new P2P traffic, which is
also a concerned question for analysis. But non-payload based
techniques introduce false-positives. In fact four from six
described methods chose payload-based techniques, because
they only concerned about particular well-know protocols.
Payload-based can not discover new P2P traffics, but it can
guarantee the correctness of those identified. Therefore the
choice of identification method must primarily base on purpose
of each research. In this case payload-based is better, but in
other case the use of non-payload based it recommended.
Early works in P2P analysis focused on comparison between
P2P traffic and web traffic, in order to determine the trend
of P2P. Especially the traffic volume at the beginning was
concerned, as for Internet Provider it would be critical to keep
their network at good performance. Then the concentration
moved to learn the characteristic and behavior patterns of P2P
traffic. From this point on P2P protocols get more complex,
as for the trend of network analysis this paper found the idea
based on domain knowledge a good approach for future work.
For network operator, it is mandatory to be able to monitor P2P
traffics, to optimize P2P networks and prevent P2P networks
from corruption. Monitor of P2P network is still a big challenge due to large scale of network and dynamic properties of
P2P protocols. We have seen some solutions for this problem,
but it still has to be developed. A general monitoring approach
for all P2P traffic is still a big challenge. Hybrid monitoring
scheme would be the solution for monitoring P2P networks.
To learn the complex behaviors of P2P traffic machine
learning is a good approach. The quality of machine learning
process is dependent from the quality of the samples, i.e. a
sample set from payload-based identified traffic can be fed
in order to learn the behaviors pattern of these particular
protocols, or sample set of both payload- and non-payloadtechniques can be fed to learning process. The training data
can be used to detect and learn behaviors. By using machine
learning process it is also able to learn about undesired
behaviors of P2P traffic by choosing suspicious cluster. With
this notice we tend to believe that further works in P2P analysis
should use machine learning more, as P2P is getting more
complex.
MA6
x
x
x
x
x
tool, which can capture flows and perform Deep Packet
Inspection, thus enables users to identify known P2P
traffics based on payload. MA6 focused on EMule, Kad,
and KadU (a modified version of Kad). These 3 application contribute the most traffic to the monitored network.
Signatures of these application were already mentioned
in other works, therefore classification of these three
were not a problem. MA6 applied a machine learning
approach, density based algorithm to divide the data set
in subsets (clusters), in which the data have similarity.
Normally noise region, which was generated after the
last step would be considered interesting. However in
this case the authors of MA6 chose to select interesting
regions based on domain knowledge of network operator,
P2P developer and P2P users. MA6 considered metrics as
dependent from flow initiator and independent from flow
initiator. Metrics dependent from flow initiator are flow
average duration, number of active flows, ratio of outside
connections to total numbers, bit rate, average packet size,
ratio of byte sent and byte received. Metrics dependent
of flow initiator are total connection attempts, ratio of
flows to the number of distinct destinations, number
of peers, number of destination ports, also number of
destination ports which are under 1024 was considered.
Using signature-based technique for identification, MA6
limited it’s work only with three P2P protocols. MA6
analyzed traffic based on domain knowledge, which is
better for classification of behaviors at host level, and the
way MA6 chose interesting region can be applied in other
works as well.
Table II is a summary of corresponding metrics in each
analysis methods. We can recognize from the table, that the
use of each metric differentiates in each work. The reason is,
each work has it’s own focus on a particular direction. Of
all metrics, the metric traffic volume of P2P was the most
considered one. It is also a sign, that P2P traffic is getting
larger over time and this naturally raises concern of P2P
network administrator and researcher.
IV. C ONCLUSION
This paper considered the problem of P2P traffic analysis
and summarized some methods. For a better understanding,
the methods were viewed as for identification, monitor/filter
and analysis tasks. We reviewed the identification methods
in two major approaches, payload-based and heuristic-based
methods. Furthermore one approach for identification based
on machine learning was reviewed. We stated the classification
of monitoring scheme, named the problems and difficulties
of P2P monitoring. Afterwards we listed the most common
concerned metrics, which can be used for monitoring tasks
as well as analysis purposes. We also summarized how these
metrics were used in analysis researches. We showed that for
III. D ISCUSSION
As we have already seen, the common template of P2P
traffic analyzing is identify P2P traffic from other traffics,
filter them, chose the appropriate metrics, which should be
interesting with regard to each particular work, evaluate the
worked results from the collected data. There have been
59
~
7
each particular analysis purpose, appropriate metrics should
be chosen. The paper also discussed possible advantages and
disadvantages for each approach. As result, each approach
despite of its drawbacks, can find its own usefulness depends
on purpose of each work. For last word we also believed that
machine learning would become more and more important in
this study field.
[21] Long Vu, Indranil Gupta, Klara Nahrstedt, and Jin Liang. Understanding
Overlay Characteristics of a Large-scale Peer-to-Peer IPTV System.
Computer, V, 2008. II-A
[22] Ping Wang, S. Sparks, and C.C. Zou. An advanced hybrid peer-topeer botnet. IEEE Transactions on Dependable and Secure Computing,
7(3):235–127, April 2008. I
R EFERENCES
[1] Serge Abiteboul. Distributed monitoring of peer to peer systems.
Proceedings of the 9th annual ACM, pages 41–48, 2007. I, II-B
[2] Genevieve Bartlett, John Heidemann, and Christos Papadopoulos. Estimating p2p traffic volume at USC. ISI-TR-645, USC/Inform., (June),
2007. I
[3] Salman A. Baset and Henning G. Schulzrinne. An Analysis of the
Skype Peer-to-Peer Internet Telephony Protocol. Proceedings IEEE
INFOCOM 2006. 25TH IEEE International Conference on Computer
Communications, pages 1–11, April 2006. II-C
[4] Naimul Basher, Aniket Mahanti, Anirban Mahanti, Carey Williamson,
and Martin Arlitt. A comparative analysis of web and peer-to-peer traffic.
Proceeding of the 17th international conference on World Wide Web WWW ’08, page 287, 2008. I, II-C
[5] Andreas Binzenhöfer, Gerald Kunzmann, Robert Henjes, Andreas
Binzenhbfer, and Am Hubland. A Scalable Algorithm to Monitor Chordbased P2P Systems at Runtime Institute of Computer Science Institute
of Communication Networks. Processing, 2006. II-B
[6] Fivos Constantinou and Panayiotis Mavrommatis. Identifying known and
unknown peer-to-peer traffic. In Network Computing and Applications,
2006. NCA 2006. Fifth IEEE International Symposium on, pages 93–
102. IEEE, 2006. I, II-A
[7] Karim El Defrawy, Minas Gjoka, and Athina Markopoulou. BotTorrent
: Misusing BitTorrent to Launch DDoS Attacks. Analysis, pages 1–6. I
[8] Jeffrey Erman, A Mahanti, and Martin Arlitt. Identifying and discriminating between web and peer-to-peer traffic in the network core. on
World Wide Web, pages 883–892, 2007. I, II-A
[9] B. Gedik. PeerCQ: a decentralized and self-configuring peer-to-peer
information monitoring system. 23rd International Conference on
Distributed Computing Systems, 2003. Proceedings., pages 490–499.
II-B
[10] Takeo Hamada, Kaoru Chujo, Xiang Ying Yang, and Takafumi Chujo.
Peer-to-peer traffic in metro networks: analysis, modeling, and policies.
Network Operations and, 2004. I
[11] R. Hofmann, R. Klar, B. Mohr, a. Quick, and M. Siegle. Distributed
performance monitoring: methods, tools, and applications. IEEE Transactions on Parallel and Distributed Systems, 5(6):585–598, June 1994.
II-B
[12] Shay Horovitz. Collabrium: Active Traffic Pattern Prediction for Boosting P2P Collaboration. Technologies: Infrastructures for Collaborative,
2009. I
[13] Thomas Karagiannis and Andre Broido. Transport layer identification
of P2P traffic. Proceedings of the 4th ACM, pages 121–134, 2004. I,
II-A
[14] Thomas Karagiannis, Andre Broido, and Nevil Brownlee. Is p2p dying
or just hiding? Global, 2005. I, II-A, II-C
[15] M. Karakaya, I. Korpeoglu, and O. Ulusoy.
A distributed and
measurement-based framework against free riding in peer-to-peer networks. Proceedings. Fourth International Conference on Peer-to-Peer
Computing, 2004. Proceedings., pages 276–277. II-B
[16] B. Landfeldt, P. Sookavatana, and a. Seneviratne. The case for a hybrid
passive/active network monitoring scheme in the wireless Internet.
Proceedings IEEE International Conference on Networks 2000 (ICON
2000). Networking Trends and Challenges in the New Millennium, pages
139–143. II-B
[17] Plissonneau Louis, Lauren Costeux Jean, and Brown Patrick. Analysis
of Peer-to-Peer Traffic on ADSL. France Telecom R&D. I, II-C
[18] Marcell Perényi, Trang Dinh Dang, András Gefferth, and Sándor Molnár. Identification and Analysis of Peer-to-Peer Traffic. Journal of
Communications, 1(7):36–46, December 2006. I, II-A, II-C
[19] Ruben D. Torres, Mohammad Y. Hajjat, Sanjay G. Rao, Marco Mellia,
and Maurizio M. Munafo. Inferring undesirable behavior from P2P
traffic analysis. Proceedings of the, pages 25–36, 2009. I, II-C
[20] S Tzur-David and Danny Dolev. MULAN: Multi-Level Adaptive
Network Filter. Security and Privacy in Communication, 2009. I
60
~
1
PEER-TO-PEER-BASIERTE LIVE-STREAMING-SYSTEME
Peer-to-Peer-basierte Live-Streaming-Systeme
Thomas Schlosser
Zunächst führt Abschnitt II in die Grundlagen der P2PLive-Streaming-Systeme ein. Dabei werden besonders Begrifflichkeiten, die für das weitere Verständnis in diesem
Paper relevant sind, beschrieben. Abschnitt III gibt eine
Übersicht über existierende Klassifikationen solcher LiveStreaming-Systeme. Basierend auf den in den Klassifikationen verwendeten Eigenschaften werden diese und weitere in
Abschnitt IV zusammengetragen und in ihren Ausprägungen
unterschieden. Im anschließenden Abschnitt V werden eine
Vielzahl von Systemen anhand dieser Eigenschaften untersucht
und beschrieben. Ihre Gemeinsamkeiten und Unterschiede
werden hervorgehoben, wodurch die Auswahl eines Systems
beziehungsweise Ansatzes für verschiedene Einsatzszenarien
vereinfacht wird. Abschließend wird in Abschnitt VI ein Fazit
über die in diesem Paper zusammengetragen Systeme und
Klassifikationsmöglichkeiten gezogen.
Zusammenfassung—Live-Streaming-Anwendungen finden im
Internet zunehmend größere Verbreitung. Durch die steigende
Anzahl an Nutzern einer solchen Anwendung wird es immer
kostenaufwendiger, ein solches System Client-Server-basiert zu
betreiben. Eine kostengünstige, skalierbare Lösung stellen Peerto-Peer-basierte Live-Streaming-Systeme dar. Dieses Paper stellt
einige bekannte Klassifikationen und Eigenschaften solcher Systeme vor. Es bietet zudem einen umfassenden Überblick über
die verschiedensten existierenden Peer-to-Peer-Live-StreamingSysteme. Diese werden jeweils kurz vorgestellt und bezüglich
ihrer Eigenschaften, Gemeinsamkeiten und Unterschiede betrachtet. Somit hilft dieses Paper bei der Wahl eines Peer-toPeer-basierten Systems für verschiedenste Einsatzgebiete, Umgebungen und Ziele.
I. E INLEITUNG
Eine immer größere Anzahl an Internetnutzern verwendet Dienste, die Videos live über das Internet ausstrahlen.
Sowohl bei Konferenzen und Großveranstaltungen als auch
für gewöhnliche TV-Übertragungen werden solche Dienste
angeboten. Die einfachste Art und Weise solche Live-Streams
zu verbreiten stellt das Client-Server Modell dar. Mit diesem
Modell stoßen die Systeme aber schnell an die Grenze der
Skalierbarkeit beziehungsweise auf immens hohe Betriebskosten, denn die Leistung der Server muss proportional zur
Nutzeranzahl wachsen.
Eine effiziente Lösung des Problems stellt IP-Multicast [9]
dar, bei dem die IP-Pakete des Senders an eine Gruppe von
Empfängern übertragen wird. Da die Datenpakete erst an Verzweigungen im Netzwerk dupliziert werden, muss jedes Paket
lediglich ein einziges Mal über ein und dieselbe Verbindung
gesendet werden. Aufgrund der speziellen Anforderungen an
die Infrastruktur und den erforderlichen Zustand innerhalb der
Router ist IP-Multicast meist kein praktikabler Mechanismus
zur Übertragung von Live-Streams.
Ein Ansatz namens Peer-to-Peer (P2P), der keinerlei
Unterstützung des zugrundeliegenden Netzwerks benötigt,
verbreitete sich als Alternativansatz. Dieser abstrahiert von
der Netzwerkebene und arbeitet ausschließlich auf der
Anwendungsebene. In P2P-Systemen teilen die Teilnehmer
– die sogenannten Peers – ihre Hardwareressourcen
untereinander, um als Einheit den Service des Netzwerks allen
Peers anbieten zu können. Die Peers kommunizieren direkt
untereinander und agieren dabei sowohl in der Rolle des
Anbieters als auch in der des Anfragenden [31]. Im Bereich
der Live-Streaming-Systeme lassen sich somit kostengünstige
und hochskalierbare Systeme entwickeln.
II. G RUNDLAGEN
Dieser Abschnitt führt in die Grundlagen P2P-basierter
Live-Streaming-Systeme ein. Dabei werden besonders die für
dieses Paper relevanten Aspekte hervorgehoben.
P2P-basierte Live-Streaming-Systeme unterscheiden sich
von anderen P2P-Systemen vor allem hinsichtlich ihres
Bandbreitenkonsums. Sie gehören der Klasse der fixed-rateSysteme an [2]. In diesen Systemen wird der zu verteilende
Inhalt mit einer konstanten Rate auf einer Teilmenge der Peers
generiert. Aufgrund der hohen zeitlichen Anforderungen an
Live-Streaming-Systeme muss dieser Inhalt – unter Verwendung von kleinen Puffern – schnellstmöglichst verteilt werden.
Damit ein fortlaufendes Abspielen eines Streams gewährleistet
werden kann, muss die Downloadrate der Empfänger – im
Durchschnitt – immer der Generierungsrate entsprechen.
Diese Anforderung – immer die entsprechenden Daten für
den aktuellen Abspielzeitpunkt verfügbar zu haben – unterscheidet sich von den Anforderungen anderer P2P-basierter
Systeme. Entsprechend der Generierungsrate müssen die Daten an jedem Peer bis zu einer bestimmten Frist vorhanden sein. Somit werden für gewöhnlich Daten, die nahe am
Abspielzeitpunkt liegen, höher priorisiert als weiter entfernte
Daten. Alle Daten, die hinter dem Abspielzeitpunkt liegen,
sind von keinem Interesse und können verworfen werden.
Weitere Aspekte, die bei solchen Systemen beachtet werden
sollten, sind die Heterogenität der Peers, die Asymmetrie
zwischen Download- und Uploadrate und die Gewährleistung
eines zusammenhängenden Netzwerks zwischen den Peers.
Dieses Paper stellt einige bekannte Klassifikationen und
Eigenschaften der P2P-Live-Streaming-Systeme vor und
gibt eine umfassende Übersicht über existierende Systeme.
Die betrachteten Systeme werden ferner hinsichtlich ihrer
Gemeinsamkeiten und Unterschiede betrachtet.
A. Overlay-Topologien
Das zwischen den Peers auf der Anwendungsebene aufgebaute Netzwerk wird als Overlay bezeichnet. Der Prozess,
diesem Overlay beizutreten, heißt Joinen. Der beim Joinen
61
2~
Server
Server
Stream 1
Peer 0
Baum 1
Peer 1
P1
P2
P3
P6
Abbildung 1.
P4
P7
P0
P1
P2
P2
Baum 2
P0
P5
P8
P9
Abbildung 2.
Overlaystruktur eines Multi-Tree-basierten Systems
Overlaystruktur eines Single-Tree-basierten Systems
mehrere Teilstreams aufgeteilt und jeweils über einen eigenen
Baum verteilt. Jeder Peer ist in jedem Teilbaum – meist
an unterschiedlichen Positionen – enthalten. Über die Positionierung kann die Ausnutzung der Bandbreiten verbessert
werden. In einem vollständig balancierten Baum ist jeder
Peer nur in einem Teilbaum ein innerer Knoten. Durch die
vielen Teilstreams und Bäume entsteht ein größerer Overhead.
Andererseits führt das Verteilen der Daten über verschiedene
Pfade – bei Verwendung einer redundanzbehafteten Kodierung
– zu einer deutlich größeren Ausfallsicherheit.
Abbildung 2 zeigt ein Overlay eines Multi-Tree-basierten
Systems. Der Stream wird vom Server in zwei Teilstreams
aufgeteilt und in den Teilbäumen Baum 1 und Baum 2 verteilt.
Peer 0 und Peer 1 tauchen als Blätter und als innere Knoten
auf. Lediglich Peer 2 kann seine Upload-Kapazität nicht zur
Verfügung stellen, da er immer als Blatt angehängt ist.
2) Mesh-basiert: In einem Mesh-basierten System gibt es
keine statische Topologie. Beziehungen zwischen den Peers
werden dynamisch auf- und abgebaut. Jeder Peer kann gleichzeitig verschiedene Daten zu mehreren Peers hochladen und
von mehreren Peers herunterladen. Eine hohe Anzahl an Verbindungen zwischen den Peers macht eine solche Topologie
sehr robust. Bei Ausfällen einzelner Peers können die Daten
weiterhin von anderen Peers empfangen werden [20].
verwendete Mechansimus, zum Kennenlernen eines oder mehrerer initialer Teilnehmer des Overlays, ist das sogenannte
Bootstrapping. Die Menge aller Peers, mit denen ein Peer
verbunden ist, bildet dessen Nachbarschaft. Die Topologie
eines solchen Overlays entspricht bei P2P-Live-StreamingSystemen einer der folgenden oder Mischformen der folgenden Topologien:
1) Tree-basiert: Ähnlich dem Baum, der bei der Verteilung
über IP-Multicast entsteht, werden die Peers in Tree-basierten
Systemen miteinander verknüpft. Von der Quelle des Videostreams ausgehend entsteht somit eine zusammenhängende und
azyklische Struktur zwischen allen Peers. Diese Topologie
lässt sich feiner in Single-Tree und Multi-Tree unterteilen [20].
Ein Single-Tree zeichnet sich dadurch aus, dass alle Peers
in einem Baum verwaltet werden. Der Stream wird jeweils
vom Eltern-Peer an seine Kinder gesendet. Jeder Peer – außer
der Wurzel – besitzt genau einen Eltern-Peer. Die wichtigsten
Merkmale eines solchen Baums sind dessen Tiefe und der
Ausgangsgrad der Knoten1 . Offensichtlich ist auch, dass die
Peers auf einer tieferen Ebene die Daten zu einem späteren
Zeitpunkt erhalten. Somit wäre ein möglichst flacher Baum das
Wünschenswerteste. Dies ist wiederum durch die begrenzte
Upload-Kapazität der Peers nicht beliebig umsetzbar. Ein
weiterer wichtiger Aspekt eines solchen Baums ist dessen
Verwaltung. Sobald ein Peer ausfällt, sind alle seine Nachfahren von der Quelle abgeschnitten. Darum ist es wichtig,
dass der Baum möglichst schnell repariert werden kann. Diese
Verwaltung kann entweder durch einen zentralen Server oder
über einen verteilten Algorithmus durch die Peers erfolgen.
Ein weiterer Nachteil dieser Topologie ist, dass Blätter keinen
Ressourcen-Beitrag leisten können.
Abbildung 1 zeigt ein Beispieloverlay eines Single-Treebasierten Systems. Auf Ebene 1 befinden sich zwei Peers,
die direkt vom Server versorgt werden. Peer 0 wiederum ist
Eltern-Peer von drei anderen Peers. Da Peer 6 auf Ebene 3
den Stream von Peer 3 von Ebene 2 erhält, ist offensichtlich,
dass dieser den Stream erst später erhält.
Um das Problem mit dem fehlenden Ressourcen-Beitrag
der Blätter zu lösen, wurden die sogenannten Multi-Treebasierten Ansätze entwickelt. Dabei wird der Originalstream in
1 Die
Stream 2
B. Kommunikationsparadigmen
Der Austausch der Daten in einem P2P-System kann auf
zwei verschiedene Art und Weisen – Pull-basiert oder Pushbasiert – vonstatten gehen. In einigen neueren Systemen wird
eine Mischform verwendet, in der die eine oder andere Art je
nach Kommunikationszweck gewählt wird.
1) Push: Die Push-basierte Kommunikation zeichnet sich
dadurch aus, dass der Sender die Daten ohne explizite Anforderung an den Empfänger sendet. Dieses Paradigma ist das
Standard-Paradigma in Tree-basierten Systemen.
2) Pull: Bei einer Pull-basierten Kommunikation werden
die Daten vom Empfänger beim Sender angefordert. Dazu
tauschen die Peers für gewöhnlich die Verfügbarkeit der
Daten untereinander aus. Dadurch lassen sich redundante
Übertragungen – wie sie durch Push-basierte Kommunikationen entstehen würden – vermeiden. Diesem Paradigma wird
standardmäßig bei Mesh-basierten Systemen gefolgt.
Begriffe „Knoten“ und „Peer“ werden austauschbar verwendet.
62
~
3
III. K LASSIFIKATIONEN
unstrukturiertes Overlay erzeugt werden, das sich dadurch
auszeichnet, dass die Peers in keiner speziellen Topologie
miteinander verknüpft sind. Mesh-basierte Systeme besitzen
genau dieses Merkmal und können somit synonym verwendet
werden. Tree-basierte Systeme können sowohl die eine als
auch die andere Ausprägung dieser Eigenschaft besitzen. Dies
ist davon abhängig, ob der Baum bei der Konstruktion des
Overlays entsteht oder ob der Baum erst jeweils bei der
Datenverteilung seine Form erhält. In letzterem Fall handelt
es sich um ein unstrukturiertes Overlay [11].
Weiterhin können sich die Systeme in ihrer Struktur dahingehend unterscheiden, dass ein System ein oder mehrere –
eventuell verschiedene – Overlays für die Verteilung der Daten
verwendet. Auch die Struktur der Overlays zur Verwaltung der
Peers kann von denen zur Datenverteilung abweichen [11].
Dieser Abschnitt gibt eine Übersicht über existierende Klassifikationen für P2P-Live-Streaming-Systeme.
In [34] klassifizieren Silverston und Fourmaux P2P-LiveStreaming-Protokolle anhand ihrer Verwaltung des Overlays.
Sie unterscheiden die Kategorien Source-Driven, ReceiverDriven und Data-Driven. In Source-Driven Systemen werden
die Daten – von einer Wurzel ausgehend – über eine Baumstruktur an die Empfänger verteilt. Werden die Daten hingegen
über einen Baum verteilt, dessen Wurzel der Empfänger ist,
so handelt es sich um einen Receiver-Driven Ansatz. Dabei
organisiert der Empfänger die Ressourcen – das heißt die
anderen Peers –, um an den gewünschten Stream zu gelangen.
In Data-Driven Systemen tauschen die Peers Nachrichten über
die Datenverfügbarkeit aus. Anhand dieser Datenverfügbarkeiten suchen sich die Peers selbstständig ihre Nachbarn zum
Datenaustausch aus. In ihren Untersuchungen kommen sie zu
dem Ergebnis, dass der Data-Driven Ansatz der beste Ansatz
für Live-Streaming zu sein scheint. Aufgrund der Ähnlichkeit
von unstrukturierten Overlays zu Zufallsnetzen, erweisen sich
solche Systeme gegenüber Angriffen und Ausfällen als resistenter.
Eine weitere Möglichkeit zur Klassifizierung wird von Liu,
Guo und Liang in [20] beschrieben. Sie unterscheiden LiveStreaming-Systeme anhand der Struktur des Overlays. Dabei
verwenden sie die Klassen so, wie sie in Abschnitt II-A
vorgestellt wurden. Sie unterscheiden somit zwischen SingleTree, Multi-Tree und Mesh-basierten Systemen.
Durch die kontinuierliche Neuentwicklung von P2P-LiveStreaming-Systemen entstanden in der Vergangenheit eine
Reihe von hybriden Systemen, wie beispielsweise Climber
(siehe Abschnitt V), die sich nicht mehr eindeutig einzelnen Klassen dieser Klassifikationen zuordnen lassen. Zudem
entstanden auch neue Systeme, die weitere Komponenten –
wie die Gruppierung von Peers in Cluster – in die Topologie
integrierten und weiter vermischten. Das Aufstellen einer neuen Klassifikation, die alle wichtigen Aspekte dieser Systeme
berücksichtigt, ist somit nicht befriedigend umsetzbar.
B. Cluster
Einige Systeme gruppieren ihre Peers in sogenannte Cluster,
um robustere Netzwerke aufbauen zu können. Meist wird
innerhalb eines Clusters eine andere Struktur als zwischen
den Clustern verwendet. Aussagen über die Overlay-Struktur
lassen sich jedoch sowohl auf Peer- als auch auf Clusterebene
in gleichem Maße treffen.
C. Koordinierung der Peers
Zur Koordinierung in einem P2P-System zählt sowohl der
Aufbau desselben als auch die Verteilung der Daten in ihm.
Wird die Koordinierung der Peers von einem einzelnen Knoten
übernommen, so wird das System als zentrales bezeichnet.
In einem solchen System stellt dieser zentrale Punkt einen
Flaschenhals dar. Er steht für gewöhnlich unter einer großen
Last und im Falle seines Ausfalls kann das System nicht
mehr betrieben werden. Dezentrale Ansätze, bei denen die
Peers gemeinsam die Koordination übernehmen, verhindern
das Auftreten dieses Problems. Im Gegensatz zu dem zentralen
Ansatz, bei dem der dedizierte Knoten über ein globales
Wissen des Systems verfügen muss, wird beim dezentralen
Ansatz an jedem Peer meist lediglich ein lokales Wissen benötigt. Durch das globale Wissen können in zentral verwalteten
Systemen Optimierungen vorgenommen werden, die sich mit
Hilfe reines lokalen Wissens nicht realisieren lassen. Mischformen, die den Aufbau durch eine zentrale Instanz koordinieren
und die Verteilung der Daten dezentralisiert ablaufen lassen,
versuchen die Vorteile beider Koordinierungsarten zu vereinen.
IV. E IGENSCHAFTEN VON
P2P-L IVE -S TREAMING -S YSTEMEN
Da sich, wie in Abschnitt III beschrieben, keine eindeutige Klassifikation für P2P-Live-Streaming-Systeme erstellen
lässt, werden die Systeme im weiteren Verlauf dieses Papers
hinsichtlich ihrer Eigenschaften betrachten. Die wichtigsten
Eigenschaften, die ein solches System ausmachen können,
werden in diesem Abschnitt zusammengetragen.
D. Kommunikationsparadigma
Entsprechend der Erläuterung in Abschnitt II-B existieren zwei verschiedene Kommunikationsparadigmen: Push und
Pull. Push-basierte Kommunikation hat den Vorteil einer geringeren Aufbauzeit, da der Sender ohne explizite Anfrage
die Daten versenden kann. Bei Pull-basierter Kommunikation
teilt der Sender für gewöhnlich zunächst die Verfügbarkeit der
Daten mit, woraufhin der Empfänger die gewünschten Daten
anfragt und erst im Folgenden zugesendet bekommt. Allerdings werden im Pull-basierten Ansatz redundante Übertragungen vermieden. Auch bei den Kommunikationsparadigmen
werden Mischformen für verschiedene Aspekte der Systeme
verwendet, um die Vorteile beider Varianten zu nutzen.
A. Overlay-Struktur
Eine der wichtigsten Eigenschaften eines P2P-Overlays ist
dessen Struktur. Ein Overlay kann über einen strukturierten
Ansatz erstellt werden, bei dem die Peers zusammen eine
spezielle Topologie bilden. Eine solche Struktur kann zum Beispiel einem Ring [35], Hypercube [29] oder Plaxton Mesh [30,
39] entsprechen. Hierbei ist es wichtig, dass beim Joinen,
aber auch beim Ausfall von Peers die Struktur weiter Bestand
hält. Im Gegensatz zum strukturierten Ansatz kann auch ein
63
4~
E. Fairness
Der Empfänger dieser Nachricht kann diese direkt vom Peer
oder über Weiterleitungen anderer Peers erhalten. Verlässt
er ungewollt das Netzwerk, so nehmen die anderen Peers
nach einer gewissen Zeitspanne, in der sie nichts von ihm
mitbekommen haben, sein Verschwinden an. In Folge des
einen oder anderen Falles werden die Informationen zum
austretenden Peer entfernt.
In P2P-basierten Systemen werden die Systemressourcen
durch die Summe der von den Peers zur Verfügung gestellten
Ressourcen bestimmt. Um die Bereitschaft zur Ressourcenbereitstellung der Peers zu erhöhen, verwenden einige Systeme
sogenannte Anreiz-basierte Ansätze. Ein Peer, der dem System
mehr seiner Ressourcen – das heißt Upload-Kapazität – zur
Verfügung stellt, erhält Vorzüge gegenüber anderen Peers. Dies
kann sich zum Beispiel in der Qualität des Videos, aber auch
in der Abspielkontinuität widerspiegeln.
Narada
In [16] stellen Chu et al. mit Narada ein Mesh-basiertes P2PSystem vor. Die Peers dieses Systems organisieren sich selbst
über einen vollständig dezentralen Ansatz und benötigen dafür
globales Wissen über alle Peers. Dazu tauschen sie periodisch
untereinander Nachrichten aus, die Informationen über die
bereits bekannten Peers enthalten. Beim Joinen benötigt der
neue Peer – über einen beliebigen Bootstrap-Mechanismus –
eine Liste bereits existierender Peers über die er mit dem
Netzwerk verbunden wird. Im weiteren Verlauf wird das
Overlay durch das Entfernen und Aufbauen von Verbindungen optimiert. Die dafür verwendeten Bewertungsfunktionen
messen – als Aufbaukriterium – den Performance-Gewinn
und – als Abbaukriterium – die Anzahl der Pfade über diese
Verbindung. Mit Hilfe eines kürzeste Wege-Algorithmus wird
ein Baum in dem aufgespannten Mesh erzeugt, über den die
Daten von der Quelle – die als Wurzel dient – Push-basiert an
die Peers verteilt werden. Befinden sich mehrere Quellen im
System, so werden mehrere Bäume im Mesh erzeugt. In beiden
Varianten werden in Narada keine speziellen Kodierungen für
den Stream verwendet.
F. Kodierung des Streams
Das Teilen des Videostreams in mehrere Teilstreams und
das Versenden über verschiedene Wege führt zu einer höheren
Ausfallsicherheit und einer besseren Möglichkeit die Lasten
im Netzwerk zu verteilen. Dies lässt sich im einfachen Fall
durch das sogenannte Stream Splitting realisieren. Dabei wird
der Hauptstream in mehrere gleich große Pakete zerlegt und
auf die gewünschte Anzahl an Streams verteilt. Eine Variante,
mit der sowohl Redundanzen hinzugefügt als auch Fairness
leichter unterstützt werden können, stellt das Network Coding
dar. Bei dieser Variante reicht dem Empfänger eine Teilmenge
der Pakete aus, um den Stream abspielen zu können. Je mehr
Streams – das heißt Pakete – er zur Verfügung hat, desto
besser wird die Qualität des Videos. Ein Beispiel solch einer
Kodierung stellt die H.264/AVC-Erweiterung Scalable Video
Coding (SVC) [33] dar.
G. Berücksichtigung der Lokalität
Im Rahmen der Übertragungszeit-Optimierung zwischen
den Peers verwenden einige Systeme die physikalische Lokalität der Peers, um das Overlay-Netzwerk zu optimieren.
Diese kann sowohl einer geographischen als auch topologischen Lokalität entsprechen. Für die Optimierung der Übertragungszeit ist in erster Linie die topologische Lokalität im
zugrundeliegenden Netzwerk entscheidend. Einige Systeme
verwenden dazu die IP-Adressen der Peers, andere wiederum
approximieren die Entfernungen anhand der Übertragungszeiten oder Bandbreiten zwischen den Peers. Der zusätzliche
Aufwand beim Konstruieren und Verwalten des Overlays wird
wegen der Verringerung der Übertragungszeit und damit der
Gewährleistung eines stabileren Streams in Kauf genommen.
CoolStreaming/DONet
Mit DONet [38] entwickelten Zhang et al. ein Data-Driven
Pull-basiertes Mesh-Overlay-Netzwerk zur Übertragung von
Live-Streams. Eine skalierbare Internet-basierte Implementierung namens Coolstreaming [37] wurde auf Basis DONet’s
entwickelt. Ähnlich zu Narada besitzt jeder Peer eine Liste
aller aktiver Knoten, die durch einen periodischen Nachrichtenaustausch auf dem aktuellsten Stand gehalten wird.
Der Source-Knoten ist in DONet allseits bekannt und wird
beim Joinen kontaktiert. Von ihm erhält der neue Peer einen
zufällig gewählten existierenden aktiven Peer, von dem er eine
Liste von Peers erhält. Zu jedem dieser Peers versucht der
neue Peer eine Nachbarschaftsbeziehung aufzubauen. Für den
Datenaustausch des in Segmente zerteilten Streams werden
durchgehend Informationen über deren Verfügbarkeit mit Hilfe
sogenannter BufferMaps ausgetauscht. In einer BufferMap ist
– entsprechend dem Sliding Window-Verfahren – ein Bit zu
jedem Segment in der Nähe des aktuellen Abspielsegments
enthalten. Dieses gibt an, ob das Segment an einem Peer
verfügbar ist oder nicht. Jeder Peer kann dann über ein Bitmuster gewünschte Segmente entsprechend seines Schedulings
(zeitlichen Ablaufplans) anfragen. Dabei werden die selteneren
und schneller herunterladbaren Segmente priorisiert. Um die
Qualität des Streams zu erhöhen und eine stabile Anzahl
an Partnern zu gewährleisten, werden periodisch neue Nachbarschaftsbeziehungen mit einem zufällig gewählten aktiven
Knoten aufgebaut. Dabei wird wenn nötig der Partner, von
V. P2P-L IVE -S TREAMING -S YSTEME
Dieser Abschnitt gibt einen Überblick über existierende
Forschungssysteme und kommerzielle P2P-Live-StreamingSysteme. Die Systeme werden kurz bezüglich ihrer Funktionsweise erläutert und hinsichtlich der Eigenschaften aus
Abschnitt IV untersucht und unterschieden. Zunächst werden
Vorgehensweisen, die in allen Systemen gleichartig verwendet
werden, separat aufgeführt. Auf spezifische Abweichungen
wird in den speziellen Beschreibung der entsprechenden Systeme eingegangen.
Eine weit verbreitete Vorgehensweise ist der einheitliche
Umgang mit austretenden Peers. Beim Verlassen des Overlays
sendet ein Peer eine Nachricht an alle Peers, die ihn kennen.
64
~
5
dem im Durchschnitt am wenigsten Segmente pro Zeiteinheit
erhalten wurden, entfernt.
aktualisieren die eigene Sicht mit Hilfe dieser Informationen.
Im Rahmen dieser lokalen Sicht verwendet das System einen
Algorithmus um Schleifen zu erkennen und zu entfernen.
Abhängig von der Eingangsbandbreite werden Verbindungen
zu verschiedenen Anbietern aufgebaut. Ein Peer kann somit
auch über mehrere Anbieter und Abnehmer verfügen. Der
Stream selbst wird ohne weitere Kodierung mit Hilfe des Realtime Transport Protokolls (RTP) [32] von den Anbietern an die
Abnehmer Push-basiert übertragen.
MeshTV
MeshTV [3, 8] ist ein Pull- und Mesh-basiertes P2P-LiveStreaming-System, dessen Ansatz dem Data-Driven Ansatz
entspricht. Im Wesentlichen deckt sich die Funktionsweise mit
der von DONet. Im Gegensatz zu DONet beschränkt MeshTV
die Anzahl der Nachbarn eines Peers nicht. Dadurch kann in
MeshTV eine bessere Ausnutzung der Upload-Kapazität von
hochkapazitiven Knoten erreicht werden. Eine weitere Besonderheit dieses Systems liegt in der lokalen Optimierung des
Overlays hinsichtlich der Latenzzeit zwischen den Peers. Diese
– meist auch physikalisch kurzen – Verbindungen werden
dann auch für die Datenübertragung verwendet. Des Weiteren
stellt MeshTV sicher, dass alle Peers die benötigte Datenrate
über eine konstante Anzahl an Sendern empfangen können.
Außerdem wird die Anzahl der Nachbarn eines Peers in
Korrelation zur Bandbreite des Peers gehalten, um ungenutzte
Kapazitäten zu vermeiden.
Live-Streaming über BitTorrent
Cai, Xiaolu Zhang und Xuejie Zhang stellen in [4] ein auf
BitTorrent [5] basierendes Live-Streaming-System vor. Um
den Bedingungen eines Live-Streaming-Systems gerecht zu
werden, passten sie ein paar der BitTorrent-Mechanismen an.
So werden anstatt der seltenen Stücke die Stücke nahe des
Abspielzeitpunkts höher priorisiert. Auch das Verhalten des
Source-Knotens wurde angepasst. Er wird im sogenannten
Super Seeding Mode betrieben, in dem er sich als Leecher
– Peer ohne vollständige Datenverfügbarkeit – ausgibt. Dabei
stellt er einem Nachbarn erst dann weitere Daten zur Verfügung, wenn dieser die bereits erhaltenen Daten an andere
weitergegeben hat. Der Source-Knoten bekommt dies über
die periodischen Datenverfügbarkeitsnachrichten der anderen
Peers mitgeteilt. Wenn der Source-Knoten weiß, dass gewisse
Daten an einem Peer noch nicht verfügbar sein können, dann
kann er diese Daten zu ihm pushen. Der restliche Datenaustausch im aufgebauten Mesh läuft – wie in BitTorrent
üblich – über Pull-basierte Kommunikation ab. Sobald alle
Daten eines Streaming-Intervalls mindestens einmal verteilt
wurden, wechselt der Source-Knoten in den normalen Modus.
Um einen langsamen Start zu vermeiden, werden die aktiven
Nachbarn periodisch bestimmt und deren Anzahl auf einem
bestimmten Level gehalten.
PRIME
Magharei und Rejaie entwickelten mit PRIME [23] ein
Mesh-basiertes Live-Streaming-System. Das zufällig verbundene Netz entsteht dadurch, dass Peers einen BootstrappingKnoten nach Versorger-Peers fragen und sich mit diesen
verbinden. Jeder Peer versucht die Anzahl der Versorger-Peers
in Korrelation zu seiner Eingangsbandbreite zu halten. Die
Datenverteilung des in Teilstreams zerlegten Streams erfolgt
in zwei Phasen und in Intervallen. In der ersten Phase – der
Diffusion-Phase – werden die Daten über einen impliziten
Verteilungsbaum Pull-basiert von der Quelle ausgehend verteilt. Jedes Kind der Quelle und somit jeder Peer innerhalb
des entsprechenden Teilbaums erhält dabei nur Daten eines
Teilstreams. In der zweiten Phase – der Swarming-Phase –
versucht jeder Peer Pull-basiert an die fehlenden, aber bereits
verteilten, Daten der anderen Teilstreams zu gelangen. Dieses
Vorgehen hilft dem Flaschenhals durch zu wenig Bandbreite
oder durch zu wenig Daten an den Nachbarn vorzubeugen.
Chainsaw
Das von Pai et al. in [24] vorgestellte Chainsaw ist ein
Mesh-basiertes Live-Streaming-System, das sowohl in der Art
des Aufbauprozesses als auch der Datenverteilung dem im
letzten Abschnitt beschriebenen Live-Streaming-System über
BitTorrent entspricht. Lediglich der Super Seeding Mode des
anderen Systems wird nicht verwendet und die Wahl der Pullbasiert zu holenden Daten wird nur per Zufall getroffen. Da
dadurch viele Daten nicht rechtzeitig an den Peers zur Verfügung stehen würden, führten Pai et al. den Request OverridingAlgorithmus ein. Dazu verwaltet der Source-Knoten eine Liste
mit allen noch nie versendeten Datenpaketen. Ist die Liste
nicht leer, so sendet der Source-Knoten das älteste Paket der
Liste an den anfragenden Peer, sofern dieser ein nicht auf
der Liste enthaltenes Datenpaket angefragt hat. Dadurch wird
gewährleistet, dass jedes Datenpaket im Overlay verteilt ist.
STREAMCOMPLETE
Covino und Mecella entwickelten mit STREAMCOMPLETE [6, 7] ein Mesh-basiertes P2P-Live-Streaming-System, in
dem sich die Peers mit Hilfe verteilter Algorithmen selbst
verwalten. Kernelement dieses Systems ist der State of health-Parameter, der abhängig von den aktuell zur Verfügung
stehenden Ressourcen und Verbindungen zu anderen Peers
berechnet wird. Um die Gesamtperformance zu erhöhen wird
die sogenannte Fast-Top Prozedur verwendet. Abhängig von
dem Wert des State of health-Parameters tauschen Anbieter
und Abnehmer ihre Positionen im Overlay. Peers mit geringem
State of health werden somit am Rande des aufgebauten Meshs
und Peers mit besserem State of health näher an der Quelle
positioniert. Dadurch wird die Last dynamisch im System
verteilt. Um ein stabiles Overlay aufrecht erhalten zu können,
tauschen die Peers ihre lokalen Sichten untereinander aus und
PALMS
PALMS [14], ein zu DONet und BitTorrent ähnliches
Mesh-basiertes Live-Streaming-System, wurde von Hoong und
Matsuo entwickelt. Sowohl der Aufbau und die Verwaltung
65
6~
des Netzes geschehen analog zum DONet-Ansatz. In ihrer
Grundform verläuft die Datenverteilung ebenfalls ähnlich der
Verteilung in DONet und BitTorrent. Um jedoch die Verzögerung, die durch Verwendung des Pull-Mechanismus entsteht,
zu verringern, wird zudem auch ein Push-basierter Ansatz
verwendet. Dabei subskribieren sich Peers bei ihren Nachbarn, um deren neu erhaltene Pakete automatisch zugesendet
zu bekommen. Wird das Fehlen eines Paketes anhand der
Sequenznummer festgestellt, so kann dieses Paket über eine
NACK-Nachricht erneut angefragt werden. Um dem Heterogenitätsproblem der Peers entgegenzuwirken, wird der Originalstream mit Hilfe von Network Coding in Teilstreams zerlegt.
Je mehr Streams an einem Peer vorliegen, desto höher ist die
Qualität des Videos an diesem Peer. Um die Bereitstellung von
Ressourcen zu erhöhen und das Aufkommen von Freeridern
– Peers die sich nicht beteiligen – zu verringern, werden die
Peers für ihren Einsatz Punkte-basiert belohnt. Entsprechend
ihrer zentral hinterlegten Wertung dürfen sie nur Daten von
Peers laden, deren Wertung kleiner oder gleich der eigenen
Wertung ist. Je mehr sie sich beteiligen, desto flexibler dürfen
sie also ihre Peers auswählen.
nimmt ein Peer einen joinenden Peer mit einer gewissen
Wahrscheinlichkeit als Kind an oder gibt ihn weiter. Die
zufälligen Kanten werden nach dem Erhalt von Datenpaketen
eingefügt. Der Stream wird am Source-Knoten in gleich
große, mit einer Sequenznummer durchnummerierte Pakete
zerlegt und über den Verteilungsbaum zu allen Peers gepusht.
Sobald ein Peer durch eine Zufallskante einen Knoten findet,
von dem Pakete mit höherer Sequenznummer ankommen,
verwendet er diesen als neuen Eltern-Peer. Bei Ausfällen von
Peers wird der Baum ebenfalls mit Hilfe dieser Zufallskanten
repariert. Ist dies nicht möglich, so müssen die entsprechenden
Peers einen Rejoin durchführen. Um Rejoins zu vermeiden,
wird die Anzahl der Zufallskanten proportional zur Anzahl der
durchgeführten Rejoins gewählt. Der zu Beginn des Abschnitts
angesprochene Anreiz liegt darin, dass ein Peer, der sich
stärker an der Datenverteilung beteiligt, mehr Zufallskanten
aufbauen darf. Dadurch erfährt er weniger Unterbrechungen
und besitzt einen deutlichen Vorteil gegenüber unkooperativer
Peers. Als Maß für die Beteiligung wird die Anzahl der
Kinder eines Peers verwendet.
Overcast
LSONet
Overcast [18] ist ein Tree-basiertes P2P-System, das LiveStreaming unterstützt. Beim Joinen initialisiert sich der Peer
selbst und registriert sich in einem zentralen Register. Von
diesem erhält er eine Liste von Overcast-Netzwerken, in denen jeweils unterschiedliche Streams verteilt werden. Möchte
ein Peer einem konkreten Overlay beitreten, so beginnt der
Eltern-Auswahlprozess an der Wurzel, die dem Source-Knoten
entspricht. Als Eltern-Knoten wählt der neue Knoten den
am weitesten entfernten Knoten, bei dem er maximal 10%
Verlust – hinsichtlich der Datenrate – gegenüber der Wurzel
hinnehmen muss. Zudem entscheidet er sich auf jeder Ebene
für den Knoten – der innerhalb der 10% liegt – zu dem
die Anzahl an Hops am geringsten ist. Periodisch prüft jeder
Peer ob alle seine Kinder, an die er den Single Stream pusht,
noch vorhanden sind. Dazu, und um ein schnelleres Joinen
zu ermöglichen, verwaltet jeder Knoten eine Liste aller seiner
Kinder und deren Zustand. Diese Informationen werden bis zur
Wurzel nach oben propagiert. Peers können sich in Overcast
durch die Wahl eines neuen Eltern-Knotens an Änderungen
im zugrundeliegenden Netzwerk – zum Beispiel durch Fehler
oder Datenstau – anpassen. Dennoch garantiert Overcast mit
seinen Algorithmen keine optimale Topologie.
Bei LSONet [12, 13] handelt es sich um ein Mesh-basiertes
P2P-Live-Streaming-System, das eine Layer-Kodierung verwendet. Am Source-Knoten wird der Stream über Network
Coding auf mehrere Teilstreams (Layer) verteilt. Für jeden
dieser Layer wird ein eigenes Mesh aufgebaut. Ein Peer kann
gleichzeitig mehrere Layer von mehreren Sendern empfangen
und auch zu mehreren Empfängern schicken. Die Verfügbarkeit von Layern wird – im Gegensatz zu den anderen
Systemen – nur auf explizite Anfrage verschickt. Ein durch
den Pull-Mechanismus erhaltener Anbieter bleibt prinzipiell
durchgehend in dieser Rolle, bis er fehlschlägt oder das
Overlay verlässt. Beim Joinen wendet sich der neue Knoten an
einen der vielen Bootstrapping-Knoten und erhält von ihm eine
eindeutige ID. Ein Peer nimmt den neuen Knoten mit einer
gewissen Wahrscheinlichkeit als Empfänger an oder leitet ihn
an einen anderen weiter. Bei der Verwaltung des Overlays
werden Strategien wie LTM (location-aware topology matching) [21] verwendet, um das Overlay an die physikalische
Topologie anzupassen. Dazu gehört ebenfalls die periodische
Eliminierung langsamer Partner. Über einen Algorithmus wird
versucht, jedem Peer die maximale Anzahl an Layern zur
Verfügung zu stellen. Der Basis-Layer – der alleine ausreicht,
um das Video abzuspielen – erhält bei der Auswahl eine
höhere Priorität. Die über diesen Mechanismus realisierbare
Fairness wird in LSONet nicht betrachtet. Jedoch wird durch
diese Daten- und Pfadredundanz eine höhere Stabilität erreicht.
CTree
CTree [40] ist ein geclustertes, Tree-basiertes P2P-LiveStreaming-System. Die Peers werden dabei von einem zentralen Tracker, der für die Verwaltung des ganzen Systems
zuständig ist, in Cluster verteilt. Wie in Abbildung 3 zu sehen,
bilden diese Cluster einen Verteilungsbaum, dessen Wurzel
das Cluster mit dem Source-Knoten ist. Ein Elterncluster
versorgt push-basiert seine Kindercluster, wobei Peers eines
Clusters entweder von Peers aus dem Elterncluster oder aus
dem lokalen Cluster versorgt werden können. In CTree gibt
es zwei Arten von Peers, die über die Upload-Bandbreite unterschieden werden. Peers mit einer hohen Upload-Bandbreite
Climber
Climber [25, 26], ein hybrides Tree- und Mesh-basiertes
P2P-Live-Streaming-System, verwendet einen Anreizbasierten Ansatz, um die Beteiligung der Peers zu erhöhen.
Das Overlay wird durch einen Baum gebildet, der –
um redundate Verbundenheit herzustellen – mit weiteren
zufälligen Kanten versehen wird. Analog zu LSONet
66
~
7
Source
Cluster 1
Cluster 3
Knoten, die sich nicht an der Verteilung der Daten beteiligen,
werden aus dem Cluster ausgeschlossen.
Die Verteilung des in gleich große Teile zerlegten Streams
durch den Source-Knoten erfolgt Push-basiert an die sogenannten Power Nodes. Diese entsprechen den Knoten mit
der höchsten Beteiligung. Die Beteiligung der Peers wird
periodisch über eine spezielle Formel berechnet und über
den Tracker an den Source-Knoten weitergegeben. Zu Beginn
wählt er die Knoten mit dem größten Upload. Sobald ein
Peer im Cluster Daten erhält informiert er die anderen Peers,
so dass diese die Daten pullen und selbst verteilen können.
Dieses Vorgehen stellt zugleich einen Fairness-Mechanismus
dar. Ein Peer, der sich rege beteiligt, hat den Vorteil den Stream
unmittelbar und direkt vom Server zu erhalten. Zudem wird die
Gesamtperformance des Systems erhöht, da Peers mit einem
höheren Upload näher an dem Source-Knoten platziert sind.
Cluster 0
Cluster 2
Cluster 4
Cluster 5
Cluster
Power Peer (p-Peer)
Normal Peer (n-Peer)
Push des Gesamtstreams von p-Peer in Eltern- zu p-Peer in Kindcluster
Push eines Teilstreams von n-Peer in Eltern- zu n-Peer in Kindcluster
Verbindung zwischen Peers eines Clusters; Teilstreams werden gepullt
Abbildung 3.
Overlaystruktur von CTree (adaptiert aus [40])
werden p-Peer (Power Peer) genannt und werden beim Joinen
vom Tracker in ein neues Cluster gesetzt. Als Elterncluster
wird das Cluster verwendet, in den der p-Peer zunächst gejoint
wurde. Peers mit einer geringeren Upload-Bandbreite werden
als n-Peers (Normal Peers) bezeichnet und beim Joinen einem existierenden Cluster hinzugefügt. Dabei priorisiert der
Tracker die Cluster in der Nähe der Wurzel und Cluster mit
wenigen Peers. Jeder Peer bekommt beim Joinen einen Peer
des entsprechenden Clusters vom Tracker übermittelt und lernt
im Folgenden seine lokalen Peers und die des Elternclusters
kennen. Nach dem erfolgreichen Joinen eines Peers, aber
auch in fixen Abständen, aktualisieren alle Peers des lokalen
Clusters und der Kindercluster ihre Clusterinformationen. Der
Tracker hält Informationen zu allen Clustern und wird kontinuierlich aktualisiert. Dabei muss er nicht alle Peers kennen –
eine Teilmenge aus jedem Cluster reicht aus.
Die Daten, die der Source-Knoten streamt, werden von
ihm in gleich große Blöcke zerlegt und durchnummeriert.
Der Gesamtstream wird mit Hilfe der Blöcke auf unkodierte
Substreams verteilt. Jeder Peer hält nur zu einer Teilmenge
der bekannten Peers eine aktive Verbindung. Die n-Peers
wählen zufällig einige Peers aus dem lokalen Cluster und dem
Elterncluster um Substreams zu erhalten. Die p-Peers hingegen
wählen wenn möglich den p-Peer des Elternclusters, um von
ihm den Gesamtstream übermittel zu bekommen. Sollte dies
nicht möglich sein, so verhält sich der p-Peer wie ein n-Peer.
Im Gegensatz zu den Daten aus dem Elterncluster, werden
Daten innerhalb eines Clusters nur auf explizite Anfrage –
das heißt pull-basiert – versendet.
AnySee/Anysee2
Liao et al. stellen in [19] mit AnySee ein Mesh-basiertes
P2P-Live-Streaming-System vor, das sich auf Inter-OverlayOptimierung, das heißt auf die Optimierung zwischen verschiedenen Overlays, konzentriert. Dazu wird zunächst mit
Hilfe eines Bootstrapping-Knotens ein Mesh aufgebaut. Ähnlich zu LSONet wird das Overlay durch Strategien wie
LTM [21] an die physikalische Topologie angepasst. Über periodische Nachrichtenfluten wird die Overlay-Struktur durchgehend optimiert. Für die Optimierung des Datenflusses verwaltet jeder Peer jeweils eine Liste mit aktiven Pfaden und
mit Backup-Pfaden. Zunächst werden die Pfade innerhalb
des eigenen Overlays anhand der kürzesten Verzögerungszeiten bestimmt. Fällt die Anzahl der Backup-Pfade unter
einen Schwellwert, so werden Overlay-übergreifende Pfade
bestimmt. Diese werden über eine umgekehrte Suche – vom
Peer zum Source-Knoten – ebenfalls anhand der Verzögerungszeit ausgewählt. Der Datenaustausch des Single Streams
– mit Knoten der aktiven Pfade – erfolgt analog zu DONet
über einen Pull-Mechanismus.
Anysee2 [17] stellt eine Weiterentwicklung von AnySee dar.
Im Unterschied zu AnySee werden für den Austausch der
Kontroll- und Datennachrichten zwei unterschiedliche Strukturen verwendet. Die Ebenen des Baums, der für die Kontrollnachrichten aufgebaut wird, korrelieren mit Räumlichkeiten,
die sich über die IP-Adresse bestimmen lassen. Die erste Ebene unterscheidet die verschiedenen Internet Service Provider
(ISPs), die zweite diese anhand der Städte und so weiter. Für
den Datenaustausch wird ein Mesh zwischen den Nachbarn des
Kontrollbaums erzeugt. Die Anzahl der Kontrollnachrichten
konnte durch die Vermeidung der Nachrichtenfluten gegenüber
AnySee deutlich reduziert werden.
BEAM
BEAM [27, 28] ist ein von Purandare und Guha entwickeltes geclustertes, Mesh-basiertes P2P-Live-Streaming-System.
Ähnlich zu CTree verwendet BEAM einen zentralen Tracker,
der den Zustand des Systems verwaltet. Beim Joinen eines
Peers bekommt dieser vom Tracker eine Liste mit 40 Peers,
deren Bandbreite ähnlich zu der des neuen Knotens ist. Diesen
Knoten sendet er eine Cluster-Join-Nachricht, die diese annehmen sofern sie noch nicht in genügend Clustern enthalten sind.
In BEAM kann ein Knoten in mehreren Clustern enthalten
sein. Cluster können auch zu späteren Zeitpunkten über eine
ähnliche Nachricht neue Mitglieder für ihr Mesh gewinnen.
PPLive und SOPCast
Neben den bisher beschrieben Systemen existieren auch
kommerzielle Systeme wie PPLive2 und SOPCast3 . Da es sich
bei diesen Systemen um proprietäre Systeme handelt, können
2 PPLive.
http://www.pptv.com/en/.
http://www.sopcast.org/.
3 SOPCast.
67
8~
Name
Referenz
Struktur
Cluster
Koordinierung
Narada
CoolStreaming/DONet
MeshTV
PRIME
STREAMCOMPLETE
Live-Streaming über
BitTorrent
[16]
[37, 38]
[3, 8]
[23]
[6, 7]
Mesh & Tree
Mesh
Mesh
Mesh & Tree
Mesh
-
dezentral
de- & zentral
dezentral
de- & zentral
dezentral
Kommunikationsparadigma
Push
Pull
Pull
Pull
Push
[4]
Mesh
-
de- & zentral
Pull & Push
Chainsaw
[24]
Mesh
-
dezentral
Pull
Unterstützung
von Fairness
möglich
-
PALMS
[14]
Mesh
-
de- & zentral
Pull & Push
LSONet
[12, 13]
Mesh
-
dezentral
Pull
Climber
Overcast
CTree
BEAM
AnySee
Anysee2
[25, 26]
[18]
[40]
[27, 28]
[19]
[17]
[1, 10,
15, 22,
36]
Tree & Mesh
Single-Tree
Tree
Mesh
Mesh
Mesh & Tree
Mesh
Mesh
-
dezentral
dezentral
de- & zentral
de- & zentral
de- & zentral
de- & zentral
Push
Push
Push & Pull
Push & Pull
Pull
Pull
möglich durch
Kodierung
Peer-Auswahl
möglich durch
Kodierung
# Kanten
Platzierung
-
Mesh
-
de- & zentral
Pull
-
PPLive & SOPCast
SSt
SSt
SSt
NC
SSt
Lokalität
(Aspekt)
Latenzzeit
-
SSt
-
SSt
-
Kodierung
NC
-
LC
Latenzzeit
SSt
SSt
StS
SSt
SSt
SSt
# Hops
Latenzzeit
IP-Adresse
SSt
-
Tabelle I
Ü BERSICHT DER S YSTEME UND IHRER E IGENSCHAFTEN
Umsetzung von Fairness, Clustern, einer speziellen Kodierung
und auch die Berücksichtigung der Lokalität der Peers.
Eine zusammenfassende Übersicht über die vorgestellten
Systeme befindet sich in Tabelle I. Zu jedem System sind
dort die Eigenschaften aus Abschnitt IV angegeben. Nutzt ein
System Cluster, so ist die Topologie innerhalb des Clusters in
der Spalte Cluster hinterlegt. In der Spalte Unterstützung von
Fairness ist angegeben, in wie weit ein Fairness-Mechanismus
unterstützt wird. Ist ein solcher Mechanismus enthalten, so ist
das Gebiet angegeben, in dem sich ein beteiligender Peer einen
Vorteil verschaffen kann. Die Kodierungen in der vorletzten
Spalte sind wie folgt abgekürzt:
Informationen über sie ausschließlich aus Messungen des
Netzwerkverkehrs gewonnen werden. Eine Reihe von Untersuchungen stellte bei beiden Systemen ein ähnliches Verhalten
fest [1]. Beide Systeme erzeugen mit Hilfe eines zentralen
Servers ein Mesh [22, 36]. Dieser Bootstrapping-Knoten liefert
beim Joinen eine Liste von potenziellen Nachbarn. Durch
den periodischen Austausch der Nachbarlisten können neue
Nachbarn gewonnen werden. Im Gegensatz zu PPLive senkt
SOPCast die Rate, mit der die Nachbarlisten ausgetauscht
werden, mit der Zeit [15]. Für die Datenverteilung wird der
Stream ähnlich zu DONet in Segmente zerlegt und durch
die Verwendung von BufferMaps Pull-basiert verteilt [10].
Fairness-Mechanismen sind in keinem der beiden beiden Systeme enthalten. So können Peers keine oder um die 15-20
Kinder besitzen und werden dabei gleichberechtigt behandelt.
Bei der Optimierung des Overlays werden die Anbieter nur
anhand deren Performance ausgewählt. Die Lokalität der Peers
wird dabei vollständig außer Acht gelassen [1].
•
•
•
•
SSt = Single Stream
StS = Stream Splitting
NC = Network Coding
LC = Layer-Kodierung
In der Spalte Lokalität sind alle Aspekte, die zur Betrachtung
der Lokalität verwendet werden, aufgelistet.
Wie in der Tabelle zu sehen ist, werden meist Mesh-basierte
Systeme mit Single Stream verwendet. Diese werden alle durch
dezentrale Ansätze verwaltet. Nur wenige benötigen zusätzlich
eine zentrale Instanz. Ebenfalls wird deutlich, dass sich die
meisten Systeme auf spezielle Aspekte spezialisiert haben und
kein System existiert, das versucht, in allen Eigenschaften nahe
ans Optimum zu gelangen. Somit müssen bei der Auswahl
eines Systems weiterhin alle Eigenschaften gegeneinander
abgewogen werden.
Neben den neuen Ausprägungen und der Weiterentwicklung der beschriebenen Eigenschaften muss in Zukunft
viel Forschung im Bereich der gesamtoptimierten P2P-LiveStreaming-Systeme betrieben werden. Dadurch könnte die
Auswahl relevanter Systeme allein durch den Einsatzzweck
getroffen werden, ohne dabei alle Eigenschaften gegeneinander abwägen zu müssen.
VI. FAZIT
Durch den rapiden Anstieg der Live-Streaming-Nutzer und
der immer weiter wachsenden Bandbreite der Internetanschlüsse, stellen P2P-basierte Systeme eine kostengünstige und
skalierbare Alternative zum Client-Server Modell dar. Die
Belastung des Streamservers wird deutlich reduziert und im
Gegensatz zu IP-Multicast werden keine besonderen Anforderungen an das zugrundeliegende Netzwerk gestellt.
Bei der Betrachtung existierender Klassifikationen solcher
Systeme wurde festgestellt, dass keine umfassende Klassifikation möglich ist. Um dennoch kein System auszuschließen,
wurden die in der Übersicht vorgestellten Systeme hinsichtlich ihrer Eigenschaften untersucht. Neben den grundlegenden
Eigenschaften wie der Struktur des Overlays, der Art der
Koordinierung und dem verwendeten Kommunikationsparadigma, bieten einige Systeme weitere Eigenschaften wie die
68
~
9
L ITERATUR
[22] Yue Lu, Benny Fallica, Fernando A. Kuipers, Robert E. Kooij, and
Piet Van Mieghem. Assessing the quality of experience of sopcast.
Int. J. Internet Protoc. Technol., 4:11–23, March 2009.
[23] Nazanin Magharei and Reza Rejaie. Prime: peer-to-peer receiver-driven
mesh-based streaming. IEEE/ACM Trans. Netw., 17:1052–1065, August
2009.
[24] Vinay Pai, Kapil Kumar, Karthik Tamilmani, Vinay Sambamurthy, and
Alexander E. Mohr. Chainsaw: Eliminating trees from overlay multicast.
Peer-to-peer systems IV, pages 127–140, 2005.
[25] Kunwoo Park, Sangheon Pack, and Taekyoung Kwon. Climber: an
incentive-based resilient peer-to-peer system for live streaming services.
In Proceedings of the 7th international conference on Peer-to-peer
systems, IPTPS’08, pages 10–10, Berkeley, CA, USA, 2008. USENIX
Association.
[26] Kunwoo Park, Sangheon Pack, and Ted „Taekyoung“ Kwon. An adaptive peer-to-peer live streaming system with incentives for resilience.
Comput. Netw., 54:1316–1327, June 2010.
[27] Darshan Purandare and Ratan Guha. An alliance based peering scheme
for peer-to-peer live media streaming. In Proceedings of the 2007
workshop on Peer-to-peer streaming and IP-TV, P2P-TV ’07, pages
340–345, New York, NY, USA, 2007. ACM.
[28] Darshan Purandare and Ratan Guha. BEAM: A Peer-to-Peer Framework
for Live Media Streaming. Technical report, University of Central
Florida, Orlando, 2007.
[29] Sylvia Ratnasamy, Paul Francis, Mark Handley, Richard Karp, and Scott
Shenker. A scalable content-addressable network. In Proceedings of
the 2001 conference on Applications, technologies, architectures, and
protocols for computer communications, SIGCOMM ’01, pages 161–
172, New York, NY, USA, 2001. ACM.
[30] Antony Rowstron and Peter Druschel. Pastry: Scalable, decentralized object location, and routing for large-scale peer-to-peer systems. In Rachid
Guerraoui, editor, Middleware 2001, volume 2218 of Lecture Notes in
Computer Science, pages 329–350. Springer Berlin / Heidelberg, 2001.
[31] Rüdiger Schollmeier. A definition of peer-to-peer networking for the
classification of peer-to-peer architectures and applications. In Peer-toPeer Computing, 2001. Proceedings. First International Conference on,
pages 101 –102, August 2001.
[32] Henning Schulzrinne, Stephen L. Casner, Ron Frederick, and Van Jacobson. RTP: A transport protocol for real-time applications. IETF Request
for Comments: RFC 3550, july 2003. http://tools.ietf.org/html/rfc3550.
[33] Heiko Schwarz, Detlev Marpe, and Thomas Wiegand. Overview of the
scalable video coding extension of the h.264/avc standard. Circuits and
Systems for Video Technology, IEEE Transactions on, 17(9):1103 –1120,
2007.
[34] Thomas Silverston and Olivier Fourmaux. Source vs data-driven approach for live p2p streaming. In Networking, International Conference
on Systems and International Conference on Mobile Communications
and Learning Technologies, 2006. ICN/ICONS/MCL 2006. International
Conference on, pages 99 – 99, 2006.
[35] Ion Stoica, Robert Morris, David Karger, M. Frans Kaashoek, and Hari
Balakrishnan. Chord: A scalable peer-to-peer lookup service for internet
applications. In Proceedings of the 2001 conference on Applications,
technologies, architectures, and protocols for computer communications,
SIGCOMM ’01, pages 149–160, New York, NY, USA, 2001. ACM.
[36] Long Vu, Indranil Gupta, Jin Liang, and Klara Nahrstedt. Measurement
and modeling of a large-scale overlay for multimedia streaming. In
The Fourth International Conference on Heterogeneous Networking
for Quality, Reliability, Security and Robustness & Workshops,
QSHINE ’07, pages 3:1–3:7, New York, NY, USA, 2007. ACM.
[37] Susu Xie, Bo Li, Gabriel Y. Keung, and Xinyan Zhang. Coolstreaming:
Design, theory, and practice. Multimedia, IEEE Transactions on,
9(8):1661 –1671, 2007.
[38] Xinyan Zhang, Jiangchuan Liu, Bo Li, and Tak-Shing Peter Yum.
Coolstreaming/donet: a data-driven overlay network for peer-to-peer live
media streaming. In INFOCOM 2005. 24th Annual Joint Conference of
the IEEE Computer and Communications Societies. Proceedings IEEE,
volume 3, pages 2102 – 2111 vol. 3, 2005.
[39] Ben Y. Zhao, John D. Kubiatowicz, and Anthony D. Joseph. Tapestry:
An infrastructure for fault-tolerant wide-area location and. Technical
report, Berkeley, CA, USA, 2001.
[40] Qinglin Zhu, Rui Wang, Depei Qian, and Feng Xiao. Re-exploring the
potential of using tree structure in p2p live streaming networks. In Network and Parallel Computing, 2009. NPC ’09. Sixth IFIP International
Conference on, pages 125 –132, 2009.
[1] Shahzad Ali, Anket Mathur, and Hui Zhang. Measurement of Commercial Peer-to-Peer Live Video Streaming. 2006.
[2] Farid Benbadis, Fabien Mathieu, Nidhi Hegde, and Diego Perino.
Playing with the bandwidth conservation law. In Peer-to-Peer Computing
, 2008. P2P ’08. Eighth International Conference on, pages 140 –149,
2008.
[3] Bartosz Biskupski, Raymond Cunningham, and Rene Meier. Improving
throughput and node proximity of p2p live video streaming through
overlay adaptation. In Multimedia, 2007. ISM 2007. Ninth IEEE
International Symposium on, pages 245 –253, 2007.
[4] Qingchao Cai, Xiaolu Zhang, and Xuejie Zhang. Streaming live media
over bittorrent. In Communications and Mobile Computing, 2009. CMC
’09. WRI International Conference on, volume 3, pages 44 –49, 2009.
[5] Bram Cohen. Incentives build robustness in BitTorrent. In Workshop on
Economics of Peer-to-Peer systems, volume 6, pages 68–72, 2003.
[6] Federico Covino and Massimo Mecella. Design and evaluation of a
system for mesh-based p2p live video streaming. In Proceedings of the
6th International Conference on Advances in Mobile Computing and
Multimedia, MoMM ’08, pages 287–290, New York, NY, USA, 2008.
ACM.
[7] Federico Covino and Massimo Mecella. Streamcomplete: an architecture
for mesh-based peer-to-peer live video streaming. In Proceedings of the
6th IEEE Conference on Consumer Communications and Networking
Conference, CCNC’09, pages 1004–1008, Piscataway, NJ, USA, 2009.
IEEE Press.
[8] Raymond Cunningham, Bartosz Biskupski, and René Meier. Managing
peer-to-peer live streaming applications. In Proceedings of the 8th
IFIP WG 6.1 international conference on Distributed applications and
interoperable systems, DAIS’08, pages 140–153, Berlin, Heidelberg,
2008. Springer-Verlag.
[9] Stephen E. Deering and David R. Cheriton. Multicast routing in
datagram internetworks and extended lans. ACM Trans. Comput. Syst.,
8:85–110, May 1990.
[10] Benny Fallica, Yue Lu, Fernando Kuipers, Rob Kooij, and Piet Van
Mieghem. On the quality of experience of sopcast. In Next Generation
Mobile Applications, Services and Technologies, 2008. NGMAST ’08.
The Second International Conference on, pages 501 –506, 2008.
[11] Mário Rui Vazão Vasco Ferreira. Live streaming in overlay networks,
october 2010. Master Thesis, Instituto Superior Técnico.
[12] Hui Guo, Kowk-Tung Lo, and Chi-Tsun Cheng. Overlay networks
construction for multilayered live media streaming. In Multimedia, 2006.
ISM’06. Eighth IEEE International Symposium on, pages 427 –436,
2006.
[13] Hui Guo, Kwok-Tung Lo, and Jiang Li. Lsonet: A case of layerencoded video transmission in overlay networks. In Tat-Jen Cham,
Jianfei Cai, Chitra Dorai, Deepu Rajan, Tat-Seng Chua, and LiangTien Chia, editors, Advances in Multimedia Modeling, volume 4351 of
Lecture Notes in Computer Science, pages 485–494. Springer Berlin /
Heidelberg, 2006.
[14] Poo Kuan Hoong and Hiroshi Matsuo. Push-pull incentive-based p2p
live media streaming system. WTOC, 7:33–42, February 2008.
[15] Akos Horvath, Miklos Telek, Dario Rossi, Paolo Veglia, Delia Ciullo,
Maria Antonieta Garcia, Emilio Leonardi, and Marco Mellia. Dissecting
PPLive, SopCast, TVAnts. submitted to ACM Conext, 2008.
[16] Yang hua Chu, Sanjay G. Rao, Srinivasan Seshan, and Hui Zhang. A
case for end system multicast. Selected Areas in Communications, IEEE
Journal on, 20(8):1456 – 1471, October 2002.
[17] Qi Huang, Hai Jin, and Xiaofei Liao. P2p live streaming with tree-mesh
based hybrid overlay. In Parallel Processing Workshops, 2007. ICPPW
2007. International Conference on, pages 55 –55, 2007.
[18] John Jannotti, David K. Gifford, Kirk L. Johnson, M. Frans Kaashoek,
and James W. O’Toole, Jr. Overcast: reliable multicasting with on
overlay network. In Proceedings of the 4th conference on Symposium
on Operating System Design & Implementation - Volume 4, OSDI’00,
pages 14–14, Berkeley, CA, USA, 2000. USENIX Association.
[19] Xiaofei Liao, Hai Jin, Yunhao Liu, Lionel M. Ni, and Dafu Deng.
Anysee: Peer-to-peer live streaming. In INFOCOM 2006. 25th IEEE
International Conference on Computer Communications. Proceedings,
pages 1 –10, 2006.
[20] Yong Liu, Yang Guo, and Chao Liang. A survey on peer-to-peer video
streaming systems. Peer-to-peer Networking and Applications, 1(1):18–
28, 2008.
[21] Yunhao Liu, Li Xiao, Xiaomei Liu, Lionel M. Ni, and Xiaodong Zhang.
Location awareness in unstructured peer-to-peer systems. Parallel and
Distributed Systems, IEEE Transactions on, 16(2):163 – 174, 2005.
69
~
1
HARVESTING SENSOR NETWORKS
Harvesting Sensor Networks
Andreas Straninger
nodes.
The paper is structured as follows. Section II explains
the properties of harvesting sensor nodes and introduces the
terminology used. In Section III, algorithms for optimizing
the energy available for a node are explained. Section IV
introduces algorithms, which address sensor network specific
problems. Harvesting specific algorithms for rate adaption,
routing and compression are depicted. Finally in Section V,
a conclusion is drawn and ideas for future research are given.
Abstract—Battery powered Wireless Sensor Networks only
have a limited lifetime and have to be replaced if the battery
drops to zero. Using renewable energy sources to recharge
batteries allows sensor nodes theoretically to attain indefinite
lifetime. Thus, the focus moves from maximizing the lifetime
to maximizing the usage of harvestable energy. This affects the
sensors energy saving strategies, rate adaption, the establishment
of routes, compression and the use of error correcting codes. This
Seminar work aims to give an overview on algorithms, which
maximize the efficiency of harvesting sensor nodes.
I. I NTRODUCTION
Sensors are widely used for gathering information about the
environment. One task for a sensor network is field monitoring,
where sensors are deployed at an area and information is
routed to one or more base stations (see e.g. [2]). Sensors
regularly collect information, e.g. temparature or humidity, at
a constant rate. The maximum sensing rate for each sensor
would be of interest. Another task, which could be performed
by sensor nodes deployed over a field is event monitoring. In
constrast to field monitoring, only a selected set of events is
transmitted, e.g. detected smoke by a fire sensor.
Currently, most sensors are supplied by a battery and have
to be exchanged, when the sensor node gets out of energy.
Algorithms for maximizing the lifetime in sensor networks
with batteries are used. Recent works propose the usage of
renewable energy sources for sensors in combination with
rechargable batteries. If the battery is low, a sensor can shut
down components to reduce energy consumption and reload
the battery, when energy is available and can be harvested. A
harvesting sensor can theoretically work forever.
Energy sources, which can be used in harvesting sensor
networks (e.g. [6]) are solar, mechanical and thermal energy.
Solar energy can be harvested outdoors from the sun or
indoors from artificial lights with solar panels. Mechanical
energy occurs as vibrational or kinetic energy. Vibrations are
harvested by using a piezoelectric capacitator, kinetic energies
can be harvested with generators. Thermal energy in terms of
temperature differences can also be harvested.
The transmission range of sensors usually is limited. Each
Sensor collects informations, initiates the transmission of
collected informations and routes information to the sink.
Compared to a peer to peer network, connections cannot be
established arbitrarily. Only connections to locally near sensor
nodes are possible. Sensors buffer the information collected
and send it to neighbour nodes.
In harvestin sensor networks, optimal routes do not necessarily follow the shortest paths with the least possible number
of hops. Instead, a routing algorithm would prefer nodes with
the highest possible harvesting opportunities.
Maximization of energy usage from the environment is one
of the task which emerges from the usage of harvesting sensor
II. BASICS
The authors in [2] suggest 3 kinds of energy storage,
harvesting systems with no energy storage, harvesting systems
with ideal energy buffer and harvesting systems with non-ideal
energy buffer. In harvesting systems with no energy storage,
for each point in time only the energy harvested can be used. A
harvesting systems with ideal energy buffer is able to store and
restore all the energy harvested without any losses. Harvesting
systems with non-ideal energy buffers have a limited storage
capacity, a charging efficiency < 100% and also have a leakage,
i.e. a loss of energy over time.
In the following it is assumed if not explicitly mentioned,
that sensors use batteries as a non-ideal energy buffer. In
practice, ultra capacitators and rechargable batteries are used
as energy buffers. Ultra capacitators have a high charging
efficiency but also a high leakage and a low energy density, i.e.
storage capacity per volume. They can be used if high power
is available over small time intervals of about a second or less.
Rechargable batteries usually have a higher energy density and
are suitable for energy that is available for longer periods of
time.
Sensor nodes use algorithms to control the energy consumption and adjust the duty cycle. The duty cycle is the fraction
of time, where the sensor is busy. Sensors are either in active
mode or consume a small amout of energy in sleep mode.
Empty batteries should be avoided because sensors regularly
have to switch to active mode to sense information. A sensor
which harvests the same amount energy which it consumes
over the time it is deployed, without getting out of battery
energy, works at energy neutral operation.
If a sensor consumes more energy than harvested before,
the battery level may drop to zero and the sensor may be
interrupted. On the other hand, if a sensor consumes less
energy than possible, the battery may be fully loaded and thus
not able to store surplus energy harvested. Hence, an algorithm
that optimizes the duty cycle has to estimate the future
harvesting opportunities, so that energy neutral operation is
possible, and no energy is wasted.
Sensors usually provide a sleep mode, where a minimum
amount of energy is consumed. In active mode, a sensor
70
2~
may reduce the energy consumption by switching off parts of
the hardware e.g. the sensing module or the communication
module. Besides, a sensor needs energy for each transmission
of data. Thus, an optimized sensing rate and optimal routes
for a minimized amout of energy needed for transmission is
searched.
To measure the current energy produced in an interval, [2]
recommend to monitor the energy production of the harvesting
source rather than monitoring the battery level because there
is only a small change in change of voltage at the battery,
compared to the change of voltage in the harvesting module.
Algorithms operate either on global knowledge or on local
knowledge. Algorithms with global knowledge have information about the state of each deployed sensor node. They can
run on a node with high computation power. However, the
collection of sensor node states leads to additional transmission overhead and delays. The transmission overhead will be
to high to be neglected and delays can cause nodes to make
necessary adjustments too late and operate with suboptimal
parameters. Algorithms which directly operate on a sensor
node with local knowledge only have information about the
state of the sensor node and can determine the state of
neighboring nodes. Since computation power of sensor nodes
is limited, low complexity solutions are required.
With the ability to adapt the duty cycle, the energy wastage
can be minimized. The following section addresses the issue
of optimizing the duty cycle with the use of the state of the
sensor node and its sourrounding.
opportunities are not known in advance. The algorithm proposed makes predictions about future harvesting opportunities
in a first step and then in a second step determines the optimal
duty cycle. The duty cycle is readjusted in a third step, if the
energy harvested deviates from the energy predicted.
In the first step, the algorithm predicts the energy available with an Exponentially Weightetd Moving-Average. The
predicted value x̄(i) at time i is:
x̄(i) = αx(i − 1) + (1 − α)x(i)
where x(i) is the energy harvested at time i. Several values
for α have been tested and a value of α = 0.5 is suggested.
In experiments, an initial training for 72 hours has been
performed before the usage of the sensor nodes. Predictions
for each slot x(i) are refreshed after the energy energy yield
at slot i has been determined. A window size of 24 hours is
chosen, consisting of NW time slots x ∈ W . In experiments,
NW = 48 time slots have been chosen with a size of 30
minutes each.
The algorithm distinguishes sun duty cyles S = {i|Ps (i) −
Pc ≥ 0} where more energy is harvested than consumed
and dark duty cycles D = {i|Ps (i) − Pc ≥ 0} where more
energy is consumed than harvested. The optimization problem
is reformulated as:
NW
X
i=1
In this section, algorithms for energy prediction and energy
usage are presented. The algorithms either schedule the duty
cycles on the basis of energy observations or learn how to
optimally adapt the duty cycle on the basis of the current
sensor state. In the following, one scheduling algorithm and
two algorithm that work on current sensor states are presented.
A. Scheduling duty cycles
The authors in [2] present an algorithm that maximizes the
duty cycle over the time, where the sensor is deployed. The
algorithm is designed for solar harvesting sensors, therefore it
is postulated, that energy patterns reoccure periodically. The
period, a day for solar harvesting sensors, is divided into NW
time slots. For each time slot i, the power harvested Ps (i), the
power consumed Pc (i) and the duty cycle D(i) are considered
to be constant. The maximization of duty cycles is expressed
as
NW
X
X
i∈D
D(i)[
X
1
Pc
+ Ps (i)(1 − )] +
Pc D(i)
η
η
i∈S
In the second step, the minimum admissible duty cycle is
assigned for time slots, where more energy is consumed than
harvested and the maximum admissible duty cycle is assigned
for time slots, where less energy is consumed than harvested.
Then two cases may occure, either there is still energy
available or too much energy is assigned to the duty cycles.
In the first case, the maximum duty cycle is assigned to additional slots in D, dependent on their harvesting opportunities.
Otherwise, the duty cycle of all slots in S is reduced uniformly
by a modifier δ.
After each time slot, the algorithm corrects in the third
step the duty cycle assigned. If less energy is harvested than
predicted, the duty cycle of some future time slots is reduced
to the minimum duty cycle. Otherwise duty cycles with the
lowest duty cycles are increased.
In evaluation the authors compared their low complexity
algorithm with local knowledge to an optimal solution, which
is calculated with global knowledge. They used the same
energy prediction method for both algorithms and achieved
a good result for the low complexity variant. A drawback of
the algorithm is that harvesting predictions are only usable
after 72 hours. Thus, the sensor would have to work initially
on a reduced duty cycle.
III. E NERGY P REDICTION AND U SAGE
max
Ps (i) =
D(i)
i=1
An optimization problem is formulated that takes the power
harvested, the power consumed, the battery level and properties of the battery into account. The problem can be solved
with high computational power and knowledge about future
harvesting opportunities. Since the optimization problem is too
complex to be solved on sensor nodes, the authors propose a
local low complexity solution. Furthermore, future harvesting
B. Learning adaption rules
The Idea of the algorithm introduced by Vigorito [7] is to
minimize the usage of the battery. This is done on the one
hand to minimize the losses which occure when charging or
discharging batteries. Then, if the battery is full, energy which
71
~
3
A probabilistic approach for adapting the energy usage
of sensor nodes is presented in [4]. Only two states for
sensor nodes are assumed, an active mode and a sleep mode.
Transations between the states are determined by strategies
which are based on properties of the sensor, the battery
state or the queue for outgoing messages, or properties of
the sourrounding, the channel quality or the solar radiation.
Hybrid strategies which use more than one properties are also
mentioned. For example, a strategy which is based only on
the message queue of size 10 containing x messages and can
be formulated in the following way:
cannot be used is wasted and if the batterie is empty, the node
gets out of energy. Finally, most types of batteries like NiMH
and Li-Ion Batteries have a longer lifetime if they are not
completely discharged.
The algorithm aims to minimize the quadratic deviation of
the battery level Bt from the desired level B ∗ . In other words,
the algorithm tries to minimize the equation
lim
N →∞
N
X
t=1
(Bt − B ∗ ).
To achieve this, the algorithm makes use of control theory.
The Battery Level at time Bt + 1 can be expressed as
Pactive→sleep (x) = 0.8|x ≤ 4
Pactive→sleep (x) = 0.3|x > 4
Bt+1 = aBt + but + cwt + wt+1
Psleep→active (x) = 0.3|x ≤ 3
where ut is the utility of the sensor, and wt is some noise.
a, b and c are unknown constants. It is mentioned in [7], that
the optimal control law for ut is
Psleep→active (x) = 0.7|x > 3
The authors analyzed the influence of different strategies on
the package drop rate respectively the package blocking rate.
This was done by modeling the arrival of packages at a node
as a batch markovian arrival process, where states are defined
for each of the properties and for the state of the sensor node
S ∈ wake, sleep.
B ∗ − (a + c)Bt + cB ∗
ut =
b
The constants a, b, c are calculated via fixpoint iteration.
Thus, θ = (a + c, b, c)T and φt = (Bt , ut , −B ∗ )T are defined
with φTt θ = y ∗ . θ is calculated with fixpoint-Iteration. Using
fixpoint iteration has the advantage, that a, b and c do not
necessarily have to be constant but may change over time.
Update rule is given by
θ̂t+1 = θ̂t +
µ
φTt φt
IV. ROUTING AND N ETWORK
A. Maximum flow
[2] suggest an approach for maximizing the throughput and
determining a constant sensing rate which is equally assigned
at all sensor nodes. The energy consumption of a node is given
by
φt (Bt+1 − φTt θ̂t )
The authors also provide a way to reduce the variance of
the duty cycle. Therefore, ut is not used directly, instead, the
smoothened duty parameter pt is calculated:
P (i, j) = r[α1 + α2 d(i, j)2 ]
ut ¯+ 1 = u¯t + α(u − ū)
where “d(i, j) is the distance” between nodes i and j, r is
the data rate and “α1 and α2 are radio [frequency] dependent”
constants. Given the duty cycle for node i at time t, problem
can be formulated as a maximal flow problem where the duty
cycle determines the maximal flow through a sensor node and
the power P (i, j) determines the actual costs for sending a
message from node i to node j. After assigning the flow, the
maximum sensing rate can be computed. The algorithm still
does not allow the adjustment of sensing rates based on local
knowledge. Besides, the approach does not allow sensing rates
to be readjusted if the energy harvested varies.
It is an exponentially weighted utility with old values of u
with α < 1. Then,
pt+1 = βut + (1 − β)ūt
with 0 ≤ β ≤ 1 is calculated.
Experimental results have been made with µ = 0.001 and
different values for α and β. Best results could be achieved
with α = 10−4 and β = 0.25 with time steps of 1 minute.
The authors compared their solution to the algorithm proposed in [2] and claim to achieve better results with their
algorithm. At evaluation, a higher uptime, lower variance of
the battery level, and a higher duty cycle was measured. The
evaluation was done as a simulation, where measured data of
sensors have been used.
B. Rate adaption
An approach, which calculates the throughput for a network
with fixed routes is presented in [1]. The optimal throughput
can be calculated centrally by solving a liniear programming
problem. This is done by formulating the necessary constraints
for energy consumption of the sensor node, energy needed for
routing, and properties of energy neutral operation dependent
on the sensing rate.
A local solution for the problem is constructed in two steps.
First, the maximum sensing rate is calculated for each sensor
node. If the battery would drop to zero after a time interval, the
C. Probabilistic duty cycle adaption
Duty cycle adaption algorithms specify the fraction of time,
where the sensor is in the wake state or in the sleep state. If a
sensor is set to a specific duty cycle, it is not clear, at which
parts of the sensors are active and at which intervals they are
active.
72
4~
sensing rate is adapted. In a second step, each node initiates a
request for the sensing rate. The desired rate initially is set to
the maximum rate. If a node between the initiator and the sink
is not capable of assigning the requested rate for the initiator,
all existing assignments are adapted in a fair way and updates
are sent.
The authors collected harvesting profiles and sensing rates
on from a sensor environment and evaluated the algorithm in
a simulator. A high running time of the algorithm occured
due to frequent rate adaptions. The authors also mention, that
higher rates could be assigned more homogeneously among
sensor nodes if alternate routes would be possible.
Fig. 1. Comparison of routes calculated with MP, MF and R-MPRT. Dark
areas correspond to low harvesting opportunities, bright areas correspond to
high harvesting oppor. Source: [3]
The randomized minimum path energy (R-MPE) algorithm,
computes the minimum path energy, i.e. the energy, which is
necessary to route a package from the current node to the sink
over a selected next hop neighbor. The probability for choosing
a node as the next hop neighbor is inversely proportional to
the minimum path energy.
The randomized minimum path recovery time (R-MPRT)
algorithm is similar to R-MPE. Instead of the link energy,
the path recovery time is used, i.e. the time needed to harvest
the link energy at the sender node.
Finally, with the randomized maxflow (R-MF) algorithm, the
optimal flow for each node is centrally calculated. The propability for selecting a node for the next hop are proportional to
its optimal flow. Since the algorithm cannot operate on local
knowledge, but also uses random node selection, it is only
introduced for comparison purposes.
The authors showed, that the energy aware algorithms, RWMP, R-MPE and R-MPRT, perform better than the MP
algorithm. Though, compared to the optimal flow, R-MPE
and R-MPRT have a performance of about 10% to 40%. In
evaluation, the routes were chosen individually for each message. Nevertheless, establishing static routes and reestablishing
them regularly is possible to use the rate adaption algorithm
presented in this section.
Variations of the algorithm R-MPRT can be of use. Firstly,
the duty cycle can be used for creating the routing tables
instead of the minimum path energy. Then, the authors only
address route selection for field monitoring. If routes for event
monitoring are required, the maximum delay can be used
instead of the minimum path energy.
C. Greedy Routing
A quite simple routing approach is presented in [8]. The
algorithm selects the most promising node for next hops
dependent on the euclidean distance between the current node
and the receiver node, the link state quality, as well as the
battery level and the energy production and consumption rates.
Informations can be sent between any two sensor nodes in the
network.
This approach balances the load so that overload situations
of nodes are prevented. However, the energy aware greedy
routing approach is not the best choice for the monitoring tasks
of sensors. Firstly, each sensor node usually only routes its
information to one sink. Arbitrary routes are not required and
may lead to unneccessary computational overhead. Secondly,
no routing tables are used, and thus greedy routing may not
be able to find a route in some cases.
D. Harvesting aware Routing Tables
Routing tables can be used to determine routes between
two sensor nodes. For event monitoring and field monitoring,
each sensor node has to be able to establish a route only to
a collecting node, but not between each other. In a sensor
network, where each sensor node has enough energy, a node
would keep track about the minimum number of hops to reach
a collecting node. Routes would be established to minimize the
number of hops. Hence, in harvesting sensor networks, the
throughput is limited by the amount of energy harvestable.
Thus a higher node availability and thus a higher throughput
is expected, if nodes with higher harvesting opportunities are
preferred.
In [3], five algorithms for harvesting sensor networks are
presented and evaluated in a simulation environment. For each
sensor node, the average harvesting capabilities are known.
The minimum path (“MP”) algorithm selects the shortest path
based on the minimum number of hops.
For the other four algorithms, nodes randomly make a selection of their next hops. In the randomized weighted minimum
path (R-WMP) algorithm, the probability for selecting a node
for the next hop is inversely proportional to the package
energy, and to minimum number of hops from the next hop
node to the sink. The package energy is the energy necessary
to transmit the message from the current node to the next hop
node.
E. Compression
Properties about static routes are also discussed in [5]. The
authors propose to aggregate and compress data and in this
way save energy and reduce the number of messages sent.
The authors state, that individual routes, which are established for each message arouse data collisions. Additionally,
sensor nodes can aggregate and compress data with the same
destination to reduce the amount of transferred data and thus
save energy.
The method presented divides the area, where sensor nodes
are deployed into regions. For each region, a node is chosen
which is denoted “border node”. A border node in harvesting
sensor networks should be close to the sink and have high
73
~
5
by taking into account the availability of renewable energy
sources. Sophisticated methods can be developed to minimize
the number of necessary sensors given a sensing task and a
map of energy desities over an area.
Besides duty cycle adaption for single sensor nodes, neighborhood aware duty cycle adaption for harvesting nodes could
improve the transmission options. Successful transmission is
only possible, if two neighboring sensor nodes have both
switched on their transceiver module. If the sensor nodes
are deployed adversely, so that similar duty cycles at the
same time for both sensors are improbable, a connection
will be established rarely. This could cause worse routes and
consequently additional communication overhead.
R EFERENCES
Sensor Node
Border Node
Sink
[1] K.W. Fan, Z. Zheng, and P. Sinha. Steady and fair rate allocation for
rechargeable sensors in perpetual sensor networks. In Proceedings of
the 6th ACM conference on Embedded network sensor systems, pages
239–252. ACM, 2008. IV-B
[2] A. Kansal, J. Hsu, S. Zahedi, and M.B. Srivastava. Power management
in energy harvesting sensor networks. ACM Transactions on Embedded
Computing Systems (TECS), 6(4):32, 2007. I, II, III-A, III-B, IV-A
[3] E. Lattanzi, E. Regini, A. Acquaviva, and A. Bogliolo. Energetic
sustainability of routing algorithms for energy-harvesting wireless sensor
networks. Computer Communications, 30(14-15):2976–2986, 2007. IV-D,
1
[4] D. Niyato, E. Hossain, and A. Fallahi. Sleep and wakeup strategies in
solar-powered wireless sensor/mesh networks: Performance analysis and
optimization. IEEE Transactions on Mobile Computing, pages 221–236,
2007. III-C
[5] D. Petrovic, R.C. Shah, K. Ramchandran, and J. Rabaey. Data funneling:
routing with aggregation and compression for wireless sensor networks.
In Sensor Network Protocols and Applications, 2003. Proceedings of the
First IEEE. 2003 IEEE International Workshop on, pages 156–162. IEEE,
2003. IV-E, 2, 1
[6] W.K.G. Seah, Z.A. Eu, and H.P. Tan. Wireless sensor networks powered
by ambient energy harvesting (WSN-HEAP)-Survey and challenges. In
Wireless Communication, Vehicular Technology, Information Theory and
Aerospace & Electronic Systems Technology, 2009. Wireless VITAE 2009.
1st International Conference on, pages 1–5. IEEE, 2009. I
[7] C.M. Vigorito, D. Ganesan, and A.G. Barto. Adaptive control of
duty cycling in energy-harvesting wireless sensor networks. In Sensor,
Mesh and Ad Hoc Communications and Networks, 2007. SECON’07.
4th Annual IEEE Communications Society Conference on, pages 21–30.
IEEE, 2007. III-B
[8] K. Zeng, K. Ren, W. Lou, and P.J. Moran. Energy aware efficient
geographic routing in lossy wireless sensor networks with environmental
energy supply. Wireless Networks, 15(1):39–51, 2009. IV-C
Fig. 2. Comparison of routes calculated with MP, MF and R-MPRT. Dark
areas correspond to low harvesting opportunities, bright areas correspond to
high harvesting oppor. Adapted Source: [5]
harvesting opportunities 1 . Each node of a region sends its
information to the border node. Border nodes merge and
compress incoming messages.
The authors achieve compression rates of about 50% and
reason, that less collisions occur due to a lesser number of
messages. To avoid delays in field monitoring and to reduce
memory usage, messages should be sent early, if the initiating
sensor nodes have a high distance to the sink.
V. C ONCLUSION AND F UTURE W ORK
A. Conclusion
In this seminar work an overview on algorithms for optimizing the energy usage have been introduced, and algorithms
for solving sensor specific problems have been introduced.
For optimizing the energy usage for a single sensor node, a
scheduling method which makes use of future estimation, an
approach that uses control theory and estimates energy and
sensor specific parameters, and a probabilistic approach have
been introduced.
Furthermore, the rate adaption algorithms, routing algorithms and an algorithm for compressing data have been
demonstrated as further tasks for harvesting sensors.
B. Future Work
Harvesting Sensor networks are a quite new research topic.
Future research could focus for example on sensor positioning.
In battery powered sensor networks, deployed sensors, which
get out of battery energy will be replaced by new sensors. Yet,
improved positioning of harvesting sensors can be realized
1 In [5], the authors defined the algorithm for non-harvesting battery
powered sensor networks. Thus they proposed to use the node of a region,
which is closest to the sink, i.e. it has the minimum number of hops to the
sink
74
~
1
LOAD BALANCING IN PEER-TO-PEER NETZWERKEN SURVEY
Load Balancing in Peer-to-Peer Netzwerken
Survey
Johannes Thomas
II. L OOKUP O PTIMIERUNG UND C ACHING
Zusammenfassung—Load Balancing ist einer der größten Ansatzpunkte um Peer-to-Peer Netzwerke effektiver zu gestalten.
Jedoch gibt es verschiedene Arten von Peer-to-Peer Netzwerken.
Unter anderem kommt es auf die Zusammensetzung der Clients
an, welche von Handys bis zu Hochleistung-Rechnern variieren
können oder auf den Aufwand des Routings im jeweiligen Netz.
Auch die lokale Clusterung des Netzes sollte nicht ignoriert
werden. Ohne Lastverteilung kann es in einem Netzwerk zu Engpässen kommen, welche dessen Effektivität erheblich beeinflussen
kann.
Diese Survey stellt für verschiedene ausgewählte DHT
(D̈istributed Hash Table¨) Peer-to-Peer Netzwerke Lösungsansätze
vor. Außerdem werden hierbei Strukturen betrachtet, welchen
auf DHT aufbauen und teilweise benötigt werden um bestimmte
der folgenden Lösungen umzusetzen. Cachen beziehungsweise
Kopieren der gefragtesten Objekte ist bei den vorgestellten
Lösungen genauso entscheidend wie das Ausnutzen der lokalen
Clusterung des Netzen um Overhad zu vermeiden.
Nimmt man in einem strukturierten DHT-Netzwerk eine
Gleichverteilung von den gesuchten Objekten, jedoch mit einer
Zipf-Artige Anfragen-Verteilung, [3] an, gibt es hierzu Lösungsvorschläge, die eine signifikante Verbesserung bezüglich
Skalierbarkeit und Leistung ermöglichen. Auf diesen Ansatz
möchte ich hier etwas genauer eingehen [2]. Das Problem ist,
dass trotz der gleichverteilten Objekte einzelne Knoten eine
viel höhere Last haben, da das Interesse an den Objekten in
den meisten Fällen nicht gleich verteilt ist. Einzelne Objekte
werden zum Beispiel permanent von vielen verschiedenen
Knoten abgefragt, während andere im Extremfall nie abgefragt
werden. Der hier beschriebene Ansatz wird in zwei Unterpunkte aufgeteilt. Einmal eine Optimierung der Routings sowie dem
Cachen von Objekten.
Anzumerken ist, dass diese Optimierung nur die Lastverteilung
des Lookups und das Bereitstellen von Objekten betrifft.
I. E INFÜHRUNG
A. Routing
Unter den Peer-to-Peer Netzwerken gibt es verschiedene
Arten von Strukturierungen. Die Unstrukturierten zeichnen
sich dadurch aus, dass das Suchen von Objekten meistens
durch ein Fluten des Netzwerks umgesetzt wird, sowie dass
die einzelnen Clients sich nicht sicher sein können, welche
anderen Knoten noch im Netzwerk aktiv sind [1]. Es ist somit
nicht verwunderlich, dass es schwer ist in diesem Fall eine
Last-Verteilung vorzunehmen, da extrem viele Verbindungen
nötig wären, sodass sich die einzelnen Knoten über ihre Last
austauschen können und entscheiden wie diese umverteilt
werden können. In dieser Survey wird deshalb nur auf strukturierte Netzwerke eingegangen. Diese sind meistens durch ein
DHT-Protokoll strukturiert, welches effizientes Suchen über
das Netzwerk zulässt und grundlegende Möglichkeiten bietet
umgebungsabhänige Optimierungen durchzuführen. Trotzdem
sind die meisten Netzwerke in der Lage Beitritte und Austritte
von Clients aus dem Netzwerk zu verkraften ohne die Integrität zu verlieren. Dadurch eignen sich strukturierte Peer-toPeer Netzwerke besonders um durch Last-Verteilung optimiert
zu werden. In dieser Survey werden verschiedene Ansätze
ausgesucht und vorgestellt um eine bessere Last-Balancierung
in strukturierten DHT-Netzwerken zu erhalten. Diese werden
durch eine Einleitung, die wichtigsten Zwischenschritte sowie
der Auswertung der Ergebnisse zusammengefasst. Es wird
bewusst nicht tiefer auf die technischen Details eingegangen
um eine schnelle aber effektive Übersicht verschiedener Lösungsansätze zu gestalten. Die ausformulierten Algorithmen
sind in den jeweiligen Quellen zu finden sowie ausführliche
Beschreibungen.
Der Grundgedanke beim optimieren des Routings ist, dass
die Knoten, die unter einer erhöhten Last durch ihre oft abgefragten Objekten stehen, sich nicht auch noch um das Routing
kümmern müssen, da von diesem eine nicht unerhebliche Last
ausgeht. Anstatt Anfragen immer auf denselben Knoten zu
weiterzuleiten, werden die Anfragen auch auf die NachbarKnoten des Ziels verteilt. Hierzu sammeln die einzelnen Knoten Informationen zu den anderen Knoten in ihrer RoutingTabelle. Dies beinhaltet die Anzahl, der an sie weitergeleiteten
Anfragen. Außerdem hängen alle Knoten an ihre ausgehenden
oder weitergeleiteten Anfragen ihre eigene Last an. Es werden
somit keine zusätzlichen Nachrichten erstellt, sondern nur die
Vorhandenen um Informationen erweitert. Hiermit erhalten
alle Knoten eine ungenaue aber ausreichende Übersicht über
die Last der umliegenden Knoten. Bei jeder neuen erhaltenen
Anfrage werden die Routing-Tabellen mit der Last-Tabelle abgeglichen und stark belastete Knoten aus der Routing-Tabelle
entfernt. Dies stellt eine Mischung zur Routing-Optimierung
auf Basis von Last sowie der näheren Umgebung der Knoten
dar. Stark belastete Knoten werden nicht mehr zum Finden
von Objekten verwendet, sondern müssen sich nur noch um
das Verteilen der auf ihnen liegenden Objekte kümmern.
B. Caching
Durch die Routing-Optimierungen wird Last von den Knoten genommen, die viele Objekte halten. Oft jedoch reicht
dies nicht alleine aus, da ein Knoten nicht immer die ganze
Last eines kompletten Netzwerken tragen kann. Hier kommt
75
2~
Caching ins Spiel. Dazu zählt der Knoten die Anzahl der
Anfragen sowie welche der Objekte angefordert werden. Sobald ein festgelegter Grenzwert erreicht ist, werden die Werte
der einzelnen Objekte normalisiert. In diesem Fall heißt das,
durch den Grenzwert geteilt und auf einen Teil des letzten
Ergebnisses aufaddiert wird, wenn es sich nicht um das letzte
gecachte Element handelt. Falls der Knoten aktuell unter Last
steht, wird aus der Liste das Objekt mit dem höchsten Wert
genommen und eine Caching-Anfrage an den Knoten gestellt,
von dem die meisten Anfragen auf das Objekt gestellt oder
weitergeleitet wurden. Danach werden die Zähler zurückgesetzt. Dass Normalisieren dient dazu, dass auch neuere Objekte
eine Chance haben gecacht zu werden. Sonst könnte es passieren, dass ein Objekt welches über einen längeren Zeitraum
oft angefragt wurde über ein neues, jetzt sogar viel stärker,
aber kürzer, benötigtes Objekt dominiert . Es ist außerdem
zu überlegen, wieviele Objekte ein Knoten cachen darf, bevor
eine der Kopien verworfen werden muss. In diesem Fall wurde
der Wert drei genommen, da sich dieser in Experimenten als
gut erwiesen hat. Bei geringeren Werten kommt es sonst vor,
dass zwei ähnliche oft benötige Objekte abwechselnd gecacht
werden und somit zusätzliche Last entsteht.
Ein weiter Vorteil dieses Ansatzes ist, dass er ohne Änderungen im Aufbau des Netzwerkes zu implementieren ist. Es
ist nicht nötig, eine permanente Umverteilung der Objekte im
Netzwerk durchzuführen. Außerdem ist es nur während des
Cachings von Nöten zusätzliche Nachrichten zu verschicken,
was den Overhead des Algorithmus eindämmt.
entsteht kein weiterer Overhead, da man davon ausgehen kann,
dass die Hash-Funktionen allen Knoten bekannt sind. Somit
ist es einfach, die effektiv genutzte Zahl der Hash-Funktionen
dynamisch zu erhöhen. Diese sind durchnummeriert, sodass
dieselbe Nummer bei allen Knoten auf dieselbe Hashfunktion
verweist
Diese Optimierung betrifft nur das bereitstellen von Objekten.
A. Erstellen und Löschen von Kopien
Um dies umzusetzen, erzeugt ein Knoten, wenn die Last
einen bestimmten Grenzwert überschreitet, eine Kopie des
gefragtesten Objektes und hasht dieses mit einer weiteren
Hash-Funktion, welche durchnummeriert sind. Diese Nummer
wird auch an das Objekt angehängt, sodass erkennbar ist,
welche Hash-Funktion dafür genommen worden ist. Diese
Kopie wird dann auf eine der umliegenden Knoten verschoben.
Dadurch sollte sich die Last auf diesem Objekt halbieren, da
die andere Hälfte durch die Kopie von dem anderen Knoten
übernommen wird. Sollte die Last für das Objekt weiterhin
zu groß sein, werden weitere Kopien in Umlauf gebracht
und der Zähler der Hash-Funktion weiter erhöht. Wenn die
Last der Knoten unter einen bestimmten Grenzwert fällt,
wird angefangen von den beliebtesten Objekten Kopien zu
löschen, die auf dem jeweiligen Server liegen. Somit muss
auch der Zähler der Hash-Funktion verringert werden. Dies
wird solange ausgeführt bis der Knoten über den Grenzwert
der geringen Last kommt oder keine Kopien mehr auf ihm
liegen.
C. Ergebnis
B. Finden von Kopien
Die durchgeführten Experimente mit den beiden Techniken
zeigen, dass schon alleine die Routing-Optimierung die Last
der am stärksten ausgelasteten Knoten halbieren könnte. Durch
dass hinzunehmen des Cachings wird die Last der Knoten
so gut verteilt, dass alle Knoten von der Last her jetzt sehr
nahe beieinander liegen. In einem strukturierten Peer-To-Peer
Netzwerk mit gleich verteilten Objekten, stellt dieser Ansatz
somit eine sehr gute Lösung dar, um die Last auf alle Knoten
zu verteilen. Neu hinzukommende oder verlassende Knoten
stellen für diesen Algorithmus kein Problem dar, auch wenn es
nicht explizit experimentell getestet worden ist. Hierzu müsste
des weiteren ein System implementiert werden, welches neue
Knoten effektiv in das Netzwerk eingliedert sowie das Verlassen von Knoten ausreichen bekannt gibt, sodass beliebte
Objekte direkt wieder gecacht werden können.
Damit auch die Kopien im Netzwerk gefunden werden
können, muss als erstes, dass ursprüngliche Objekt geladen
werden um die Aktuelle Hash-Nummer herauszufinden. Beim
nächsten Versuch auf dieses Objekt zuzugreifen, ist die Nummer bekannt und es wird eins der Objekte mit dem Hash,
der zufällig gewählt zwischen den ursprünglichen Objekt
und der aktuellen Hash-Nummer liegt, gewählt. Es wird nun
im Netzwerk nach diesem Objekt gesucht anstatt auf dass
Ursprungsobjekt zuzugreifen. Dadurch wird die Last ab dem
zweitem Zugriff gleichmäßig auf alle Knoten verteilt, die eine
Kopie des Objektes halten. Im Vergleich zu nur einem Knoten,
der das Objekt hält, kann somit ein starke Leistungssteigerung
erzielt werden. Es kann jedoch vorkommen, dass eine Anfrage
für ein Objekt kommt, welches durch das Löschen von Kopien
oder dem Austreten des Knotens, der die Kopie hielt, nicht
mehr existiert. In diesem Fall wird eine Anfrage an das
Ursprungsobjekt gestellt, welches dadurch auch wieder die
aktuelle Hash-Nummer liefert für zukünftige Anfragen.
III. KOPIEN
Das Konzept der Kopien bezieht sich auch darauf, dass die
meisten Peer-to-Peer Netzwerke einer Zipf-Artigen AnfragenVerteilung unterliegen [3]. Dadurch kann es passieren, dass
einzelne Knoten überladen werden und sich dadurch die Leistung des Netzwerkes verschlechtert bis hin zum Datenverlust.
Der Gedanke ist, durch weitere Hash-Funktionen Kopien des
gefragten Objektes anzufertigen und diese auf schwächer
belastete Knoten zu verteilen [4]. Der Vorteil von den HashFunktionen ist, dass es leicht ist, viele zu generieren und
bei allen Knoten des Netzwerkes bereitzuhalten. Hierdurch
C. Ergebnis
Durch dieses System können die Zugriffszeiten auf ein häufig angefragtes Objekt verringert werden. Jedoch funktioniert
diese Technik nur, wenn es um dasselbe Objekt geht, welches häufig angefordert wird. Änderungen an diesem können
nicht übernommen werden und es entsteht dadurch ein neues
Objekt, für das gegebenenfalls weitere Kopien angefertigt
76
~
3
werden müssen. Außerdem kann, wenn Knoten das Netzwerk
verlassene, dies zusätzliche Last auf den Ursprungsknoten
des Objekten hervorrufen. Somit ist diese Lösung nicht für
einen ständig wechselnden Datenbestand geeignet oder für
Netzwerke, bei denen auf Objekte nicht wiederholt zugegriffen
wird, da die erste Anfrage immer an den Ursprungsknoten geht
und ihn somit gleichstark belastet wie ohne Optimierung.
Verbesserungen zu dieser Überlegung die sich um die aufgezeigten Probleme kümmern stehen in Planung der Autoren.
solange durchgeführt, bis keine sinnvollen Paarungen mehr
möglich sind. Stehen jedoch noch Lastumverteilungen an, die
so nicht durchgeführt werden können, werden diese an die
Eltern-Knoten weitergegeben und von diesen weiterverwendet.
Dies geht bis zum Wurzel-Knoten weiter. Dieser jedoch muss
sich nicht an einen Grenzwert halten um Lastverteilungen
durchzuführen.
C. Umgebungsbewusste Lastverteilung
Damit durch die Lastverteilungsreihenfolge, welche bei den
Blättern des Baumes beginnt auch der physikalischen Umgebung entspricht, müssen die Abstände der Knoten erkannt und
in den Baum eingepflegt sein. Um die Abstände zu erkennen
eignet sich ein Landmarken-System. Hierbei werden im Netzwerk eine Anzahl Landmarken verteilt welche als Fix-Punkte
genutzt werden. Jeder Knoten stellt die Abstände zu ihnen fest
und speichert diese. Diese Informationen sind jedoch Mehrdimensionales Datensätze, da für jede Landmarke ein Wert
gespeichert werden muss. Da diese sehr umständlich in einem
Netzwerk zu nutzen sind, wird das Array auf die Hilbert-Kurve
abgebildet. Durch diese wird aus den MehrdimensionalenDatensätzen ein einzelner Wert welches jedoch die Abstandsinformationen der einzelnen Knoten weiterhin behält. Durch
diese Vereinfachung ist es leichter die Umgebungsinformationen auf den DHT-Adressraum abzubilden und somit den
K-Nary-Baum Umgebungsbewusst zu gestalten. Es ist also
nach der Strukturierung davon auszugehen, Eltern und Kinder
eines Knoten möglichst nahe beieinander liegen. Bei der LastVerteilung werden diese somit als erstes beachtet und ein
Großteil der Umverteilung kann so in der näheren Umgebung
durchgeführt werden.
IV. K-NARY-BAUM
Bei Peer-to-Peer Netzwerken kommt es nicht nur auf die
Verteilung der Objekte an, um die Last effektiv zu verteilen, sondern auch auf die Struktur der Netzes selbst. Es
gibt verschiedene Knoten mit unterschiedlichen Kapazitäten
und unterschiedlichen Entfernungen bezüglich Latenzzeiten
zueinander. Daher muss es nicht immer sinnvoll sein, die
Last auf den am wenigsten belasteten Knote zu verschieben,
da dieser extrem weit entfernt sein kann und dadurch viel
Overhead entsteht. Diese Punkte werden in dem folgenden
Ansatz beachtet [7]. Es wird davon ausgegangen, dass die
virtuellen Knoten eines DHT-Netzwerkes in einem K-Nary
Baum strukturiert werden. Ein K-Nary Baum ist ein Baum,
bei dem jeder Knoten maximal N Blätter haben darf. Zum
Beispiel erhält mein bei einem N von 2 einen Binärbaum.
Außerdem wird davon ausgegangen, dass ein reeller Knoten
im Netzwerk mehrere virtuelle Knoten enthält. Hierbei werden
virtuelle Maschinen genutzt, welche die Last auf einem Server
darstellen. Dadurch kann es sich um eine beliebige Ressource
handeln, welche zur Verfügung gestellt wird. Es ist also nicht
auf Objekte beschränkt. Als Beispiel kann es sich auch um
Dienste wie Rechenleistung handeln. Hiermit kann die Last
im Netzwerk mit Hilfe der Einheit eines Virtuellen Servers
verteilt werden.
D. Ergebnis
Um diesen Ansatz experimentell zu testen wurden 4096
Knoten erstellt, welche unterschiedliche maximale Kapazitäten
ausweisen. Allen Knoten wurden 5 virtuelle Server zugewiesen und danach der Lasterverteilungalgorithmus gestartet.
Als Ergebnis ergab sich, dass alle Knoten prozentual gesehen gleich ausgelastet wurden. Dies zeigt, dass die Last
auf alle Knoten gleichmäßig verteilt wurde und somit eine
sehr effektive Lösung gefunden wurde die Last verteilen
kann. Des Weiteren wurde der Lasttransfer beobachtet. Ohne
umgebungsbewusste Last-Verteilung wurde der Großteil der
virtuellen Server über mehr als 7 physikalische Hops geleitet.
Mit der umgebungsbewussten Last-Verteilung jedoch lies sich
der Großteil der Last in unter 3 Hops balancieren. Durch diese
Lösung kann die Last somit auch auf Geräte mit unterschiedlichen Kapazitäten gut verteilt werden und dabei der Overhead
effektiv verringert wird, um das Netzwerk nicht unnötig zu
belasten. Ein Problem dieses Ansatzes ist der Aufwand, der
entsteht, wenn Knoten das Netzwerk betreten oder verlassen.
Durch solche Aktionen ist es möglich, dass Teile des Netzwerkes getrennt sind, bis der Baum neu strukturiert wurde. In
dieser Zeit ist eine Lastverteilung unter den Knoten in den getrennten Bereichen nicht mehr möglich. Vor jedem Durchlauf
der Lastverteilung muss deshalb sichergestellt werden, dass
die Integrität des k-Nary-Baums noch gegeben ist. In großen
A. Load Balancing Informationen
Regelmäßig fragen die virtuellen Server den reellen Server
nach den Last-Informationen. Des weiteren wählt der reelle
Server einen zufälligen virtuellen Knoten von sich aus, welcher die Last-Informationen in der Baumstruktur weiter gibt
um Redundanz zu vermeiden. Die Reellen-Blatt-Knoten des
Netzwerkes geben diese Informationen über ihre Eltern weiter,
bis auch der Wurzel-Knoten sie erhält. Danach verteilt der
Wurzel-Knoten die Last-Informationen an seine Kinder, bis
alle Knoten im Netzwerk die Lastverteilung erhalten haben.
Dadurch kann für alle Knoten definiert werden, ob diese leicht,
stark oder neutral belastet sind.
B. Virtuelle Server Zuweisung
Die stark belasteten Blatt-Knoten berechnen, welche Virtuellen Server sie abgeben müssten um wieder leicht belastet
zu sein. Währenddessen geben die leicht belasteten BlattKnoten weiter, dass sie Kapazitäten frei haben. Der ElternKnoten bekommt diese Informationen und sobald ein bestimmter Grenzwert überschritten ist, paart dieser die Knoten,
die die Last untereinander austauschen sollen. Dies wird
77
4~
Netzwerken mit vielen Client-Fluktuationen ist dieser Ansatz
daher nur bedingt geeignet.
C. Umgebungsbewusste Lastverteilung
Falls es nicht ausreicht die Last intern zu verteilen, wendet der Superknoten sich an die restlichen Superknoten im
Netzwerk um eine Lastverteilung durchzuführen. Hierzu wird
als erstes bei seinen Nachbarn angefragt, ob Kapazitäten zur
Lastaufnahme zur Verfügung stehen. Diese sind im Normalfall
auch physikalisch näher am Knoten was kürzere Transportwege mit sich zieht und somit Ressourcen spart. Sollte es
dazu kommen, dass der Knoten immer noch eine zu große
Last besitzt, wendet er sich an alle Superknoten. Dies wird
durch zufällig Anfragen umgesetzt. Um die Knoten umgebungsbewusster zu ordnen werden wie im vorherigen Beispiel
Landmarken verwendet, welche durch die Hilbert-Funktion
abgebildet werden und somit eine einfache Methode genutzt
wird um das Umgebungsbewusstsein zu generieren.
V. C YCLOID
Ein weiteres großes Problem von Peer-to-Peer Netzwerken
ist der Overhead der durch das Betreten und Verlassen von
Clients in das Netzwerk auftritt. Dieser ist kaum zu vermeiden
und zwingt verschiedene Strukturen von Netzwerken zur kompletten Neustrukturierung. Hierfür werden viele Ressourcen
aufgewendet welche durch eine Struktur, die darauf nicht
angewiesen ist, anderweitig genutzt werden könnte. Jedoch ist
dies meistens ein Tausch gegen längere Suchanfragen oder
größere Last im Netzwerk. Hierzu existiert ein Algorithmus
und eine Netzwerkstruktur, welche diese Probleme angehen
[5].
In diesem Fall geht es um die Verteilung von Objekten, also
nur um Speicher oder Bandbreite.
D. Ergebnis
In verschiedenen Experimenten hat sich ergeben, dass in
einem Netzwerk mit wenig Overhead, durch betretende und
verlassende Knoten, dieser Algorithmus vergleichbare Ergebnisse wie zum Beispiel der K-Nary-Baum erzielt. Ansätze,
die eine komplett zufällige Suche zur Lastverteilung nutzen
ist dieser Ansatz weit überlegen. In Netzwerken mit starker
Client-Fluktuation zeigt er seine Stärken, da Lastverteilung
durchgängig möglich bleibt, auch wenn einzelne Knoten im
jeweiligen Ring ausfallen. Es zeigt sich, dass nach dem Balancieren alle Knoten unter ihrer maximalen Kapazität liegen und
es somit keine überladenen Knoten mehr gibt. Es wurde weiterhin getestet, wieviele gleichzeitige Suchanfragen gestartet
werden sollen um einen optimalen Partner zum Lastausgleich
zu finden. Hier hat sich der Wert 2 als effektiv erwiesen, da
es einen verbesserten Ausgleich gegenüber geringeren Werten
bietet, jedoch nur geringfügig erhöhe Kosten hat.
Es ist auch möglich diese Art von Algorithmus auf andere
Netzwerke auszuweiten, jedoch muss dabei beachtet werden,
dass diese lokale Clusterung erlauben, da sonst das Umgebungsbewusstsein nicht genutzt werden kann und dieser
Ansatz einen Großteil seinen Potentials nicht nutzen kann.
A. Netzwerkaufbau
Für diese Lastverteilung wird ein Cycloid [6] Netzwerk
verwendet. Diese Art von Netzwerk hat die Besonderheit auch
bei größeren Verlusten von Clients immer noch genügend
Verbindungen unterhalten zu können um das Netzwerk aktionsfähig zu halten. Damit ist dieses Netzwerk Churn-Resistent
Dies wird unter anderem dadurch umgesetzt, dass sich Knoten
in Ringen anordnet werden und untereinander Verbindungen
aufbauen. In jedem dieser Ringen wird ein Haupt-Knoten
gewählt, welcher den Ring nach außen hin vertritt.
B. Last-Verteilung
Die Hauptknoten werden als Superknoten in dem Netzwerk
angesehen. Es wird des Weiteren darauf geachtet, dass
die Super-Knoten auch die leistungsstärksten Knoten im
jeweiligen Ring sind. Damit stellen sie eine Mischung
aus einem effizienten zentralisierten Netzwerk und einem
dezentralisierten dar. Jeder Super-Knoten führt zwei Listen,
eine mit den starken und eine mit den leicht belasteten
Knoten. Diese Listen sind sortiert, sodass die am stärksten
beziehungsweise am schwächsten belasteten Knoten die
höchste Priorität in der Liste haben. Der Superknoten
vermittelt die normalen Knoten in seinem Ring welche Last
untereinander austauschen sollen. Eine Besonderheit ist, dass
die Knoten nicht eine gleichzeitige Anfrage senden können
sondern mehrere. Zu der Auswertung, wieviele gleichzeitige
Suchen gestartet werden sollten später mehr.
Anstatt virtuelle Server zu verschieben werden in diesem Fall
nur die Objekte selbst verschoben. Dadurch wird zusätzliche
Last vermieden. Wenn ein Objekt verschoben wird, bleibt
auf dem usprünglichen Besitzer eine Referenz auf den
neuen zurück. Somit können Routing-Anfragen weiterhin
beantwortet werden, ohne das Routing an sich zu verändern.
Der Knoten der das verschobene Objekt hält, besitzt weiterhin
eine Referenz auf den ursprünglichen Besitzer. Dies ist nötig,
denn falls das Objekt durch spätere Last-Verteilung weiter
verschoben werden muss, muss der ursprüngliche Besitzer
informiert werden kann, wo das Objekt aktuell lagert.
VI. FAZIT
Es wurden verschiedene Ideen und Algorithmen gezeigt um
Last-Verteilung in Peer-to-Peer Netzwerken durchführen und
verbessern zu können. Alle ermöglichen es, Last von Objekten
die Speicher oder Bandbreite verbrauchen zu balancieren.
Nur der K-Nary-Baum jedoch funktioniert explizit auch mit
anderen Ressourcen wie CPU, da sie mit virtuellen Servern
arbeitet. Die ist bei den anderen Algorithmen nur bedingt
möglich, da es zum Beispiel nicht sinnvoll ist, eine virtuelle
Maschine zu cachen.
Die Lösungen mit Kopien sowie Lookup Optimierung und
Caching setzen auf das Cachen der Objekte, welche in dem
jeweiligen Netzwerk stark nachgefragt sind. Beim Caching
ergibt sich sogar die Möglichkeit vorausplanend zu arbeiten, sodass Clients ihr gewünschtes Objekt erhalten, ohne
je mit dem ursprünglichen Knoten, welches das Objekt zur
Verfügung stellt, in Kontakt zu treten. Jedoch ist der Cache
der einzelnen Knoten begrenzt. Es ist möglich, dass von
78
~
5
mehreren Objekten Kopien angefertigt werden und auf dem
selben Knoten gespeichert sind. Dies wird sich jedoch je nach
Implementierung im letztendlichen System anpassen lassen.
Die Lösungen Cycloid und K-Nary-Baum beinhalten die Erfassung der lokalen Gegebenheiten durch Landmarken. Dies
sorgt dafür, das Last bevorzugt unter nahe beieinanderliegenden Knoten ausgetauscht wird und somit dass Netzwerk
weitaus weniger belastet als bei zufällig ausgewählten Knoten
zum Lastaustausch. Dies stellt besonders für Netzwerke mit
sehr unterschiedlichen Entfernungen der Knoten eine größere
Rolle. Bei Netzwerken denen eine sehr hohe Bandbreite zur
Verfügung steht ist dies demnach weniger wichtig, da Umgebungsbewusstsein nur den Bandbreitenverbrauch optimiert,
nicht aber CPU oder Speicher.
Im Gesamten gibt es somit einige interessante Ansätze um
Last-Verteilung in Peer-to-Peer Netzwerken effektiver zu gestalten. Die perfekte Lösung für alle Arten von Strukturen und
Clients lässt jedoch noch auf sich warten. Vielleicht könnte
man aus der Kombination der hier vorgestellten Ansätze eine
bessere Lösung bilden, besonders aus der Mischung von
Umgebungsbewusstsein und Caching gibt es noch einigen
Spielraum für Optimierungen.
L ITERATUR
[1] Wikipedia: Peer-to-peer unstructured systems http://en.wikipedia.org/
wiki/Peer-to-peer#Unstructured_systems, December 2010. I
[2] S. Bianchi, S. Serbu, P. Felber, and P. Kropf. Adaptive load balancing for
dht lookups. In Computer Communications and Networks, 2006. ICCCN
2006. Proceedings.15th International Conference on, pages 411 –418,
2006. II
[3] Lee Breslau Pei Cao. Web caching and zipf-like distributions: Evidence
and implications. In In INFOCOM, pages 126–134, 1999. II, III
[4] Yuqi Mu, Cuibo Yu, Tao Ma, Chunhong Zhang, Wei Zheng, and Xiaohua
Zhang. Dynamic load balancing with multiple hash functions in structured
p2p systems. In Wireless Communications, Networking and Mobile
Computing, 2009. WiCom ’09. 5th International Conference on, pages
1 –4, 2009. III
[5] H. Shen and C.-Z. Xu. Locality-aware and churn-resilient load-balancing
algorithms in structured peer-to-peer networks. Parallel and Distributed
Systems, IEEE Transactions on, 18(6):849 –862, 2007. V
[6] Haiying Shen, Cheng-Zhong Xu, and Guihai Chen. Cycloid: A constantdegree and lookup-efficient p2p overlay network. Performance Evaluation, 63(3):195 – 216, 2006. P2P Computing Systems. V-A
[7] Y. Zhu and Y. Hu. Towards efficient load balancing in structured
p2p systems. In Parallel and Distributed Processing Symposium, 2004.
Proceedings. 18th International, page 20, 2004. IV
79
~
1
DIASPORA UND SAFEBOOK: DER STAND VON DECENTRALIZED ONLINE SOCIAL NETWORKS
Diaspora und Safebook: Der Stand von
Decentralized Online Social Networks
Samuel Vogel
kein Interesse an der Durchsetzung starker Datenschutzregeln.
Andererseits haben auch Dritte immer größeres Interesse an
dem „Datenschatz“, der sich in OSNs sammelt. Immer wieder
werden Sicherheitslücken aufgedeckt oder gezielte Angriffe
auf OSNs ausgeführt, bei denen die Anbieter oft nicht gerade
durch zuverlässige Abwehrmechanismen auffallen [19] [23].
Hier setzen Decentralized Online Social Networks (DOSNs)
an. Der Nutzer muss die Kontrolle über seine Daten nicht mehr
an Dritte abtreten, denn er selbst verwaltet sie und nimmt die
Durchsetzung seiner Datenschutzregeln in die eigene Hand.
Die Kommunikation unter den Nutzern läuft je nach Netzwerk
im wesentlichen über mehr oder weniger ausgeprägte P2P
Netze ohne zentrale Kontrollstrukturen. So gut dieser Ansatz
jedoch im Bezug auf Datenschutz ist, desto mehr Probleme
haben derzeitige Umsetzungen mit Verfügbarkeit und Benutzbarkeit.
In dieser Ausarbeitung werden mit Diaspora und Safebook
zwei verschiedene Entwürfe eines DOSNs vergleichend gegenübergestellt und deren Probleme aufgezeigt. Abschließend
wird ein Fazit gezogen und ein Ausblick auf zukünftige
Entwicklungen gewagt.
Zusammenfassung—Immer mehr Menschen nehmen an sogenannten Online Social Networks teil und geben dabei in
immer größerem Umfang persönliche Daten frei. Der sichere und
vertrauensvolle Umgang mit den Daten, welche die Nutzer preisgeben, liegt dabei meist in den Händen der Unternehmen, welche
diese Netzwerke betreiben. Wie Sicherheits- und DatenschutzProbleme zuletzt wiederholt gezeigt haben, kann hierauf jedoch
nicht immer Verlass sein. Das Konzept der Decentralized Online
Social Networks versucht diese Probleme zu umgehen indem jeder Nutzer seine Daten selbst bereitstellt, statt sie einer zentralen
Stelle anvertrauen zu müssen. Dieses Paper stellt mit Diaspora
und Safebook zwei Decentralized Online Social Networks vor
und zeigt auf, dass in diesem Bereich noch weitere Forschung
nötig ist, um alle Herausforderungen zufriedenstellend lösen zu
können.
I. E INLEITUNG
Online Social Networks (OSNs) wie facebook, StudiVZ oder
orkut sind zu den wichtigsten Services im World Wide Web
geworden [8]. In OSNs können selbst technisch unbedarfte
Nutzer ein persönliches Profil anlegen, miteinander in Kontakt
treten und Informationen veröffentlichen.
Genauer definiert werden Online Social Network Services
oder Social Network Sites von boyd und Ellison [7] als:
web-based services that allow individuals to (1)
construct a public or semi-public profile within a
bounded system, (2) articulate a list of other users
with whom they share a connection, and (3) view and
traverse their list of connections and those made by
others within the system.
In dieser Definition wird jedoch ein wesentlicher Bestandteil
heutiger OSNs vernachlässigt: Das direkte (beispielsweise
durch persönliche Nachrichten oder Chats) und indirekte (über
Kommentare und Empfehlungen) Austauschen von Nachrichten. Des Weiteren entwickeln sich große OSNs wie facebook
immer mehr zum Ausgangspunkt für die Nutzung des World
Wide Web (unter anderem als Startseite) und ziehen damit
mittlerweile auch an Suchmaschinen wie Google oder die
früheren Webverzeichnise wie Yahoo! vorbei [14].
Bedingt durch deren große Popularität und die stetig wachsenden Mitgliederzahlen [9] sammeln OSNs also einen riesigen Bestand an persönlichen Daten an. Kontrolliert wird dieser
Datenbestand meist von kommerziellen Unternehmen, welche
alle Daten zentral verwalten. Der vertrauensvolle Umgang und
der Schutz der Daten obliegt somit allein diesen Firmen.
Dies stellt aus mehreren Gründen ein Problem dar: Da
die meisten dieser Dienste für den Nutzer kostenlos sind,
müssen aus den Daten der Nutzer Einnahmen generiert werden, um sich finanzieren zu können. Die Unternehmen haben
II. DOSN S : A NSÄTZE & P ROBLEME
Ein optimales Online Social Network sollte Verletzungen
der Privatsphäre durch Angreifer, bösartige Nutzer und OSNBetreiber verhindern und dabei gleichwohl Integrität, Authentizität und Verfügbarkeit der Daten bei gewohnter Benutzerfreundlichkeit und gewohnten Kosten gewährleisten.
Es lassen sich also fünf Ziele für Decentralized Online
Social Networks identifizieren:
• Datenschutz
Der Schutz der personenbezogenen Daten stellte das Ziel
des Datenschutzes dar [6].
• Vertraulichkeit, Integrität & Authentizität
Die Vertraulichkeit von Daten ist sichergestellt, wenn
kein unautorisierter Datenzugriff stattfinden kann [6].
Die Integrität ist gewährleistet, wenn es nicht möglich
ist, Daten unautorisiert und unbemerkt einzuspielen, zu
manipulieren oder zu löschen [6]. Die Überprüfung der
Identität mittels charakteristischer Eigenschaften erlaubt
es, die Authentizität, d.h. die Echtheit und Glaubwürdigkeit eines Objekts, festzustellen [6].
• Verfügbarkeit
Eine optimale Verfügbarkeit ist gewährleistet, wenn alle
Daten jederzeit abrufbar sind.
• Usability
• Kosten
80
2~
Im Folgenden wird nun aufgezeigt wie OSNs versuchen
diese Ziele zu erreichen und wie sich die Ansätze in DOSNs
davon unterscheiden.
Datenschutz: OSNs bieten im Allgemeinen die Option,
die eigenen Privatsphäre-Einstellungen anzupassen. So besteht meist die Möglichkeit, die Sichtbarkeit eigener Profilinformationen und Nachrichten einzuschränken und sie beispielsweise nur für bestätigte Freunde zugänglich zu machen.
Diese Einstellungen sind jedoch häufig für den Nutzer nur
schwer zu verstehen, so dass nur selten davon Gebrauch
gemacht wird [10]. Des Weiteren werden Nutzer über die
Datenschutz-technischen Implikationen ihrer Handlungen, wie
eine Freundschaftseinladung zu akzeptieren oder eine sogenannte App zu nutzen, oft nur unzureichend aufgeklärt.
Jegliche Privatsphäre-Einstellungen können jedoch nicht vor
Angriffen auf den OSN-Anbieter oder Aktionen des OSNBetreibers selbst schützen. Da meist alle persönlichen Daten
der Mitglieder eines OSNs zentral beim Betreiber verwaltet
werden, ist dieser auch für die Durchsetzung der PrivatsphäreEinstellungen und des Datenschutzes verantwortlich.
DOSNs umgehen diese Probleme durch die Abschaffung
eines zentralen Anbieters. An dessen Stelle tritt die persönliche
Bereitstellung der Daten durch die einzelnen Nutzer. Es wird
so möglich, dass nicht Dritte, sondern die Nutzer selbst, ihre
Privatsphäre durchsetzen und den Datenschutz kontrollieren.
Vertraulichkeit, Integrität & Authentizität: OSNs versuchen, Vertraulichkeit zu gewährleisten, indem sie nach Möglichkeit Angriffe auf ihre Dienste zu verhindern. Es ist jedoch
bekannt, dass sie dabei nicht immer erfolgreich sind [19]
[23]. Authentizität der Nutzer kann aufgrund der schweren
praktischen Umsetzbarkeit von den meisten OSNs nicht gewährleistet werden.
DOSNs hingegen setzen meist auf die durchgängige Endezu-Ende-Verschlüsselung aller Kommunikation, um die durchgängige Vertraulichkeit der Daten sicherstellen zu können.
Authentizität wird jedoch auch von vielen DOSNs nicht garantiert.
Verfügbarkeit: OSNs sind durch die meist zentrale Verwaltung aller Daten bei einem einzelnen Anbieter naturgemäß
weniger von Verfügbarkeits-Problemen betroffen. Meist handelt es sich um technische Defekte, die in der Regel schnell
behoben werden können.
Bei DOSNs stellt die durchgängige Verfügbarkeit prinzipbedingt ein sehr viel größeres Problem dar. Die meisten Nutzer
sind nicht dauerhaft online, und wenn die Nutzer sich gegenseitig ihre eigenen Daten bereitstellen, verschwinden diese
aus dem Netzwerk sobald alle Knoten die eine bestimmten
Datensatz bereitstellen das Netz verlassen.
Usability: Das Thema Benutzerfreundlichkeit ist in OSNs
sowie DOSNs ähnlich aufgehängt. Einfacher Zugang und eine
gute UI sind sowohl für OSNs als auch DOSNs wichtige
Anforderung. OSNs laufen heutzutage meist im Browser ab,
so ist beim Nutzer im Grunde genommen kein Installationsaufwand erforderlich. DOSNs haben jedoch durch die verteilte
Natur, als damit meist einhergehendes Problem, die Frage der
Software-Installation zu lösen.
Kosten: OSNs werden meist von kommerziellen Organisationen betrieben. Zum Geschäftsmodell gehört es in der
Regel (Ausnahme z.B. teilweise XING), dass die Nutzung
des Netzwerkes kostenlos ist. Darin inbegriffen ist auch das
durchgängige Bereitstellen der Daten auf Servern des Unternehmens. Wie das nötige Kapital dafür beschafft wird ist nicht
Thema dieser Ausarbeitung.
In DOSNs ist die Frage nach den Kosten anders gelagert.
Jeder Nutzer betreibt seinen eigenen „Server“ und muss sich
so auch um die damit anfallenden Kosten kümmern.
Ein weiteres wichtiges Thema sind die sogenannten „Apps“,
meist kleine Programme oder oft auch Spiele welche häufig
neue Interaktionsarten mit anderen Nutzern in OSNs integrieren. In OSNs stellen Apps mittlerweile oftmals Sicherheitsprobleme dar [21], so dass hier besondere Vorsicht bei der
Konzeption der „App“-Integration geboten ist.
Nun soll betrachtet werden, wie die DOSNs Diaspora und
Safebook diese spezifischen Anforderungen im einzelnen umsetzen und welche Probleme es dabei noch gibt.
III. D IASPORA
Das Diaspora-Projekt wurde im Sommer 2010 von
vier New-Yorker Studenten gegründet. Auf der ProjektFinanzierungsplattform Kickstarter1 versuchten sie Startkapital
für ihr Vorhaben zu sammeln. Kickstarter ist vornehmlich dazu
gedacht, auch Projekten, welche von klassischen Risikokapitalgebern wahrscheinlich kein Kapital zur Verfügung gestellt
bekommen würden, das Einsammeln von Risikokapital zu
ermöglichen, indem viele kleinere Summen von Unterstützern
akkumuliert werden. Die Gründung von Diaspora fiel in eine
Zeit in der, durch wiederholte Sicherheitslücken und laxen
Umgang mit der Privatsphäre, eine Welle von Unzufriedenheit
mit den großen OSNs wie facebook durch das Internet rollte.
[15] So fiel es den vier Studenten leicht, das ursprüngliche
Ziel von 10.000 $ auf Kickstarter mit einem erreichten Betrag
von über 200.000 $ bei weitem zu übertreffen.
Die Gründer publizierten mehrere Videos [17] [18] und
Blog-Posts2 in dem sie ihr Vorhaben beschrieben. Es wurde
geplant, das Projekt nach einer anfänglichen geschlossenen
Entwicklungsphase als Open-Source zu veröffentlichen und so
das Mitwirken Dritter zu ermöglichen.
Die Entwicklung von Diaspora schien von Anfang an eher
sichtbare Entwicklungsfortschritte als ein sauberes Konzept in
den Vordergrund zu stellen. Zum Projekt Start wurde zunächst
kein grundlegendes Konzept erstellt und veröffentlicht, die
einzigen greifbaren Informationen blieben die erwähnten Videos und Blog-Posts. Bist heute gibt es kaum wissenschaftlich
erarbeitete Untersuchungen oder Papers über das DiasporaProjekt, weshalb sich auch diese Ausarbeitung im Hinblick auf
Diaspora zum Großteil auf Nachrichtenmagazine, Blogs und
die vom Diaspora-Team selbst veröffentlichen Informationen
beziehen muss.
Bei Diaspora handelt sich um ein verteiltes System, welches
jedoch ohne Replikation der Daten auskommen muss. Man
kann daher nicht von einem klassischen P2P Netz sprechen.
Aufgebaut wird das Netz aus sogenannten Seeds oder auch
1 http://www.kickstarter.com/projects/196017994/
diaspora-the-personally-controlled-do-it-all-distr
2 http://blog.joindiaspora.com/
81
~
3
Pods. Als solche werden die Knoten des Netzes bezeichnet,
welche die Daten von einem oder mehreren Nutzern im
Netz bereitstellen. Für diese Seeds wird vorausgesetzt, dass
sie durchgängig mit dem Netz verbunden sind. Durch diese
Anforderung wird zwar die ständige Availability aller User
im Netzwerk zwar konzeptbedingt garantiert, jedoch geht dies
mit einer extremen Einschränkung der Usability einher. Sobald
der Server offline ist, stehen alle Nutzer die auf diesem Server
verwaltet wurden nicht mehr im Netzwerk zur Verfügung. Nur
die wenigsten Nutzer besitzen einen Rechner beziehungsweise
Server, welcher 24 Stunden am Tag online ist, geschweige das
für den Betrieb nötige technische Wissen, noch sind sie bereit,
die Kosten und den damit einhergehenden Aufwand zu tragen.
Als Alternative zu dieser nicht realistisch umsetzbaren Anforderung wird den Nutzern empfohlen, sich einen Platz auf
einem von einer dritten Partei betriebenen, Diaspora Server zu
mieten. Dieser Ansatz löst zwar die Probleme die des ServerBetriebs, klärt jedoch nicht die Frage der dabei anfallenden
Kosten. Des Weiteren tritt hierbei ein ganz neues konzeptionelles Problem auf: Die Hoheit über die eigenen persönlichen
Daten wird, wie bei einem klassischen OSNs, wiederum an
Dritte abgetreten. Hierdurch würde also eines der wichtigsten
Ziele die ein DOSN erreichen sollte gebrochen, denn die
dritte Partei ist im Grund vergleichbar mit dem Betreiber
bei einem klassischen OSN und bringt somit auch die damit
einhergehenden Probleme wie den möglichen Missbrauch der
persönlichen Daten mit sich.
Jedes Profil kann durch eine eindeutige Adresse identifiziert werden. Diese ist, analog zu einer E-Mail Adresse, aus Nutzernamen und Host aufgebaut (e.g. nutzername@joindiaspora.com). So kann jedes Profil einem Server
zugeordnet werden, auf welchem es bereitgestellt wird. Eine
Struktur, wie ein DHT3 , um die Server untereinander bekannt
zu machen existiert nicht. Zur Auflösung der Adressen verlässt
man sich rein auf das DNS4 [12].
Die für OSNs typische Suche nach anderen Mitgliedern
im Netzwerk gibt es auf Grund dessen in dieser Art und
Weise bei Diaspora nicht. Es gibt hierdurch keine Möglichkeit
Nutzer, welche sich nicht auf dem gleichen Server befinden,
aufzuspüren. Die Adresse des Diaspora Profils muss daher
bekannt sein bzw. über andere Kanäle verbreitet werden um
sich mit weiteren Nutzern verbinden zu können, was wiederum
mit einer Einschränkung der Usability einhergeht.
Es gibt jedoch Bestrebungen Strukturen zur verteilten Kommunikation unter den Knoten einzuführen um somit auch eine
Suchfunktionalität gewährleisten zu können [22] [16].
Die Authentizität der Profile wird bei Diaspora nicht gewährleistet, da die Daten zur Person bei der Anmeldung wie
bei den meisten OSNs nicht geprüft werden. Nutzer können
sich also jederzeit durch falsche Angaben im Profil als eine
andere Personen ausgeben.
Nach derzeitigen Stand ist eine API, um beispielsweise
alternative Clients zu ermöglichen, vorgesehen aber nicht noch
nicht umgesetzt5 . Ebenso ist über Pläne Drittanbieter „Apps“
in Diaspora zu ermöglichen ist nichts bekannt.
Abbildung 1: Matrjoschka-Netz in Safebook [4]
Aufgrund des Projektablaufes mit einer anfänglichen Entwicklungsphase hinter geschlossenen Türen war es Dritten
nicht möglich, das technische Design zu überprüfen bis der
Quellcode veröffentlicht wurde. Diese ersten Reviews von
Dritten förderten dann auch gleich viele Probleme zu Tage
[20] [13] [1]. Von zum Teil einfachen Programmierfehlern
über handfeste Sicherheitslücken durch unzureichend oder
nicht verschlüsselte Kommunikation bis hin zu grundlegenden
konzeptionellen Problemen wurden viele Fehler offengelegt.
Auch die Integration von weiteren Entwicklern in das Team
gestaltete sich schwierig [11]. Der Quellcode von Diaspora
wurde unter der unter der AGPL Lizenz6 veröffentlicht. Eine
sehr freie aber gleichzeitig auch sehr restriktive Lizenz, welche
beispielsweise kommerzielle Beiträge bedeutend erschwert.
Die Anforderung dem Diaspora-Team ein gemeinsames Eigentumsrecht an allen Codebeiträgen einzuräumen erschwert
das Mitwirken Dritter zusätzlich. Wiederholt zeigten sich auch
Schwierigkeiten innerhalb des Entwicklerteams, welche auch
zum dazu führten, dass Personen das Projekt verließen [2].
Derzeit befindet sich Diaspora in einer geschlossenen
Alpha-Phase. Diese startete Ende November 2010, einen festen
Release Plan gibt es nicht. Viele Features, wie zum Beispiel
der von anderen OSNs (insbesondere facebook) bekannte
„Like“-Button, fehlen jedoch noch,
Abschließend muss also gesagt werden, dass Diaspora als
schnelle Antwort auf die „Anti-Facebook“ Stimmung dieser
Tage nicht alle Implikationen der komplexen Konzeption eines
DOSNs zufriedenstellend lösen kann.
IV. S AFEBOOK
Safebook wurde am Institut Eurécom und der TU-Darmstadt
entwickelt und legt hohen Wert auf ein korrektes Design.
Alle Gesichtspunkte wurden zunächst theoretisch analysiert
und formalisiert, statt mit den ersten Codezeilen zu beginnen.
Dadurch gibt es unter sicherheitstechnischen Gesichtspunkten
keine konzeptbedingten Probleme. Vernachlässigt wurden dabei jedoch einige Aspekte, welche den Ansatz in der realen
Welt nur schwer umsetzbar machen.
Safebook arbeitet nach einem klassischen P2P-Schema mit
einer Replikation der Daten. Jeder Nutzer betreibt seinen
3 http://en.wikipedia.org/wiki/Distributed_hash_table
4 http://en.wikipedia.org/wiki/Domain_Name_System
5 API
6 http://www.gnu.org/licenses/agpl-3.0.html
Feature Request: http://bugs.joindiaspora.com/issues/311
82
4~
persönlichen Knoten und nimmt so am Netzwerk teil. Um ihn
wird ein sogenanntes sogenanntes Matrjoschka-Netz (siehe 1)
gebildet, an dessen Innerem er steht (vgl. Core). Die erste
Stufe des Matrjoschkas stellen dann die eigenen Freunde
(vgl. Inner shell) dar, welche als vertrauenswürdig eingestuft
werden. Mit diesen werden dann die persönlichen Daten
geteilt um die Verfügbarkeit im Netzwerk zu erhöhen. Auch
indirekte Kommunikation, wie beispielsweise ein Kommentar
auf dem Profil des Nutzers, kann dann von dieser inneren Hülle
abgewickelt werden. Direkte Kommunikation, wie ein Chat,
bleibt jedoch dem Nutzer selbst vorbehalten und findet über
eine direkte Verbindung zwischen den Kontakten statt.
Safebook bedient sich somit der Vertrauensverbindungen
aus dem echten Leben des Nutzers. Jedoch sind ein Großteil
der Nutzer von OSNs bei weitem nicht durchgängig online.
Vor allem Nachts ist die Chance hoch, dass ein Nutzer und
auch sein kompletter Kreis von vertrauenswürdigen Freunden
offline ist, da es häufig der Fall ist, dass Freundeskreise aus
der selben Zeitzone kommen. Im Vergleich zu klassischen P2P
Netzen, beispielsweise zur Verbreitung von Dateien, gibt es
in Safebook sehr viele weniger bekannte Datensätze, nämlich
die einzelnen Nutzer Profile, statt nur vergleichsweise wenige,
dafür aber sehr beliebte Dateien. Es kann also trotz dieser
Maßnahme mit dieser Form der eingeschränkten Datenreplikation keine durchgängige Availability garantiert werden.
Die weiteren Hüllen (vgl. Intermediate shells) des Matrjoschkas dienen dem Schutz der Kontaktliste des Nutzers.
Ohne diese wäre es möglich die Kontaktliste eines Nutzers
zu rekonstruieren, indem man die Verbindung über das DHT
nachvollzieht welche eine Nachricht an den entsprechenden
Nutzer im Netzwerk nimmt. Bei dem letzten Hop würde
es sich dann immer um den entsprechenden Nutzer selbst
oder einen seiner Kontakte handeln. Die weiteren Hüllen
abstrahieren die Verbindung zu einem Nutzer dadurch, dass sie
Nachrichten an ihn weiterleiten, ohne dass die Hops zwischen
ihnen nachvollziehbar sind. Nur die äußere Hülle (vgl. Outer
shell) ist dann noch für Verbindungen von Außen mit dem
Nutzer zuständig.
Die Authentizität der Nutzer wird von Safebook wiederum in vollem Umfang gewährleistet. Auch hier jedoch gibt
es Schwierigkeiten bei der praktischen Umsetzung. Um die
Authentizität der Nutzer zu gewährleisten müssen sich diese
anfänglich gegenüber einer vertrauenswürdigen dritten Partei
ausweisen. Dieses System ist an die Mechanismen bei der
Vergabe von signierten SSL-Zertifikaten angelehnt. Es ist
zeitaufwendig, könnte Kosten mit sich bringen und erhöht
maßgeblich die Einstiegshürde am Netzwerk teilzunehmen.
Diese wird durch den Fakt weiter angehoben, dass neue
Nutzer sich dem Netzwerk nur anschließen können, indem sie
von einem Freund, welcher bereits am Netzwerk teilnimmt,
eingeladen werden.
„Apps“ sind im Konzept von Safebook nicht vorgesehen.
Außerdem existiert keine öffentlich zugängliche Implementierung von Safebook, es handelt sich um ein rein wissenschaftliche Konzept.
Safebook ist demnach zwar ein interessantes und aus
Sicherheits-Gesichtspunkten theoretisch makeloses Konzept,
wird jedoch von Unzulänglichkeiten in der praktischen Be-
nutzbarkeit geplagt.
V. A NDERE DOSN S
Es gibt noch einige weitere DOSNs, welche zum Teil schon
länger als Diaspora oder Safebook existieren. Drei davon
sollen nun hier kurz vorgestellt werden:
Appleseed: Ein DOSN welches bereits seit 2004 existiert
und als Open Source entwickelt wird, jedoch in dieser Zeit
nie den derzeitigen Bekanntheitsgrad von Diaspora erreichte.
Das Netzwerk hundertprozentig kostenlos anzubieten wird als
eines der Projektziele beschrieben, die Betriebskosten eines
Servers werden jedoch nicht in diese Rechnung mit einbezogen. Verlässt sich ebenfalls ständig verfügbare Server ohne
Datenreplikation. Als Alleinstellungsmerkmal gegenüber anderen DOSNs ist zum Beispiel die Unterstützung von „Apps“,
ähnlich denen bekannt von facebook, zu nennen.
Noserub: Ein DOSN welches durch starke Integration bereits existierender OSNs auffällt und damit die hohen Einstiegshürden andere DOSNs zu mindern versucht. Aufgrund
der Anbindung an andere OSNs stellt diese Netzwerk eine
Art Hybrid dar und gewährleistet die volle Kontrolle über die
eigenen Daten ausschließlich unter reinen Noserub Nutzern.
Die dezentrale Komponente scheint aber nicht primäres Ziel
des Projekts zu sein und verlässt sich, ähnlich wie Diaspora,
auf ständig verfügbare Server.
PeerSoN: Ein DOSN welches wie Safebook einen wissenschaftlichen Hintergrund hat. Es basiert ebenso auf einem
P2P Netz, setzt jedoch auf eine andere Strategie um die
Verfügbarkeit von Profilen zu gewährleisten. Profile werden
nicht nur mit Freunden geteilt, sondern zunächst mit einem
Public-Key-Verfahren verschlüsselt und dann im ganzen Netzwerk repliziert [3]. Nur Freunde eines Nutzers besitzen die
entsprechenden Schlüssel um mit dem Profil zu interagieren.
Hierdurch sollte die Verfügbarkeit wesentlich höher ausfallen.
VI. FAZIT UND AUSBLICK
Sowohl Diaspra und Safebook haben noch mit Problemen
zu kämpfen. Insbesondere kann keines der analysierten Netzwerke alle genannten Ziele für ein DOSN ohne maßgebliche Einschränkungen erreichen. Diaspora scheint aufgrund
der konzeptionellen Probleme nicht die Zukunft der DOSNs
darzustellen, leistete jedoch wichtige Öffentlichkeitsarbeit für
das Thema [5]. Safebook hingegen bietet interessante Ansätze
und kann im Bereich der Sicherheit überzeugen. Durch die
Schwierigkeiten in der Verfügbarkeit und die Einstiegshürden
wie die Authentizitätsprüfung, ist die praktische Benutzbarkeit
jedoch eingeschränkt. Man kann Safebook jedoch sicherlich
als Entwurf bezeichnen in welche weitere Arbeit investiert
werden sollte.
Bezüglich Verfügbarkeit könnte Safebook beispielsweise
Anleihen am Konzept von PeerSoN nehmen oder die ProfilReplizierung zumindest auf „Freundesfreunde“ ausweiten. Bei
der Überprüfung der Authentizität eines Nutzers, könnte man
ein an SSL angelehntes Stufenmodell wählen und zur eigentliche Verifikation, wie bei der Replikation, wiederum die
Freundschaftsbeziehungen nutzen. Nicht verifizierte Nutzer
83
würden so, wie Seiten mit ungültigen Zeritifikaten, als potenziell nicht vertrauenswürdig markieren. Nutzer welche von
mehreren Freunden als vertrauenswürdig deklariert wurden
oder den kompletten Verifizierungsprozess durchlaufen haben,
könnte man so ebenfalls entsprechend darstellen.
Daran ist zu erkennen, dass noch viele Ideen und Möglichkeiten gibt um DOSNs weiterzuentwickeln. Es muss weiterhin
Forschungsarbeit und Evaluation geleistet werden um DOSNs
entwickeln zu können welche alle erforderlichen Ziele abdecken.
~
5
[10] Ralph Gross and Alessandro Acquisti. Information revelation and
privacy in online social networks. In Proceedings of the 2005 ACM
workshop on Privacy in the electronic society, WPES ’05, pages 71–80,
New York, NY, USA, 2005. ACM. II
[11] Jarin Udom. Diaspora, or How to Kill Your „Facebook Killer“ Open
Source Project Before It Even Launches. http://jarinheit.posterous.com/
diaspora-or-how-to-kill-your-facebook-killer, 16. Sep. 2010. Visited:
20. Feb. 2011. III
[12] Jonne Hass. Re: Diaspora in mesh network. http://groups.google.
com/group/diaspora-dev/msg/cd997bead4a67b9d, 11. Feb. 2011. Visited: 19. Feb. 2011. III
[13] Mashable Dev & Design, Jolie O’Dell. Diaspora Releases Source Code, Developers Dissect It.
http://mashable.com/2010/09/16/
diaspora-source/, 16. Sep. 2010. Visited: 03. Jan. 2011. III
[14] Quit
Facebook
Day.
Facebook
zieht
an
Google
vorbei.
http://www.ftd.de/it-medien/medien-internet/:
us-nutzerranking-facebook-zieht-an-google-vorbei/50210274.html,
31. Dec. 2010. Visited: 18. Feb. 2011. I
[15] Quit Facebook Day.
QuitFacebookDay.com.
http://www.
quitfacebookday.com/, 31. May. 2010. Visited: 05. Jan. 2011. III
[16] Sam Whited.
Re: diaspora search.
http://groups.google.com/
group/diaspora-discuss/msg/b5bad56b35bb87ff, 16. Sep. 2010. Visited:
20. Feb. 2011. III
[17] Diaspora Team. Diaspora: Personally Controlled, Do-It-All, Distributed Open-Source Social Network. http://vimeo.com/11099292,
21. Apr. 2010. Visited: 03. Jan. 2011. III
[18] Diaspora Team. Other Cool Features of Diaspora. http://vimeo.com/
11111557, 21. Apr. 2010. Visited: 03. Jan. 2011. III
L ITERATUR
[1] Avery Morrow.
First Impressions of Diaspora Dev
Preview.
http://www.diaspora-news.net/2010/09/16/
first-impressions-of-diaspora-dev-preview/, 16. Sep. 2010.
Visited:
03. Jan. 2011. III
[2] Avery Morrow.
I’m Dropping Diaspora, This Site Is
Now
Closed.
http://www.diaspora-news.net/2010/11/29/
im-dropping-diaspora-this-site-is-now-closed/, 29. Nov. 2010. Visited:
08. Feb. 2011. III
[3] Sonja Buchegger, Doris Schiöberg, Le Hung Vu, and Anwitaman Datta.
Peerson: P2p social networking - early experiences and insights. In
Proceedings of the Second ACM Workshop on Social Network Systems
Social Network Systems 2009, co-located with Eurosys 2009, Nürnberg,
Germany, March 31, 2009. V
[4] Leucio Antonio Cutillo, Refik Molva, and Thorsten Strufe. Safebook :
a privacy preserving online social network leveraging on real-life trust.
IEEE Communications Magazine, Vol 47, N.12, Consumer Communications and Networking Series, December 2009, 2009. 1
[5] Diaspora Team. Hello From 2011. http://blog.joindiaspora.com/2011/01/
31/hello-from-the-new-year.html, 31. Jan. 2011. Visited: 20. Feb. 2011.
VI
[6] J. Dinger and H. Hartenstein. Netzwerk-und IT-Sicherheitsmanagement:
Eine Einführung. KIT Scientific Publishing, 2008. II
[7] d.m. boyd and N.B. Ellison. Social network sites: Definition, history,
and scholarship. Journal of Computer-Mediated Communication, 13(1),
2007. I
[8] Experian
Hitwise.
Top-visited
Websites
in
2010.
http://www.hitwise.com/us/press-center/press-releases/
facebook-was-the-top-search-term-in-2010-for-sec/,
21. Dec. 2010.
Visited: 04. Jan. 2011. I
[9] Facebook Blog, Mark Zuckerberg. 500 Million Stories. http://
blog.facebook.com/blog.php?post=409753352130, 12. Jul. 2010. Visited: 04. Jan. 2011. I
[19] Steve O’Hear TechCrunch. Video: Major Facebook security hole lets
you view your friends’ live chats. http://eu.techcrunch.com/2010/05/05/
video-major-facebook-security-hole-lets-you-view-your-friends-live-chats/,
05. May. 2010. Visited: 04. Jan. 2011. I, II
[20] The Register, Dan Goodin. Code for open-source Facebook littered
with landmines. http://www.theregister.co.uk/2010/09/16/diaspora_pre_
alpha_landmines/, 16. Sep. 2010. Visited: 03. Jan. 2011. III
[21] Emily Steel & Geoffrey A. Fowler THE WALL STREET JOURNAL.
Facebook in Privacy Breach - Top-Ranked Applications Transmit
Personal IDs, a Journal Investigation Finds. http://online.wsj.com/
article/SB10001424052702304772804575558484075236968.html,
18. Oct. 2010. Visited: 04. Jan. 2011. II
[22] Timothy Shoaf. Re: Diaspora in mesh network. http://groups.google.
com/group/diaspora-dev/msg/5727c593f464547e, 11. Feb. 2011. Visited:
20. Feb. 2011. III
[23] Kai Biermann ZEIT ONLINE.
Daten von SchülerVZ kopiert.
http://www.zeit.de/digital/internet/2009-10/schuelervz-hack,
17. Oct. 2009. Visited: 04. Jan. 2011. I, II
84
~
1
P2P-BASED VOIP
P2P-based VoIP
Zoran Zarić
zz@zoranzaric.de
Abstract—Voice over IP is gaining importance as more and
more companies transfer their voice communication infrastructure away from the public switched telephone network towards
IP networks. Existing voice over IP solutions have single points
of failure and lack scalability. Peer-to-peer systems can improve
scalability and robustness. This paper first gives an overview
over the basic building blocks peer-to-peer systems are based
on, defines six requirements a peer-to-peer based voice over IP
system should meet, and discusses six systems – Skype, XMPP
Jingle, P2P-SIP, SOSIMPLE, iPTT, and DISCOS. P2P-SIP is
the most matured open source system that can benefit by some
concepts SOSIMPLE implements.
1
14
2
4
I. I NTRODUCTION
Classic telephony is based on the public switched telephone
network (PSTN). It is circuit switched, so every call needs
a dedicated line, which doesn’t scale and is very expensive.
Voice over IP (VoIP) solves this problem by switching from a
circuit switched to a packet based network.
Some years ago communication providers started serving
next generation network (NGN) lines. These include an IP
connection, which is shared for internet access, telephony,
and sometimes television. Telephony providers also started to
switch their telephony backbones from PSTN to VoIP recently.
P2P systems can further improve this development by
offering high scalability, robustness, and fault tolerance. In
this paper I try to find a peer-to-peer voice over IP solution
that is open source and is based on open protocols.
In Section II I provide background information on P2P,
VoIP, and some related techniques. Section III discusses some
existing approaches for P2P VoIP systems. Finally Section IV
compares these approaches and gives an outlook on what needs
to be done to provide a complete solution.
5
11
9
Fig. 1.
7
A Chord network
A node maintains a routing table, that consists of predecessors, successors, and shortcuts through the ring, which are
called fingers. The number of predecessors and successors is
an implementation decision. The default number of fingers is
m. Figure 1 shows an example Chord network with m = 4.
2) Distributed Hash Tables (DHT): Distributed Hash Tables (DHT) map keys to values over a set of nodes. Usually
keys are derived from values using hash functions. Each node
is responsible for a set of values that depends on its key in
the DHT’s key space. The nodes in a DHT and their relations
form an overlay network.
A multitude of variations of concepts for DHTs exists.
Routing algorithms in DHTs range from non deterministic
routing using flooding of queries to deterministic greedy
routing. The overlay structure can be based on the underlying
network structure or solely be based on the key space. The
key space can be single dimensional or multi dimensional. In
the case of multi dimensional key spaces often a hash function
is used per dimension.
Auto-adaptive DHT (AA-DHT) [5] is a concept for a DHT
that can dynamically adapt the size of the list of nodes to
optimize the message size and the request latency.
A node in an AA-DHT maintains a routing table that is split
up into two tables. One with its predecessors and one index
table. A node A is a predecessor P for a node B, if A might
relay messages over B. If N is the total number of nodes in
II. BACKGROUND
A. Peer-to-Peer (P2P)
A P2P network consists of equally privileged participants
which make some resource available to the rest of the network.
Resources can be disk storage, bandwidth, or processing
power.
1) Chord: Chord [17] is a lookup protocol with a ringbased overlay structure and deterministic greedy routing. This
means, that with knowladge of the network you can predict the
routing paths (deterministic) and routing decisions are based
on locally optimal choice (greedy routing). Chord uses m-bit
identifiers. Nodes are placed on a ring at the position according
to their identif ier. The identifier for a node is the SHA1
hash for its ip address mod 2m , the identifier for a data chunk
is the SHA1 hash for its content or name mod 2m . A node
is responsible and stores values with identifiers between its
identifier and its predecessor’s identifier.
85
2~
P2P-BASED VOIP
the network, then the index table stores Log2 (N ) nodes.
AA-DHTs are based on two assumptions.
1) One can exhibit regularity in the average life time of a
node on a DHT.
2) Nodes with an average lifetime greater than a specified
threshold T will probably keep their average lifetime
above T .
If a node registers a node that has an average lifetime greater
than T it propagates the new node to all its predecessors.
In P2P networks the topologies of the overlay network and
the underlying network often differ greatly. Two nodes – one
in Germany (A) one in New Zealand (B) – can be Neighbors
in the overlay and a third node from Austria might route
its message to A over B. This results in a lot of network
traffic and long latencies. Basing the overlay structure on top
of the topology of the underlying network is the concept for
topology-based DHTs (T-DHT) [6].
T-DHTs where introduced with sensor networks and adhoc networks with low-power hardware in mind. Network
communication consumes a lot of energy, which is very limited
in such devices. T-DHTs reduce network traffic, latency, and
energy consumption.
The overlay structure is based on a two dimensional virtual
coordinate system, which is constructed by the nodes using
triangulation. The hop distance of the underlying network is
used as the distance metric. The resulting coordinate system
doesn’t represent physical but only logical locations.
The T-DHT on top of the virtual coordinate system is
inspired by CAN [10]. Every node is responsible for a rectangular key space around its position in the coordinate system.
3) Network Address Translation (NAT) traversal: In P2P
networks peers often are connected via dial up, ADSL, or
cable connections with one public IP address. Usually this
connection is shared between several computers. Therefore
the router has to translate private IP adresses to the public IP
address. This is called Network Address Translation (NAT).
Because in P2P networks communication between peers is essential a method to contact peers behind NATs is needed. The
Interactive Connectivity Establishment (ICE) [11] protocol is
a protocol for NAT traversal. For a NAT traversal a third party
that is accessible by both communication partners is needed.
ICE makes use of of two protocols. Session Traversal
Utilities for NAT (STUN) [12] and its extension Traversal
Using Relay NAT (TURN) [9].
STUN can be used for other protocols to implement NAT
traversal. It has three purposes.
1) determine the IP address and port allocated to by a NAT
2) check connectivity between to endpoints
3) keep-alive to maintain NAT bindings
TURN allows a peer behind a NAT to use a third party as
a message relay.
The Session Initiation Protocol (SIP) is based on the Hyper
Text Transfer Protocol (HTTP). SIP is only used for call
signaling (like call setup) in VoIP communication and doesn’t
include media transfer. SIP messages include e.g. REGISTER
for registration and INVITE for call setup. A registrar is a
server that is responsible for one or more domains and registers
user agents (UA). A proxy routes messages to their destination.
III. A PPROACHES
This section introduces six approaches for P2P VoIP systems. First I’ll show the commercial reference Skype. The
second approach discussed will be XMPP with the Jingle
extension. Approaches three and four are Chord based – P2PSIP (3), SOSIMPLE (4). iPTT, the fifth discussed approach,
is DHT based but doesn’t specify a concrete DHT. The last
discussed approach isn’t a real VoIP system but can be utilized
by such systems. Except for Skype and iPTT all VoIP systems
only do signaling, media transfer is out of their scope.
For better comparability I define six requirements. The P2P
VoIP system I am looking for should have telephony-like
voice chat. This means both partners can talk simultaneously
(full-duplex). The System should have no single point of
failure (SPOF). Some sort of authentication should be
available. Because we look at P2P systems a NAT traversal
solution should be built-in. To have the possibility to improve
the systems or build on top of them they should be open
source and should have an open protocol.
A. Skype
Login
O12
O9
O11
O8
O10
S4
S3
O7
O1
S1
S2
O4
O3
O6
O2
Fig. 2.
B. Voice over IP (VoIP)
O5
A possible part of the Skype network
Skype is a commercial P2P software that combines:
1) telephony
2) voice chat
3) video chat
4) instant messaging
In contrast to the public switched telephony network
(PSTN) – a circuit-switched frame relayed network –, where
one line is needed for one call, voice over IP provides
telephony over connection-less packed based IP networks.
86
~
3
P2P-BASED VOIP
alice@tu-darmstadt.de
bob@cased.de
tu-darmstadt.de
bar@tu-darmstadt.de
Fig. 3.
alice@tu-darmstadt.de
cased.de
bob@cased.de
tu-darmstadt.de
bar@cased.de
bar@tu-darmstadt.de
A XMPP message flow
Fig. 4.
cased.de
bar@cased.de
A XMPP Jingle message flow
All Skype to Skype communication is IP based and free
of charge. PSTN calls are available as a paid service. Skype
has state-of-the-art NAT traversal. I discuss Skype to get an
reference of what is possible.
1) Network structure: About the underlying P2P network
nothing is known as a matter of fact. Both the client and
the protocol are proprietary and closed source. All knowledge
comes from reverse engineering. [2]
The P2P network is probably based on FastTrack because its
developers Niklas Zennström and Janus Friis where Skype’s
founders. It consists of supernodes and ordinarynodes. Supernodes can be used for NAT traversal and call setup. Every
peer can become a supernode. In some clients becoming a
supernode can be disabled. A unknown number of supernodes
is hard coded into the client and a random supernode is used
for bootstrapping (initial network join). Figure 2 shows a
possible part of the Skype network.
Authentication, billing, and PSTN calls are done over dedicated servers.
2) Key features: Skype has a great marketshare, very
good NAT traversal and firewall hole-punching, and PSTN
calls.
3) Issues: Both Skype’s protocol and source are closed.
to the domain part of their Jabber ID (JID). JIDs have the same
format as e-mail addresses.
If Alice (alice@tu-darmstadt.de) wants to send a message to
Bob (bob@cased.de), Alice’s XMPP-client sends the message
to the server that is responsible for the domain tu-darmstadt.de
the tu-darmstadt.de-server then forwards the message to the
server that is responsible for the domain cased.de, which then
forwards the message to bob@cased.de. An example XMPP
message flow is shown in figure 3. This path is also used to
establish the client-to-client connection using Jingle. Once this
connection available the message flow seen in figure 4 is used.
XMPP in it’s current form isn’t a P2P protocol. It is a
client-server architecture with each server as a SPOF. It could
be argumented, that XMPP servers could be interpreted as
supernodes and clients as ordinarynodes, but a client can’t
become a server and the responsibilities for clients based on
the domain are fixed, so if a server fails its clients can’t just
connect to other servers.
2) Key features: XMPP is a open protocol and is very
extensible. Many open source implementations of server
and clients exist and have matured.
3) Issues: XMPP is no real P2P system and servers have
to maintained.
B. XMPP Jingle
C. P2P-SIP
Extensible Messaging and Presence Protocol (XMPP) is a
very extensible open messaging protocol that was generalized
from the Jabber instant messaging protocol. [14] [13]
Jingle [8] is an extension by Google that adds client-toclient connection signaling. The client-to-client connections
can be RTP streams [1] resulting in VoIP and video chat
functionality. Google Talk [15] is a service implementing the
XMPP protocol, Jingle and voice/video calls using RTP. Another extension implements Dual-tone multi-frequency signaling (DTMF) using XMPP messages to interact with interactive
voice response systems or PSTN. Pidgin, an instant messaging
client, supports voice and video chats using XMPP and Jingle.
1) Network structure: One XMPP server is responsible for
one or more domains. Clients register at their server according
P2P-SIP was proposed by Kundan Sing and Henning
Schulzrinne in 2005 [16]. P2P-SIP introduces P2P mechanics
to SIP telephony. It adds a DHT to replace some SIP features
that normally use DNS. The decision which DHT to use is an
implementation decision.
Sing and Schulzrinne provide an example implementation
called SIPpeer. SIPpeer uses Chord to implement the DHT
and has the following features:
1)
2)
3)
4)
5)
6)
87
outbound SIP proxy to use existing SIP user agents (UA)
SIP UA
SIP proxy
SIP registrar
media relay
STUN and TURN server
4~
P2P-BASED VOIP
1
14
with built in NAT traversal. Basic password authentication
is implemented and the protocol is open.
3) Issues: P2P-SIP is not robust against malicious clients.
Such malicious clients could drop messages routed through
them. Also call setup latency can take long in big networks.
O4
O5
2
O6
D. SOSIMPLE
SOSIMPLE [3] is very similar to P2P-SIP. Like P2P-SIP it
uses a DHT to add P2P features on top of SIP.
SOSIMPLE uses SIP as a base for a VoIP system because
it is mature, recognized by firewalls, traffic shapers, etc.. SIP’s
REGISTER messages are used for DHT operations.
In difference to P2P-SIP, SOSIMPLE doesn’t have built in
NAT traversal or authentication.
4
5
11
1
7
9
O1
14
O3
O2
Fig. 5.
2
A P2P-SIP network
P2P-SIP is fully compatible with existing SIP infrastructure.
It adds the DHT functionality if the local domains doesn’t have
a SIP server. It uses SIP to replace DNS for next hop lookup
in SIP for:
1) peer discovery
2) user registration
3) node failure detection
4) user location
5) call setup
SIP REGISTER messages are used for lookup, join, and
message routing. All non-REGISTER messages, like INVITE
messages, are proxied or redirected.
P2P-SIP
uses
SIP
URIs
of
the
form
sip:identifier@address:port. If the address and port are
unknown the domain is used. If no domain is available – e.g.
for DHT maintenance messages – example.invalid it used.
Authentication is accomplished with an email address and
a password in REGISTER messages. The password is mailed
to the email address given in the contact header in the first
REGISTER request.
P2P-SIP supports offline messages. They are stored at the
sender and intermediate DHT nodes.
The call setup latency increases with the number of nodes
in the Chord ring. According to Sing and Schulzrinne’s paper
a network with 10000 nodes has a call setup latency of 1-2
seconds.
1) Network structure: The example implementation
SIPpeer uses Chord as the DHT. High capacity nodes
(bandwidth, CPU, memory, uptime, public IP address) can
become supernodes and form the DHT. Ordinary nodes can
attach to one or more supernodes. Each supernode stores
log(N ) successor addresses. User registrations are replicated
at K successors
2) Key features: The existing implementation SIPpeer
brings full compatibility with existing SIP infrastructure
4
5
11
9
Fig. 6.
7
A SOSIMPLE network
1) Network structure: SOSIMPLE’s network structure is
based on Chord. A nodes identifier is the SHA-1 hashed public
IP address. Only 16 fingers are maintained. Additional finger
table entries for contacts in the buddy list are pre fetched.
This reduces call setup latency. Figure 6 shows an example
SOSIMPLE network with m = 4 and 1 finger.
2) Key features: SOSIMPLE is compatible with existing
SIP infrastructure. Its pre-fetching of contact-addresses
reduces call setup latency and the reduced count of fingers
minimizes maintenance. It is a open protocol.
3) Issues: SOSIMPLE doesn’t implement authentication
or NAT traversal.
E. iPTT
iPTT [7] is an IP- and DHT-based Push-to-Talk service.
Push-to-Talk services are half-duplex. User-to-user and group
communication are possible. In contrast to radiocommunication, which is the biggest form of push-to-talk communication,
iPTT is not geographically restricted. iPTT is targeted at
mobile devices.
88
~
5
P2P-BASED VOIP
Centralized servers like STUN and TURN servers are single
points of failure. STUN and TURN need keep-alive messages
which add up.
In a DISCOS network every node provides a STUN/TURN
server and relays SIP messages. Special nodes – called connectivity peers – can be SIP proxies or media relays. Nodes
use the first available connectivity peer.
DISCOS’s goals are:
When starting a group communication a peer sends a
SIP INVITE to its supernode. This supernode forwardes the
INVITE message to all supernodes that are responsible for
peers in the group. Those supernodes then forward the message
to the peers in the group. After all peers in the group answered
the INVITE with an OK message the peer that started the
group communication sends its voice message on the same
path the INVITE was sent. After it is finished another peer can
use the group. A group is closed when the peer that started
it leaves it using a BYE message. See figure 7 for a example
group setup.
Push-to-Talk over Cellular (POC) solutions exist, but are
vendor or carrier specific.
iPTT’s goal is to be:
1) vendor and carrier agnostic
2) scalable
3) cost-effective
4) robust
SIP messages are used for signaling and DHT maintenance,
RTP/RTCP for media streams. Because communication is only
half-duplex in contrast to full-duplex voice chats no highperformance voice mixer is needed. No specific DHT is used
in the specification, AA-DHTs or T-DHTs are proposed.
1) Network structure: The network consists of supernodes
and ordinarynodes. Supernodes perform signaling/voice relaying and group-member joining/leaving. Messages are relayed
through supernodes on the path. The supernodes multiplex
the streams (multicast). A possible iPTT network is shown
in figure 7 The metrics upon which it is decided if a node
becomes a supernode are:
1) bandwidth
2) power consumption restriction
3) computing performance
1)
2)
3)
4)
1) Network structure: DISCOS uses an unstructured gossip
based network because no maintenance and no accurate results
are needed. Gossipping means, that queries are propagated
from one peer to a randomly selected peer from his routing
table, results follow the same path backwards. The network
is scale-free. This means the number of connections to other
peers from each peer follows a power-law distribution, we
therefore have some highly connected peers.
Peers cache a number of known connectivity peers, this
information is refreshed in short intervals to be kept fresh. The
cache is sorted by popularity. Hubs are peers that are known
by many other peers and therefore receive many advertisement
messages. Advertisement messages are periodically sent to
all nodes in the cache. Advertisement messages have a TTL.
Received advertisement messages are forwarded or dropped
according to its TTL. If the advertised node is unknown it
is added to the cache. When an advertisement message is
received the popularity for nodes in the cache is increased.
Average popular peers are dropped, when the cache is full
and an unknown peer is advertised. Both hubs and low traffic
peers are favoured. As with most P2P systems security is a
problem
2) Key features: DISCOS adds NAT traversal and media
relay capabilities to arbitrary systems.
O9
O8
S3
scalability
robustness
reduced bandwidth
fast lookup
O7
IV. S UMMARY & C ONCLUSION
O1
S1
S2
O3
O6
O2
Fig. 7.
Skype is the most mature P2P VoIP solution in the market.
It has the biggest market share and the most features. But
because it is closed source and has a closed protocol we only
use it as a reference.
XMPP Jingle gaining market share more and more instant
messaging clients add Voice capablitys to their feature set
and Google Talk’s presence on the Andriod platform help
increasing XMPP Jingle’s reach.
P2P-SIP and SOSIMPLE are very similar. They both use
SIP for messaging and add P2P features to it using the Chord
DHT. These two systems are the only real P2P solutions for
VoIP telephony. With its example implementation P2P-SIP
seems to be most matured and complete. SOSIMPLE’s reduced finger table size and caching for contacts could improve
P2P-SIP. A possible future work could be the evaluation of
a replacement of Chord in favour of a T-DHT. This would
possibly improve call setup latency and voice latency if nodes
are used as media relays.
O4
O5
A iPTT network with group communication
2) Key features: Because iPTT’s voice streams are halfduplex no voice mixer is needed. It is bandwidth efficient
through multicast.
F. DISCOS
DISCOS [4] itself isn’t a VoIP system. It is a P2P NAT
traversal and media relay system, that can be utilized by
VoIP systems, that don’t have NAT traversal built in – e.g.
SOSIMPLE.
89
6~
P2P-BASED VOIP
Skype
XMPP Jingle
P2P-SIP
SOSIMPLE
iPTT
DISCOS
Telephony-like Voice Chat
X
X
X
X
No SPOF
X
X
X
X
Authentication
X
X
X
NAT Traversal
X
X
X
Open Source
Open Protocol
X
X
X
X
X
X
X
X
X
X
TABLE I
OVERVIEW OVER MET REQUIREMENTS
iPTT is an interesting special purpose solution which can
shine in disaster scenarios where mobile devices are used to
communicate in ad-hoc networks.
DISCOS could be integrated into SOSIMPLE to compensate its lack of a NAT traversal solution.
See table I for an overview over the met requirements.
[17] I. Stoica. Chord: a scalable peer-to-peer lookup protocol for internet
applications. IEEE/ACM Transactions on Networking, 41(5):297–32,
February 2003. II-A1
A. open problems
Nearly all of the shown approaches need improvements in
their security. Authentication is either implemented in a very
basic way or left out totally. This isn’t a VoIP specific problem,
but the low cost of running nodes in a P2P network often lead
to abuse. The downside of open protocols is that everybody
can implement a client and so the system has to be robust
against malicious implementations.
R EFERENCES
[1] XEP-0167: Jingle RTP Sessions. Transport, 0167(0167). III-B
[2] Salman A Baset and Henning Schulzrinne. An Analysis of the Skype
Peer-to-Peer Internet Telephony Protocol. New York, 2004. III-A1
[3] D.A. Bryan, B.B. Lowekamp, and C. Jennings. Sosimple: A serverless,
standards-based, p2p sip communication system. System, i(2005), 2005.
III-D
[4] L Ciminiera, G Marchetto, F Risso, and L Torrero. Distributed
connectivity service for a SIP infrastructure. Network, IEEE, 54(3):258,
2008. III-F
[5] a. Dury. Auto-adaptive distributed hash tables. The 6th IEEE/ACM
International Workshop on Grid Computing, 2005., page 6 pp., 2005.
II-A2
[6] O. Landsiedel, K.a. Lehmann, and K. Wehrle. T-DHT: Topology-based
Distributed Hash Tables. Fifth IEEE International Conference on Peerto-Peer Computing (P2P’05), (2):143–144. II-A2
[7] JR Lin and AC Pang. iPTT: peer-to-peer push-to-talk for VoIP. Wireless
Communications and, V(1):1–25, 2008. III-E
[8] S Ludwig, J Beda, and P Saint-Andre. Xep-0166: Jingle. XMPP
Enhancement, 2005. III-B
[9] R. Mahy, P. Matthews, and J. Rosenberg. Traversal Using Relays around
NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT
(STUN). RFC 5766 (Proposed Standard), April 2010. II-A3
[10] Sylvia Ratnasamy, Paul Francis, Mark Handley, Scott Shenker, and
Richard Karp. A Scalable Content-Addressable Network. II-A2
[11] J. Rosenberg. Interactive Connectivity Establishment (ICE): A Protocol
for Network Address Translator (NAT) Traversal for Offer/Answer
Protocols. RFC 5245 (Proposed Standard), April 2010. II-A3
[12] J. Rosenberg, R. Mahy, P. Matthews, and D. Wing. Session Traversal
Utilities for NAT (STUN). RFC 5389 (Proposed Standard), October
2008. II-A3
[13] P Saint-Andre. Extensible Messaging and Presence Protocol (XMPP):
Instant Messaging and Presence (RFC 3921). Security, C(3921):1–107,
2004. III-B
[14] P. Saint-Andre and Others. Extensible messaging and presence protocol
(XMPP): Core. Security, C(3920):1–90, 2004. III-B
[15] B Sat. Analysis and evaluation of the Skype and Google-Talk VoIP
systems. Multimedia and Expo, 2006 IEEE, V(61801), 2006. III-B
[16] K. Singh and H. Schulzrinne. Peer-to-peer internet telephony using SIP.
In Proceedings of the international workshop on Network and operating
systems support for digital audio and video, June, volume I, pages 13–
14. Citeseer, 2005. III-C
90

Seminar P2P im Wintersemester 2010

Transcription

Similar documents

Grundlagen der Video-Integration

Studienarbeit Implementierung einer IP-Multicast

Ausgewählte Themen der IT-Sicherheit

Alexander Alexandrov