李秀惠博士點對點網路檔案分享之可靠聲譽

Transcription

李秀惠博士點對點網路檔案分享之可靠聲譽

國立台灣大學資訊工程研究所碩士論文
指導教授：李秀惠博士
點對點網路檔案分享之可靠聲譽系統
的設計與實作
Design and Implementation of a Reliable
Reputation System for File Sharing in
Peer-to-Peer Networks
研究生：黃盈傑撰
中華民國九十五年六月
致謝
這篇論文的完成，首先要感謝老師李秀惠教授的指導。在這幾年裡，不論是
專業領堿裡知識的學習、論文題目摸索的過程還有作研究的方法，都有賴於老師
的教導，今日才能順利完成這篇論文。
再來要感謝實驗室裡的學長姊，麗娟、士傑、柏戎、承良，從各位身上學到
了不少經驗。還有同屆的健銘、錦驊、淳筌，唸研究所的期間多虧了你們在課業
上的照應，也共渡了一段歡樂的時光。特別感謝 coding 魔人楊淳筌，即使是在
服役之期，也替我解決了許多程式實作的問題。還有 93、94 級的學弟們，青坡、
億宗、宗賢、俊豪、詩禹、曜徽、韋志、榮宏、逸群、建霖，從你們身上也得到
不少幫助，實驗室也因有你們的加入和照顧，變的更有生氣、更有活力。
最後要感謝我的家人和朋友。不論是遇到挫折，還是陷入困境，都要多謝你
們替我分憂解勞，幫助我順利克服各種困難。因為有你們的支持，才能有今天的
我。
Abstract
Nowadays, peer-to-peer (P2P) applications have played an important role in the
network. Many applications have a great success by using P2P protocol, such as file
sharing, distributed processing, and instant messaging, etc.
In file-sharing
applications, because of the anonymity of P2P, there is a problem that some of file
providers may misuse by providing tampered files – wrong files, bad files, even
viruses and Trojan Horses.
There are already many existing researches on reputation system for P2P
file-sharing, but they still limited to the resistance of some attacks. We add a server
into our reputation system, in order to record all users’ actions, include uploading,
downloading, judging and getting judgment. To make our reputation system more
reliable, we have the monitor component that monitors these records to determine
whether there is any malicious behavior, and punish the malicious users if some
wrong behaviors are detected.
Keywords: P2P, reputation mechanism, trust.
I
中文摘要
在現今的網路上點對點網路的應用程式扮演了一個重要的角色。很多應用程
式經由點對點協定都獲得極大的成功，例如檔案分享、分散式處理和即時通訊。
由於點對點網路的匿名性，在檔案分享的系統裡就有個潛藏的嚴重問題，那
就是檔案提供者有可能提供竄改過的檔案，例如：內容和檔名不符的檔案，或者
是損壞的檔案，甚至是含有病毒和特洛依木馬的檔案。
目前在點對點檔案分享系統上建立聲譽系統已有許多相關的研究，但對於某
些攻擊行為的抵抗力仍然有限。我們在我們的聲譽系統裡加入一個伺服器，以便
記錄所有使用者的行為，包含上載、下載、評價以及取得評價等動作。經由我們
設計的行為監控程式，來判斷是否有的惡意行為，並進一步處罰惡意的使用者，
讓我們的聲譽系統更可靠。
關鍵字：點對點網路、聲譽機制、信任。
II
Content
Abstract......................................................................................................................... I
中文摘要....................................................................................................................... II
Chaper 1 Introduction ....................................................................................................1
1.1 Motivation........................................................................................................1
1.2 Objectives ........................................................................................................2
1.3 Organization of this thesis................................................................................3
Chaper 2 Related Work ..................................................................................................4
2.1 P2P Architecture ..............................................................................................4
2.1.1 Pure P2P Architecture ........................................................................5
2.1.2 Hybrid P2P Architecture ....................................................................5
2.1.3 Hierarchical P2P Architecture ...........................................................6
2.2 JXTA ................................................................................................................7
2.3 Problems and Attacks.......................................................................................9
2.3.1 Problems on P2P Network .................................................................9
2.3.2 Attacks to P2P Systems ......................................................................9
2.3.3 Attacks to Reputation-based Systems .............................................10
2.4 Existing Reputation-based Trust Management ..............................................12
Chaper 3 Design Issues & System Architecture ..........................................................14
3.1 Design Issues .................................................................................................14
3.1.1 Definitions..........................................................................................15
3.1.2 Formulas Design................................................................................16
3.2 Defend the Attacks.........................................................................................17
3.3 Monitor Design ..............................................................................................18
3.4 System Architecture.......................................................................................22
Chaper 4 System Implementation & Experiments.......................................................24
4.1 System Implementation .................................................................................24
4.1.1 Information Storage..........................................................................24
4.1.2 Application Overview .......................................................................26
4.2 Experiments ...................................................................................................33
Chaper 5 Conclusions & Future Works .......................................................................40
5.1 Conclusions....................................................................................................40
5.2 Future Works..................................................................................................41
References ...................................................................................................................42
Appendix.....................................................................................................................44
List of Tables
Table 2-1. Comparison with client/server and peer-to-peer architecture .......................................4
Table 3-1. Comparison of reputation system in different architectures........................................14
Table 4-1. Fields of reputation_data table .......................................................................................24
Table 4-2. Fields of client_registration table ...................................................................................25
Table 4-3. Fields of report record file...............................................................................................25
List of Figures
Figure 2-1. Pure P2P Architecture......................................................................................................5
Figure 2-2. Hybrid P2P Architecture .................................................................................................6
Figure 2-3. Hierarchical P2P Architecture ........................................................................................6
Figure 2-4. The JXTA three-layer architecture.................................................................................7
Figure 2-5. An example of Content Advertisement with Metadata.................................................8
Figure 2-6. Man in the middle attack...............................................................................................10
Figure 2-7. Self replication................................................................................................................10
Figure 2-8. Pseudospoofing ............................................................................................................... 11
Figure 2-9. Shilling attacks ............................................................................................................... 11
Figure 3-1. Flowchart of the Monitor ..............................................................................................18
Figure 3-2. Flowchart of determine phase: F-9...............................................................................19
Figure 3-3. Flowchart of determine phase: F-12.............................................................................20
Figure 3-8. System Architecture .......................................................................................................22
Figure 4-1. Screen shot of “Connect”...............................................................................................26
Figure 4-2. Query on multi-server....................................................................................................27
Figure 4-3. Screen shot of “Search file”...........................................................................................27
Figure 4-4. Screen shot of "Query report record from other peers”-1 .........................................28
Figure 4-5. Screen shot of "Query report record from other peers”-2 .........................................28
Figure 4-6. Screen shot of “Query the access history of the file" ..................................................29
Figure 4-7. Report on multi-server ..................................................................................................29
Figure 4-8. Screen shot of “Report”.................................................................................................29
Figure 4-9. Screen shot of main frame .............................................................................................30
Figure 4-10. Screen shot of monitor result.......................................................................................30
Figure 4-11. Screen shot of monitor parameters setting.................................................................31
Figure 4-12. System framework of Server on-line ..........................................................................32
Figure 4-13. System framework of Server off-line..........................................................................32
Figure 4-14. Result of Type-1 experiment........................................................................................34
Figure 4-17. Compare selection the highest reputation, 0.8 and 0.5 in Type-1.............................36
Figure 4-20. Result of Type-1 experiment with different variations..............................................38
5
Chaper 1 Introduction
1.1 Motivation
In the past, network services have paid much attention to access control
management, authentication protocols, and cryptographic algorithms for privacy and
digital signatures. These methods from server providers are using to protect their
services and resources. It seems the question is whether the user can be believed or
not.
But in recent years, service providers begin to pay attention to another question
that do the users trust our resources? Amazon, eBay and Yahoo have adopted the
approach of reputation-based trust management. Customers can look for past
comments before buying the product at Amazon.com. Participants can check
auctioneers' history before biding and rate each other after each transaction at eBay's
and Yahoo's auctions.
As P2P networks are in the flourishing development, and many services have
been transferred to P2P protocol. When those users use traditional means such as
FTP and the Web to download files, they can choose the site that they trust. But P2P
infrastructure's anonymity causes malicious users to exploit this property to freely
distribute Trojan Horse and Virus programs. To ensure that users can get reliable
information of the resources and other peers, it is really important to develop a
reputation system on the P2P network. So we can see that similar approaches are
also taken in P2P networks.
Copyright Problem
First of all, many people utilize P2P tools exchange digital files that possibly
without the permission of copyright owners. Thus, there are some organizations
attacking P2P systems in order to protect the intellectual property rights such as the
RIAA (Recording Industry Association of America) and MPAA (Motion Picture
Association of America) and IPFI (International Federation of the Phonographic
Industry) [CDCPS 2002].
Napster [Napster 1999] is a file-sharing system with the central indexed server.
Napster finally fails due to copyright problem, because its server was attached.
Those users of Napster can not use the service any more. P2P applications in
1
Taiwan such as Kuro [Kuro] and ezPeer [ezPeer] had also begun to wane by litigation.
Therefore, some later P2P applications are more interesting on “pure” p2p like
Gnutella [Gnutella 2000].
1.2
Objectives
Since P2P systems have various architectures, the reputation systems based on it
can also be different. Reputation can be centralized and be computed by a trusted
third party. Or it can be decentralized and be computed independently by each peer
after asking other peers for recommendations. We are going to build a reputation
system with a server to provide reliable information. The users can rest assured to
download the files based on the file provider’s reputation.
The objectives of this thesis are:
1.
Detect the malicious users and punish them.
2.
Design a mechanism to determine the judgments are real or not.
2
1.3 Organization of this thesis
This thesis is structured as follows:
Chapter 1: Introduction
This chapter states motivation and objective of this research.
Chapter 2: Related work
This chapter has some simple introductions to P2P networks, JXTA
project, some existing reputation-based trust management, the problems
and attacks to P2P and reputation system.
Chapter 3: Design Issues & System Architecture
This chapter will describe how we design the reputation system and defend
the attacks, and show our system architecture.
Chapter 4: System Implementation & Experiments
This chapter briefly describes how the system is implemented, and some
screen shots of our application. Then, we will discuss the results of the
experiments.
Chapter 5: Conclusions & Future Works
The conclusions and some future works are listed in this chapter.
3
Chaper 2 Related Work
2.1
P2P Architecture
"Peer-to-peer" is a generic term of network architectures that all the nodes offer
the same services and have the same behavior. When we focus on file exchange in
P2P networks, all nodes can act as clients and servers. In contrast to traditional
client/server architecture, P2P systems reveal some advantages [TS 2004, SR 2002]:
disperse the loading of the server to many peers, fast content distribution, the
bandwidth of all clients can be used, better fault tolerance, heterogeneous hardware
and software resources can participate together autonomously.
Table 2-1. Comparison with client/server and peer-to-peer architecture
Architecture
Property
Stability
Scalability
Fault tolerance
Cost
client/server
peer-to-peer
Depend on the server
Low
Low
High
Low
High
High
Low
The stability of client/server architecture depends on the server. If the server
always works properly, the stability is much better than the stability of P2P
architecture which is worse stable due to the dynamic variations of its peers. The
scalability of client/server architecture is low, because the server can only deal with
limited requests of the clients. In P2P architecture, more peers participate in the
network, more resources and services are available. The fault tolerance is also low
in client/server architecture, because all services are unavailable when the server
crashes. But in P2P architecture, the failure of one node will not crash the entire
network. It is certainly that there is a additional cost to maintenance the server, but
P2P architecture only works with peers’ devices in the network.
A P2P file exchange involves two phases: search and download. The search
phase is looking for peers who have the given file. And the download phase
establish a direct connection between the demander and provider (in most P2P
application). In the search phase, according to the way that peers find their
4
interesting files, we can divide P2P systems to three main architectures: Hybrid P2P
architecture, pure P2P architecture and Hierarchical P2P architecture.
2.1.1
Pure P2P Architecture
Pure P2P architecture is a fully decentralized architecture. All peers in this
network are really identical, and all interactions between peers are performed by
themselves. Due to the variations of dynamic network states, the performance can't
be expectable. Gnutella is a well known representative of pure P2P architecture.
Figure 2-1. Pure P2P Architecture
2.1.2
Hybrid P2P Architecture
In this architecture, it uses a centralized indexing server that describes the
resources offered by each peers. Therefore, every peer must connect to a server,
when they are starting. The server will keep a list of all peers and all resources.
When a peer wants to find some files, it sends a request to the server, and the server
can respond the matched files efficiently with the file indexes. The representatives
of this solution are Napster, eDonkey [eDonkey 2000] and eMule [eMule 2002].
5
Figure 2-2. Hybrid P2P Architecture
2.1.3
Hierarchical P2P Architecture
In the hierarchical P2P architecture, every peer may not act the same roles.
Taking FastTrack [FastTrack 2001] as an example, it distinguishes its peers in
supernodes and nodes. Supernodes are responsible for indexing the resources and
have a major role in the organization of the network. In general, a node with more
bandwidth and computational power is fit to be a "supernode".
Figure 2-3. Hierarchical P2P Architecture
6
2.2
JXTA
JXTA Project
JXTA is the abbreviation of “Juxtapose.” JXTA™ technology is a set of open
protocols that allow any connected device on the network ranging from cell phones
and wireless PDAs to PCs and servers to communicate and collaborate in a P2P
manner. JXTA peers create a virtual network where any peer can interact with other
peers and resources directly even when some of the peers and resources are behind
firewalls and NATs or are on different network transports [JXTA 2001].
The Logical Layers of JXTA
The JXTA platform can be broken into three layers, as shown in Figure 2-4.
Figure 2-4. The JXTA three-layer architecture
7
JXTA CMS
The Content Management Service (CMS) is a simple JXTA service that builds
for file-sharing and file-searching within a peer group [CMS 2002]. The shared
contents were also resources, and can be represented by advertisements. The content
advertisement contains some meta-information describing the content, including the
content name, length, mime type, id, and description. Content name and id are
necessary to describe content.
Figure 2-5. An example of Content Advertisement with Metadata
8
2.3 Problems and Attacks
2.3.1
Problems on P2P Network
•
Free-riders:
In P2P file sharing system, lots of users do not provide files for download by
others or just provide a few files. They only download files for themselves.
According to experiments on Gnutella, there are near 66% of all users share no
file, the top 1% users supply 47% of all downloads, and the top 25% users
account for 99%. The same phenomenon is also observed in Napster and Kazaa
[Kazaa 2002]. The Free-rider problem indicates that individual users often
have little incentive for sharing their own files [TWD 2004].
•
Tragedy of commons:
Hardin proved that common resources without any exclusive ownership will be
consumed without limit. He named this phenomenon “Tragedy of Commons”
[Hardin 1968].
In some P2P systems, peers can use the resources (bandwidth and storage space)
of others on the network without providing resources of their own available to
the network, thereby reducing the value of the network. While more users
choose not to share their resources, those peers who do share resources suffer
increased load and, in many ways, the network begins to revert to the classic
client/server architecture.
As a common resource that can be utilized freely, Internet bandwidth is
consumed by all kinds of P2P applications without limit, for example, statistic
shows that near 70% of the bandwidth of Internet backbones were occupied by
P2P applications [TWD 2004].
2.3.2
•
Attacks to P2P Systems
Distribution of tampered with information:
The simplest version of this attack is based on the fact that there is no way to
verify the sources. A malicious user can provide a fake resource with the same
as a popular resource. The actual file could be a Trojan Horse program or a
virus[LL 2004].
9
•
Man in the middle attack:
The malicious peer can intercept the message from the provider peer to the
requestor and rewrite it with his IP address and port instead of the provider’s.
Now, the malicious peer can infect the original content from the provider and
pass it on to the requestor [LL 2004].
Figure 2-6. Man in the middle attack
2.3.3
•
Attacks to Reputation-based Systems
Self replication:
A single node(user) N sequentially joins the system multiple times, creating
virtual identities N1,N2…Nn. In the reputation systems that adopt peer-voting
(polling) mechanism to response peer’s query message, this situation will lead to
a unfair voting result.
Figure 2-7. Self replication
•
Pseudospoofing:
The pseudospoofing attack exploits the P2P systems use of pseudonyms.
Pseudospoofing attackers create and control multiple phony identities. This
technique can be readily used to compromise P2P systems relying on
pseudonyms rather than on full authentication. Pseudospoofing is easy to
countermeasures based on peer reputations alone, as a malicious peer can turn to
10
a new pseudonym after earning a bad reputation, and simulate multiple witnesses
willing to give fake evidence in its favor[DVPSV 2002].
Figure 2-8. Pseudospoofing
•
Shilling attacks:
Shilling is a well-known problem of distributed auctions protocols, where a
malicious auctioneer may try to cheat his bidders by pushing up the price
creating multiple registration names (called shills) to bid under. Shilling is
different from pseudospoofing, as the multiple identities are actually created with
real IP addresses, and not just simulated, by the attacker[DVPSV 2002].
Figure 2-9. Shilling attacks
•
Reentry to get rid of the bad history:
The user that has a bad history or bad reputation gets a new ID, and play as a
new role in the system. With reentry, malicious users can keep on separating
bad files or causing damage to the reputation system when their original IDs are
restricted by the system.
11
2.4
Existing Reputation-based Trust Management
There are various mechanisms to build up reputation systems, and the reputation
systems may be for different functions. Like P2Prep [CDVPS 2002] and XRep
[DVPSV 2002] are using the polling protocol and focus on the improvement of
security of the communications between peers. Some researches focus on the users’
incentive to share their own resources [GBM 2001, MF 2002, NWD 2003]. Above
reputation systems are setting up the users’ credibility, and there are still some
reputation systems are setting for the resources. Like sig2dat [sig2dat 2002] which
Kazaa used is this kind.
Now, we briefly introduce how the Recommendation-based P2P trust model
[DWJZ 2004] restrains slander and magnifying (shilling attacks), because we will
compare the results of the experiments with it in chapter 4.
Recommendation-based P2P trust model
Definitions:
1. Sij: successful transactions from node j to node i.
2. Fij: unsuccessful transactions from node j to node i.
3. Eij: node i’s evaluation on node j. Eij = (Sij, Fij)
4. Rij: node i’s recommend degree on node
R
ij
=
S −F
∑S
ij
ij
kj
k
5.
Trust calculation formula:
T = ∑ (R ×T
i
ki
k
)
k
From definition 4 and 5, we can get:
S −
T = ∑( ∑ F
S
kv
v
k
kv
×T k)
jv
j
While node u tries to slander or magnifies node u. Node u will send an unreal Euv,
and set Suv a big number. When Suv is big enough, we can get:
T
v
≒ S uv
− F uv
S
×T u
uv
Therefore, when node u has a high trust, and Suv >> Fuv, node u can magnify
node v. If Suv ≒ Fuv, node u can slander node v.
12
Restrain slander and magnifying
1.
If node u puts Euv too frequently, the Euv may not be accept.
2.
For every transaction, when node u puts Euv, node v also needs to echo it in a
period of time.
If node v echos in time:
(a) Euv is positive evaluation, the Euv is accepted in the probability of Tv.
(b) Euv is negative evaluation, the Euv is accepted.
If node v does not echo in time:
(a) Euv is positive evaluation, the Euv is not accepted.
(b) Euv is negative evaluation, the Euv is accepted in the probability of 1-Tv
Therefore, when node u wants to slander a node with higher trust, the probability
is smaller; when node u wants to magnify a node with lower trust, the probability is
smaller too.
13
Chaper 3 Design Issues & System Architecture
3.1
Design Issues
Our goal is building a reputation system on the file sharing application that
provides each user a basis to select the file source. The reputation is based on users’
feedback after they download files. With the users’ feedbacks, we construct not only
the reputation of each client but the file’s access history. Therefore, clients can
consult the file provider’s reputation or the file’s access history, when they want to
download a file.
It is important that a reputation system is robust enough to against the attacks as
we have illustrated in section 2.3. Therefore, we design some mechanisms to defend
the attacks.
Although there are some drawbacks of client/server architecture, we still adopt it
to build our system. Because it is really hard to defend the attacks of the malicious
peers in the pure P2P network, we use the server to detect if any malicious behaviors
in our system. In order to reduce the weakness of the client/server architecture, the
server in our system can extend to multi-servers.
Table 3-1. Comparison of reputation system in different architectures
Architecture
Pure P2P
Property
Difficulty
Efficiency
Bandwidth cost
Fault tolerance
Overhead
Cost
Hard
Depend on
design
Depend on
design
High
Low
Low
Hierarchical
P2P
Hard
Depend on
design
Depend on
design
High
Low
Low
Hybrid P2P
Our System
Easy
High
Easy
High
Low
Low
Low
High
High
Moderate
Moderate
High
A comparison of reputation system in different architecture is given in Table 3-1.
Some early reputation systems are lower efficient and higher bandwidth cost in pure
P2P and hierarchical P2P architecture. Because the clients need gets all information
on other client’s when the clients query other clients’ reputation, so there are more
14
messages flooding in the network. Later reputation systems calculate the reputation
first and store the information on certain client, so there will be less query messages in
the network. Obviously, reputation systems in hybrid P2P architecture and our
system have also less message traffic, because the clients only need to query the
server to get the reputation information they want. Our system is seems much like
the hybrid P2P architecture, but there is a difference. Our RepServer does not work
as an index server, so the overhead is less than the reputation system in hybrid P2P
architecture.
3.1.1
Definitions
RepServer:
The key of our reputation system is this server, called RepServer. RepServer is
responsible for: maintain clients’ reputation data, record clients’ action, collect
clients’ report, response clients’ query and monitor clients’ action.
Client:
Because our reputation system is client/server architecture, we call the user “client.”
Cx represents client x.
Manager:
The RepServer can be managed by one or several managers.
work is handling the results of monitor.
The manager’s main
Monitor:
The capability of the Monitor is monitoring clients’ actions such as download, upload,
report, and get report. The Monitor will set the client’s state as “Alert” or “Forbid”
when the action counts exceeds the parameters. The parameters are adjusted by the
manager.
Report:
After a downloading, a client should send a message to RepServer to judge the
downloaded file.
Judgment:
In our system, the judgments of the files can briefly divide into three kinds: “Good”,
“Bad”, and “Very bad. ” “Good” represents the file is good. “Bad” represents that
perhaps the file is low quality, or perhaps the file name or file description doesn’t
match the file totally. “Very bad” represents the file can’t be used or even a harmful
file such as a virus or Trojan Horse.
15
3.1.2
Formulas Design
Global Trust Calculate Formula:
Each client’s Global Trust is calculated by the judgments he got and it is stored in the
RepServer’s database. The manager can set the weight (parameter w) of very bad
judgment, our default setting is 2.
GTx represents client x’s Global Trust.
g − b x − w × vb x
(1)
GT x = x
Jx
-1 ≤ GTx ≤ 1, w = 2
gx = Counts of “Good” judgments of Cx
bx = Counts of “Bad” judgments of Cx
vbx = Counts of “Very bad” judgments of Cx
Jx = gx + bx +w* vbx
Self-Trust Calculate Formula:
STxy represents the self-trust for client x to client y.
g − b − w × vb
(2)
ST =
J
-1 ≤ STxy ≤ 1, w = 2
xy
xy
xy
xy
xy
gxy = Counts of “Good” judgments that Cx report to Cy
bxy = Counts of “Bad” judgments that Cx report to Cy
vbxy = Counts of “Very bad” judgments that Cx report to Cy
Jxy = gxy + bxy +w* vbxy
Reputation Calculate Formula:
REPxy represents client y’s reputation to client x.
REP
xy
= α × GT y + (1 − α ) × ST xy
(3)
-1 ≤ REPxy ≤ 1, 0 ≤ α ≤ 1
Each client can set the coefficient ‘α’ himself. If the client only believes his
own report records, he can set α = 0. If the client has fewer report records, he can
set α a higher value (near 1) to adopt the global trust.
16
While the RepServer is off-line, clients can not get the GT of the clients register
on it. We can query other clients to get the judgments of them at this time. So the
calculate formula will change like this:
REP
xy
=β×
∑(g
z
zy
− b zy − w × vb zy )
∑J
+ (1 − β ) × ST xy
(4)
zy
z
-1 ≤ REPxy ≤ 1, 0 ≤ β ≤ 1, w = 2
z: all the other clients in the P2P network
Each client can also set the coefficient ‘β’ himself. The same as last coefficient
‘α’, if the client is much willing to believe the report records of other clients, he can
set β a higher value (near 1). On the contrary, the client can set β a lower value
(near 0) when he relatively believes his self-trust. If all clients are on-line, the
calculating result will be quite close to the value that calculated by formula (3).
3.2
Defend the Attacks
•
Self replication:
In JXTA’s P2P network, each peer has to set PlatformConfig if this is his first
time to run the application. With this setting, the IP address and port are bind to
this peer. So this peer can’t run with the same PlatformConfig second time.
Because we use the ID of the JXTA and MAC address to identify each peer, any
client copies the PlatformConfig to other computer to run the application will be
recognized as another peer. Therefore, this situation won’t occur in our system.
•
Distribution of tampered with information:
If there is some client downloads the tampered file, he will report to RepServer
to update the provider’s reputation, and that file’s access history is update too.
Other clients can prevent interact with this provider or download the tampered
file again.
•
Pseudospoofing:
Because the ID we designed, this can’t be done on a personal computer.
Anyone wants to do pseudospoofing attack must have enough hardware, and this
is not easy to achieve. If anyone has enough hardware to do pseudospoofing
attack, the situation is the same with “shilling attacks”.
17
•
Shilling attacks:
Our RepServer is always running a monitor thread that checks each client’s
download, upload, report action and the reports he gets, we can detect the
abnormal situations and then punish the cheaters. We will describe how the
“Monitor” works in next section.
•
Reentry to get rid of the bad history:
The same, because we use the ID of the JXTA and MAC address to identify each
peer that it can keep its unique identifier and its reputation, and malicious peers
can't get rid of his bad reputation by making a new identifier easily.
3.3
Monitor Design
When a client does something, such as downloading, uploading, reporting and
getting judgments, the RepServer where this client registered on will save the
information about these actions in a file corresponding to the client. We call this file
“report record file.”
The work of the Monitor is scanning the report record files to detect the possible
malicious behaviors at regular intervals. When someone is thought to misbehave,
the monitor only sets his alert-state to “Alert” of “Forbid” under some situations.
But if someone gets too many bad judgments, the Monitor will determine whether he
is punished or not. Anyone’s reputation goes down, if he is punished. The work of
Monitor will go through two phases: Check phase and Determine phase.
Figure 3-1. Flowchart of the Monitor
18
1.
Check phase
There are both 14 kinds of checking parameters for “Alert” and “Forbid” (all
kinds are show in P.29 Figure 4-11). In this phase, the Monitor checks whether the
action counts of each type exceeds the parameters in a period of time, and sets
alert-state of the clients. When the action counts exceed, the alert-state will be set to
‘A’ in “Alert”; the 14 corresponding arguments (fn) will set to 1 in “Forbid”, and we
can get a number fs = F-1*20 + F-2*21 + … + F-16*215. The alert-state will then be
set to “F-fs”. If there are no action counts exceeding, the alert-state will be set to 0.
2.
Determine phase
The Monitor will proceed to this phase, when someone’s alert-state is set. In
this situation, the Monitor is going to determine whether the giving judgments are real
or not, and whether the client is on the good behavior or bad behavior. We have
designed the determine mechanisms for alert-state F-9, F-12, F-13, F-14, F-15 and
F-16. The following shows some notations and how the Monitor determines each
alert-state.
Notations:
Cx: the client whose alert-state is set
Cg: the client gives Cx good judgment
Cb: the client gives Cx bad judgment
GTx: global trust of Cx, -1 ≤ GTx ≤ 1
NGTx: normalized global trust of Cx, 0 ≤ NGTx ≤ 1
avg_good_judgment = mean( ∑(NGTg) )
avg_bad_judgment = mean( ∑(NGTb) )
final_judge = avg_good_judgment - avg_bad_judgment
•
F-9: Cg gives too many good judgments to a specific file of Cx.
Figure 3-2. Flowchart of determine phase: F-9
19
•
F-12: Cb gives too many bad judgments to a specific file of Cx.
•
F-13: Cx gets too many good judgments.
•
F-14: Cx gets too many good judgments from Cg.
20
•
F-15: Cx gets too many bad judgments.
•
F-16: Cx gets too many bad judgments from Cb.
21
3.4
System Architecture
This section describes major components of our system. We briefly divide our
system into four parts: Message Processor, Monitor, GUI Interface and Information
Storage. The architecture is depicted in Figure 3-3.
Figure 3-8. System Architecture
The functionality of each component is roughly described as follows:
•
Message Processor
There are many kinds of messages in our system which can be divided into two
types: client-to-server message and server-to-server message. Client-to-server
messages include kinds of query messages and report messages.
Server-to-server messages include client registration notification, parameters
setup.
When a report message is processed, there is always a update in client’s
information and the trust calculator has to calculate the new trust at this time.
•
Monitor
As we describe in last section, the Monitor is used to monitor clients’ actions.
22
•
GUI Interface
The manager can conveniently look over clients’ data and monitor results with
the GUI interface. Besides, it is easy to change the system setting and monitor
parameters.
•
Information Storage
We use a database to store most information of the clients and the files are used
to store the detail information of clients’ actions, include download, upload,
report and get report.
23
Chaper 4 System Implementation & Experiments
4.1
System Implementation
The development environment of our system is:
Tool: J2SE 1.4.2, JXTA 2.3.3, and JXTA CMS 2.3.3
Database: MySQL 5.0
Platform: Windows XP
4.1.1
Information Storage
Information Storage of RepServer
Database Design
The database consists
client_registration table.
of
two
tables:
reputation_data
table
and
reputation_data table: used to store client’s information that registers at this server.
Each field describes in Table 4-1.
Table 4-1. Fields of reputation_data table
Id
Name
Alert
Monitor
Reputation
rep_rank
Judge
transaction_count
transaction_size
Report
bad_report
good_judgment
verybad_judgment
bad_judgment
reg_time
This is a unique ID created by JXTA.
Client can take a name, when he runs the JXTA
application for the first time.
Alert state
Indicate if monitor this client. 1: yes, 0: no.
Reputation value
Reputation rank
Judge
Total transaction count (upload)
Total transaction size (upload)
Counts of report (report)
Counts of bad report (report)
Counts of good judgment (get report)
Counts of very bad judgment (get report)
Counts of bad judgment (get report)
Register time
24
client_registration table: used to store all clients’ information in our system.
field describes in Table 4-2.
Each
Table 4-2. Fields of client_registration table
id
host_ip
mac_addr
This is a unique ID created by JXTA.
The IP of the server where this client registers on.
MAC address
Record File Design
There is a report record file named as the client’s JXTA ID for each client that
registers on this RepServer. The record file saves all actions of the client. Each
field describes in Table 4-3.
Table 4-3. Fields of report record file
type
monitor
time
id
cid
name
size/report
Action type of this entry. Four types: DL: download, UP:
upload, RP: report, GEREP: get report.
Indicate whether monitor this entry or not.
true: yes, false: no.
Action time
The id of the interactive client.
The content id of the file.
The name of the file.
If this entry is download type or upload type, this field
stores the size of the file.
Otherwise, this field stores the report type.
Information Storage of Client
Record File Design
There are two record files stored in the client: downloaded file and report file.
Downloaded file: this file records the information of the file that has finished
download but not report to RepServer yet. The entry will be removed if the client
reports it.
Report File: this file records what this client reports the status of the downloaded files,
and the transfer rate of last downloading.
25
4.1.2 Application Overview
Client application:
Phase 1.
Connect to RepServer
When a client starts to run the application, ha can connect to the server that he
registered to make sure whether the server is on-line and get his latest reputation
information. If this is his first time to use this application, he should select a server
to register on. If the server is off-line or even the client had not registered yet, he
can still search files and download. But then there is no any reputation information
about the searched files. Here is the screen shot:
Figure 4-1. Screen shot of “Connect”
Phase 2.
Search file
A client search files by sending query message (broadcast) contains the keyword.
While the wanted files are found, this client application will send query reputation
message to the RepServer to get the file owners’ reputation data automatically.
We can see how the application works at this phase in Figure 4-2. Cx had
registered on S1, so Cx will query S1 first when he needs any information. In fact,
the figure has still omitted two operations:
1.
Before step “3. Query Cy’s GT”, Cx will check if he has the registration
information about Cy. When he knows which server is Cy registered on,
he will send query message to the server directly.
26
2.
After step “No B4. Response Cy’s registered Server S2”, Cx will save this
information. Therefore, Cx can query Cy’s global trust from the right server
directly next time.
Figure 4-2. Query on multi-server
Here is the screen shot of the result of search file:
Figure 4-3. Screen shot of “Search file”
27
Phase 3.
Query report record from other peers
If the registered server of the file provider is off-line, the client can not get the
reputation information of the files. Then he can send query report records message
(broadcast) to collect report records of one of these file owners that are kept by other
clients. Here is the screen shot:
Figure 4-4. Screen shot of "Query report record from other peers”-1
Phase 4.
Download file
With the information that are queried from RepServer or other clients, this client
can make his own decision to select the file provider. Although our reputation is
constructed for evaluating which file provider is much believable on providing good
files, this client can still select the file provider with high transaction rate in the
information (Figure 4-5) or query the access history of the file (Figure 4-6).
Figure 4-5. Screen shot of "Query report record from other peers”-2
28
Figure 4-6. Screen shot of “Query the access history of the file"
Phase 5.
Report
After downloading, our application will keep the information of this
downloading. This client can report the quality of the downloaded file, while
RepServer is on-line (this client should connect to RepServer to enable the “Report”
function). We can see how the application works at this phase in Figure 4-7 and the
screen shot is shown in Figure 4-8.
Figure 4-7. Report on multi-server
Figure 4-8. Screen shot of “Report”
29
RepServer application:
The Manager can conveniently see the information of all clients with the GUI of
RepServer application. Here is the screen shot of main frame:
Figure 4-9. Screen shot of main frame
In the general situation, the manager only needs to adjust the monitor parameters
and pays attention to the monitor result. The manager should check the clients’
actions if there are “Alert” warnings or “Forbid” warnings. While some attacks are
found, the manager can punish the bad clients by give them some bad judgments to
reduce their reputation. Here are screen shots of monitor result and monitor
parameters setting (“Forbid” is the same with “Alert”):
Figure 4-10.
Screen shot of monitor result
30
Figure 4-11. Screen shot of monitor parameters setting
31
The Simple frameworks of our system are shown in Figure 4-12 and Figure 4-13.
Figure 4-12.
System framework of Server on-line
Figure 4-13.
System framework of Server off-line
32
4.2 Experiments
The goal of our reputation system is providing clients a guide to select the right
sources. The clients’ successful downloading rate can be one estimate of the
performance of the system. In this section, we will show some experiments how we
test our system.
Because we want to compare our performance with the result of the
Recommendation-based P2P trust model, we set the simulate experiment environment
under the same condition. List as follows:
•
A successful downloading means the client gets the right file he wants. The
client only adds the file after a successful downloading. Otherwise, the number
of files he owned will not increase.
•
There are two kinds of clients in the experiments, “Good clients” and “Bad
clients.” Good clients always provide right files, and report with correct
judgments. Bad clients always provide wrong files, and have some bad
behavior. According to their behavior, bad clients are divided into three kinds.
1.
2.
3.
A bad client provides wrong files only. The bad clients are this kind in our
Type-1 experiment.
A bad client will give a “bad” judgment to the client who provides him the
right file. The bad clients are this kind in our Type-2 experiment.
A bad client will give a “good” judgment to the client who even provides
him the wrong file. This situation can be regarded as a shilling attack.
The bad clients are this kind in our Type-3 experiment.
•
This is an ideal network, so that any client can find all files of all clients. A
client only tries to get the file he does not have yet, and he selects the file owner
who has the highest reputation to be the file provider.
•
There are 1,000 clients and 10,000 files which each file will be allotted to 10
clients in the simulate environment. Each file will be allotted to at least one
good client. Each client will complete 100 downloading, and the number of
total downloading times is 100,000.
33
Each experiment results as shown in later figures. Line “QS” represents the
clients query server to get reputation information, line “QP” represents the clients
query other clients to get reputation information, line “RB” is the result of
Recommendation-based P2P trust model, and line “QS-M” represents the Monitor is
active. The Monitor does not change the records saved in the clients, so there is no
line “QP-M.” The results we shown in this section totally set the clients’ coefficients
α and β are set to 1. The Monitor only determines F-13 and F-15 with the threshold
5, and it will act after every 5,000 downloadings. The experiment results which set
α and β are to 0.5 and 0 will put in the Appendix.
Successfuk Downloading Rate
QS
QP
RB
QS-M
100%
95%
90%
85%
80%
75%
10%
20%
30%
40%
50%
60%
70%
80%
90%
80%
90%
Bad Client Percentage
Figure 4-14.
Result of Type-1 experiment
Successful Downloading Rate
QS
QP
RB
QS-M
100%
95%
90%
85%
80%
75%
10%
20%
30%
40%
50%
60%
70%
Figure 4-15.
34
QS
QP
RB
QS-M
100%
90%
80%
70%
60%
50%
40%
10%
20%
30%
40%
50%
60%
70%
80%
90%
Figure 4-16.
Our system has a better performance then Recommendation-based P2P trust
model according to these experiment results. While any client downloads file once
from the bad clients, the bad clients’ will keep the worse reputation and no client will
select them as the file providers. Therefore, our system has an extreme good
performance in Type-1 experiment that all clients report correct judgments. In
Type-2 and Type-3 experiment, our system’s performance drops more and more
rapidly when bad client percentage exceeds 50%, because of the incorrect judgments
are more than correct judgments. But our Monitor works well in Type-3 experiment.
Then, we do the experiments with a different condition. Line “Best” represents
the clients select file providers highest reputation and the Monitor is not active, line
“BestM” represents the Monitor is active, line “0.8” represents that clients select the
file owner who has the reputation higher than 0.8 to be the file providers, line “0.8M”
represents the Monitor is active, line “0.5” represents that clients select the file owner
who has the reputation higher than 0.5 to be the file providers, and line “0.5M”
represents the Monitor is active. There are no any difference on the results of
Type-1 experiments. The results are shown in Figure 4-17, Figure 4-18 and Figure
4-19.
35
Best
BestM
0.8
0.8M
0.5
0.5M
100%
99%
98%
97%
96%
95%
10%
20%
30%
40%
50%
60%
70%
80%
90%
Figure 4-17.
Best
Compare selection the highest reputation, 0.8 and 0.5 in Type-1
BestM
0.8
0.8M
0.5
0.5M
100%
95%
90%
85%
80%
75%
10%
20%
30%
40%
50%
60%
70%
80%
90%
Bad Peer Percentage
Figure 4-18.
36
Best
BestM
0.8
0.8M
0.5
0.5M
1
0.9
0.8
0.7
0.6
0.5
0.4
0.3
10%
20%
30%
40%
50%
60%
70%
80%
90%
Figure 4-19.
We can observe that the results of “0.8” and “0.5” will have higher successful
downloading rate than “Best” in Type-2. In Type-3, the result of “0.8” is better than
“Best”, and the result of “0.8M” is nearly “BestM.”
37
In previous experiment, all clients are always on-line. Now, we want to test our
system in the variable network. “C50%” means each client has 50% of the chance to
be on-line and so on. Line “QSM” represents the Monitor is active. Because our
Monitor does not change the successful downloading rate in Type-1 and Type-2
experiments, we do not show the results with monitor any more.
QS C100%
QP C100%
QS C50%
QP C50%
QS C10%
QP C10%
100%
90%
80%
70%
60%
50%
40%
30%
20%
10%
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
Figure 4-20.
Result of Type-1 experiment with different variations
QS C100%
QP C100%
QS C50%
QP C50%
QS C10%
QP C10%
100%
90%
80%
70%
60%
50%
40%
30%
20%
10%
0%
10%
20%
30%
40%
50%
60%
70%
80%
Figure 4-21.
38
90%
QS C100%
QP C100%
QSM C100%
QS C50%
QP C50%
QSM C50%
QS C10%
QP C10%
QSM C10%
100%
90%
80%
70%
60%
50%
40%
30%
20%
10%
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
Figure 4-22.
The results are the same as our expectancy, the performance descends more
when lesser clients are on-line. Because it is more possible that there is no on-line
“good” file provider. The results also indicate that query server will have a bit better
performance than query other clients in a high variation network.
39
Chaper 5 Conclusions & Future Works
5.1
Conclusions
In summary, we have proposed some mechanisms to defend the attacks on the
reputation system and implemented the reputation system in P2P network. Our
system has a very nice performance which we can see in the experiments results while
the malicious clients are less that 50%. As our reputation system is based on clients’
feedbacks, the system will have a poor performance when most feedbacks (reports)
are incorrect. So we provide another mechanism “Monitor” to detect the malicious
behaviors. The manager can punish the malicious clients and remove the incorrect
judgments so that the reputations of the clients are more believable.
As we use the RepServer to maintain the reputation information and clients’
report record files, the server will eventually suffer the crash problem when the
number of clients exceeds its limit. To improve the scalability, we can extend the
RepServer to multi-servers in our system.
40
5.2
Future Works
There are some directions for further improvement:
1.
Even though our system has the “Monitor” mechanism, the application only
automatically restricts the client to report when his state is at some alert-states.
And the “Determine phase” does not works for all alert-states either. The
manager has to handle all the other “Alert” and “Forbid” situations. Designing
the methods for the other “Forbid” situations will make the application smarter,
and the manager can take less efforts on the monitor results.
2.
Our reputation system is built for clients to select good sources. We only use
the judgments to calculate the reputation of the clients. In fact, there are still
other kinds of information stored in the database like the transaction_size and
transaction_count, we can take these into our reputation calculation formula. It
is also an important issue that how to design the reputation system which makes
the clients have incentives to share the files.
41
References
[CDVPS 2002]
F. Cornelli, E. Damiani, S.C. Vimercati, S. Paraboschi and P.
Samarati. “Choosing Reputable Servents in a P2P Network.”
In 11th International Conference on World Wide Web, May 2002.
[CMS 2002]
JXTA Content Management System.
[DVPSV 2002]
E. Damiani, S.C. Vimercati, S. Paraboschi, P. Samarati and F.
Violante.
“A Reputation-Based Approach for Choosing
Reliable Resources in Peer-to-Peer Networks.” In ACM
Conference on Computer and Communications Security,
November 2002.
[DWJZ 2004]
W. Dou, H.N. Wang, Y. Jia and P. Zou.
“A
recommendation-based peer-to-peer trust model.” Journal of
Software, Vol.15, No.4 2004.
[eDonkey 2000]
eDonkey. URL: http://www.edonkey2000.com/
[eMule 2002]
eMule.
URL: http://www.emule-project.net/
[ezPeer]
ezPeer.
URL: http://www.ezpeer.com/
[FastTrack 2001]
FastTrack. URL: http://en.wikipedia.org/wiki/FastTrack/
[Fu 2003]
Y.F. Fu. An Implementation of a Peer-To-Peer Reputationbased Resources Sharing System. Master thesis in Department of
Information Management, National Taiwan University, 2003.
[GBM 2001]
P. Golle, K.L. Brown and I. Mironov. “Incentives for Sharing
in Peer-to-Peer Networks.” In Proceedings of the 3rd ACM
conference on Electronic Commerce, 2001.
[Gnutella 2000]
Gnutella. URL: http://www.gnutella.com/
[Hardin 1968]
Hardin. “The Tragedy of the Commons.” Science, Vol. 162.
no. 3859, pp. 1243 - 1248, December 1968.
[JXTA 2001]
Project JXTA. URL: http://www.jxta.org/
42
URL: http://cms.jxta.org/
[Kazaa 2002]
Kazaa.
URL: http://www.kazaa.com/us/index.htm
[Kuro]
Kuro.
[LL 2004]
Li Xiong and Ling Liu. “PeerTrust: Supporting ReputationBased Trust for Peer-to-Peer Electronic Communities.” IEEE
Transactions on Knowledge and Data Engineering, VOL. 16, NO.
7, JULY 2004.
[MF 2002]
A.G. Martinez and M. Feldman. GnuShare: Enforcing Sharing
in Gnutella-style Peer-to-Peer Networks.
University of
California at Berkeley, 2002.
[Napster 1999]
Napster.
[sig2dat 2002]
sig2dat spec. 2002.
[SR 2002]
T. Strufe and D. Reschke. “Efficient Content Distribution in
semi-decentralized Peer-to-Peer Networks.” In 8th Netties
Conference, September 2002.
[TWD 2004]
Y.B. Tang, H.M. Wang and W. Dou. “Trust Based Incentive in
P2P Network.” In Proceedings of the IEEE International
Conference on E-Commerce Technology for Dynamic E-Business,
2004.
[TS 2004]
S.A. Theotokis and D. Spinellis. “A survey of peer-to-peer
content distribution technologies.” ACM Computing Surveys,
36(4):335-371, December 2004.
[NWD 2003]
T.W.J. Ngan, D.S. Wallach, and P. Druschel. “Enforcing Fair
Sharing of Peer-to-Peer Resources.” In 2nd International
Workshop on Peer-to-Peer Systems, February 2003.
URL: http://www.kuro.com.tw/
URL: http://www.napster.com/
URL: http://www.geocities.com/vlaibb/
43
Appendix
Experiment(1)
Query Server Type-1
100%,
100%,
100%,
50%,
50%,
50%,
10%,
10%,
10%,
P-Bad
0
0.5
1
0
0.5
1
0
0.5
1
10%
0.92773
0.99949
0.99969
0.92637
0.99925
0.99925
0.91625
0.99772
0.99797
20%
0.86043
0.99915
0.99914
0.83967
0.99818
0.99831
0.82638
0.99351
0.9931
30%
0.79061
0.99857
0.99849
0.7478
0.99672
0.99664
0.73518
0.9864
0.98717
40%
0.70528
0.99767
0.99766
0.66411
0.99416
0.99442
0.6429
0.97422
0.97336
50%
0.60992
0.99659
0.99652
0.56566
0.98929
0.98903
0.55181
0.95061
0.95096
60%
0.52551
0.99554
0.99542
0.47394
0.97756
0.97732
0.44405
0.9071
0.91013
70%
0.40986
0.99424
0.99401
0.37305
0.94954
0.9496
0.3438
0.8412
0.8371
80%
0.31414
0.99284
0.99312
0.25994
0.88304
0.88642
0.24461
0.72777
0.72512
90%
0.18446
0.99233
0.99236
0.15337
0.74989
0.75099
0.13706
0.54668
0.54792
P-On,α
Query Server Type-2
100%,
100%,
100%,
50%,
50%,
50%,
10%,
10%,
10%,
P-Bad
0
0.5
1
0
0.5
1
0
0.5
1
10%
0.9318
0.999
0.999
0.9182
0.99891
0.99884
0.90959
0.99737
0.99749
20%
0.8505
0.998
0.998
0.82159
0.99723
0.99707
0.82065
0.99182
0.9926
30%
0.75717
0.99671
0.99667
0.73376
0.99375
0.99337
0.73059
0.98202
0.98229
40%
0.6612
0.99427
0.99391
0.63791
0.98482
0.98731
0.63238
0.96342
0.96649
50%
0.56026
0.98693
0.98486
0.53594
0.9721
0.97486
0.53482
0.93069
0.93917
60%
0.44041
0.96698
0.97337
0.42484
0.94252
0.95199
0.42144
0.87686
0.88837
70%
0.34043
0.93784
0.95671
0.3147
0.88928
0.91555
0.32004
0.79212
0.81148
80%
0.21981
0.85693
0.91763
0.20664
0.78316
0.82021
0.20494
0.64623
0.69143
90%
0.10887
0.62146
0.83043
0.10817
0.52186
0.64463
0.10038
0.41236
0.48342
P-On,α
Query Server Type-3
100%,
100%,
100%,
50%,
50%,
50%,
10%,
10%,
10%,
P-Bad
0
0.5
1
0
0.5
1
0
0.5
1
10%
0.89972
0.99952
0.99928
0.9021
0.99918
0.99906
0.9028
0.96304
0.96936
20%
0.7781
0.99756
0.99813
0.79031
0.9974
0.99762
0.79936
0.91979
0.93251
30%
0.67714
0.99668
0.99575
0.69464
0.99444
0.99439
0.69205
0.86574
0.87738
40%
0.54906
0.99132
0.99272
0.58031
0.99024
0.98984
0.57935
0.801
0.82041
50%
0.44049
0.98248
0.98605
0.47041
0.97877
0.97748
0.48113
0.71841
0.73571
60%
0.34135
0.95525
0.96226
0.36853
0.95452
0.95414
0.3748
0.62662
0.64332
70%
0.23665
0.90106
0.90709
0.26508
0.91919
0.91418
0.27986
0.51879
0.53754
80%
0.15296
0.78929
0.78872
0.16445
0.82838
0.811
0.17956
0.39666
0.40278
90%
0.07106
0.60776
0.61167
0.07707
0.4359
0.44296
0.08494
0.26652
0.25118
P-On,α
44
Query Peer Type-1
100%,
100%,
100%,
50%,
50%,
50%,
10%,
10%,
10%,
P-Bad
0
0.5
1
0
0.5
1
0
0.5
1
10%
0.93382
0.99954
0.99954
0.92365
0.99885
0.99874
0.91075
0.95568
0.95571
20%
0.8558
0.99914
0.99913
0.84003
0.99673
0.99701
0.81876
0.90361
0.90494
30%
0.78483
0.99863
0.99862
0.75577
0.99466
0.99443
0.72939
0.84399
0.84349
40%
0.69984
0.99787
0.99762
0.66812
0.99067
0.99123
0.62667
0.77171
0.77529
50%
0.61437
0.99641
0.99676
0.57334
0.98326
0.98316
0.53176
0.69092
0.6931
60%
0.51851
0.99547
0.99524
0.46848
0.96825
0.96814
0.43474
0.60222
0.5999
70%
0.41194
0.99379
0.99408
0.36955
0.93452
0.93706
0.3386
0.49742
0.49243
80%
0.30118
0.99294
0.99311
0.25968
0.86891
0.86923
0.23344
0.38503
0.38022
90%
0.18388
0.99223
0.99254
0.14291
0.73354
0.73452
0.12515
0.25183
0.25026
P-On,β
Query Peer Type-2
100%,
100%,
100%,
50%,
50%,
50%,
10%,
10%,
10%,
P-Bad
0
0.5
1
0
0.5
1
0
0.5
1
10%
0.92816
0.999
0.999
0.9211
0.99439
0.99389
0.90863
0.95315
0.95395
20%
0.84216
0.998
0.998
0.8339
0.98748
0.98687
0.81976
0.89947
0.89752
30%
0.76067
0.99698
0.997
0.73848
0.97974
0.97928
0.72029
0.8304
0.83563
40%
0.67138
0.99342
0.99416
0.63769
0.97025
0.97007
0.61987
0.75402
0.75871
50%
0.55803
0.9833
0.98553
0.5424
0.95683
0.95845
0.52793
0.66362
0.66917
60%
0.4396
0.97027
0.97371
0.42599
0.93236
0.93932
0.42537
0.56365
0.56807
70%
0.33211
0.938
0.95696
0.32202
0.88154
0.89928
0.32531
0.44403
0.45771
80%
0.22157
0.85656
0.90769
0.21471
0.77
0.81632
0.22335
0.32068
0.3261
90%
0.10323
0.60867
0.80251
0.10482
0.52508
0.63603
0.1164
0.1734
0.18391
P-On,β
Query Peer Type-3
P-On, β
100%,
100%,
100%,
50%,
50%,
50%,
10%,
10%,
10%,
P-Bad
0
0.5
1
0
0.5
1
0
0.5
1
10%
0.92773
0.99938
0.99959
0.91818
0.99781
0.99801
0.90801
0.95462
0.95693
20%
0.8433
0.99819
0.99834
0.8349
0.99398
0.99355
0.81813
0.89818
0.89913
30%
0.75306
0.99602
0.99667
0.73659
0.98679
0.98495
0.72059
0.83306
0.83069
40%
0.6465
0.99217
0.99421
0.63841
0.96875
0.96952
0.62635
0.75228
0.75273
50%
0.54933
0.98427
0.98817
0.53825
0.94965
0.94589
0.52901
0.65802
0.6644
60%
0.43442
0.97721
0.9767
0.4276
0.90719
0.90907
0.4259
0.55443
0.55707
70%
0.33652
0.90034
0.90558
0.32205
0.83711
0.82215
0.32956
0.43693
0.44114
80%
0.21763
0.7778
0.78813
0.21692
0.70665
0.69198
0.22521
0.31078
0.30511
90%
0.11545
0.6078
0.6012
0.11447
0.46675
0.43868
0.11757
0.16284
0.16406
According to the experiment results, the clients will get the worst successful
downloading rate when they set α, β to 0, because they have to downloading from all
other clients themselves to know whether they are good providers or not. The
successful downloading rate with α,β set to 0.5 and 1 are close.
45
Experiment(2)
Query Server with α = 1, peer on-line 100%
Type-1
10%
20%
30%
40%
50%
60%
70%
80%
90%
Best
0.99949
0.99915
0.99857
0.99767
0.99659
0.99554
0.99424
0.99284
0.99233
BestM
0.99969
0.99914
0.99849
0.99766
0.99652
0.99542
0.99401
0.99312
0.99236
0.8
0.99954
0.99914
0.99863
0.99787
0.99641
0.99547
0.99379
0.99294
0.99223
0.8M
0.99954
0.99913
0.99862
0.99762
0.99676
0.99524
0.99408
0.99311
0.99254
0.5
0.99967
0.99915
0.99843
0.99762
0.99651
0.99543
0.99403
0.99314
0.99239
0.5M
0.99956
0.99912
0.99843
0.99767
0.99645
0.99544
0.99375
0.99284
0.99224
30%
40%
50%
60%
70%
80%
90%
Type-2
10%
20%
Best
0.99949
0.99866
0.99721
0.99432
0.98668
0.97533
0.95059
0.91267
0.80885
BestM
0.99955
0.99911
0.99785
0.99388
0.98707
0.97455
0.95273
0.92549
0.81119
0.8
0.99963
0.99894
0.99808
0.996
0.99133
0.98497
0.97366
0.95879
0.92635
0.8M
0.9995
0.99896
0.99791
0.99583
0.99158
0.98466
0.9746
0.95823
0.92303
0.5
0.99953
0.99898
0.99783
0.99551
0.99117
0.98486
0.97429
0.95677
0.92617
0.5M
0.99962
0.99895
0.99801
0.99544
0.99081
0.98533
0.9735
0.95552
0.93045
Type-3
10%
20%
30%
40%
50%
60%
70%
80%
90%
Best
0.99945
0.99901
0.99686
0.99317
0.98512
0.96226
0.90709
0.78872
0.61167
BestM
0.99957
0.99877
0.99814
0.99585
0.99204
0.985835
0.97892
0.972348
0.960673
0.8
0.99958
0.9989
0.99756
0.9964
0.99112
0.98169
0.960545
0.893012
0.755063
0.9996
0.9989
0.99801
0.99594
0.99321
0.988275
0.98243
0.976957
0.964844
0.5
0.99956
0.99906
0.99769
0.99515
0.98927
0.97969
0.939035
0.777838
0.366346
0.5M
0.99948
0.99899
0.99744
0.9963
0.99307
0.98814
0.98132
0.971947
0.947006
0.8M
There is no difference between the client selects the file owner who has the
reputation higher than 0.8 and 0.5 in Type-2 experiments. Because the malicious
client is always at the lowest reputation which is not exceeding 0.8 or 0.5. The client
selects the file owner with lower reputation will get a worse successful downloading
rate in Type-3. But we observe that the Monitor still makes a better efficiency in this
case.
46

李秀惠博士點對點網路檔案分享之可靠聲譽

Transcription

Similar documents

bearshare kazaa edonkey

View Sample PDF

An Online Gaming Testbed for Peer-to

ENVINET as - Czech Industry for ITER

Presentation

Trust problem

View

Reputational crises in Peru

P2P Gnutella analysis

Dynamic Regional Carbon Budget Based on Multi

李秀惠 博士 點對點網路檔案分享之可靠聲譽

Transcription

Similar documents

李秀惠博士點對點網路檔案分享之可靠聲譽