P2P網路架構下開放式數位商店平台之研究(2/2)

行政院國家科學委員會專題研究計畫 成果報告

P2P 網路架構下開放式數位商店平台之研究(2/2)

研究成果報告(完整版)

計 畫 類 別 ： 個別型 計 畫 編 號 ： NSC 95-2221-E-002-073- 執 行 期 間 ： 95 年 08 月 01 日至 96 年 07 月 31 日 執 行 單 位 ： 國立臺灣大學資訊工程學系暨研究所 計 畫 主 持 人 ： 李秀惠 計畫參與人員： 碩士班研究生-兼任助理：游曜徽、邱建霖 處 理 方 式 ： 本計畫可公開查詢

中 華 民 國 96 年 10 月 15 日

行政院國家科學委員會補助專題研究計畫 - 成果報告

P2P 網路架構下開放式數位商店平台之研究(2/2)

計畫類別：■ 個別型計畫 □ 整合型計畫

計畫編號：NSC 95－2221－E－002－073

執行期間：2006 年 8 月 1 日至 2007 年 7 月 31 日

計畫主持人：李秀惠

計畫參與人員：游曜徽、邱建霖

執行單位：國立台灣大學資訊工程學系

中 華 民 國 96 年 10 月 2 日

Table of Contents

Table of Contents... 2 List of Figures ... 3 Abstract... 4 1. Motivation... 5 2. Objective ... 5 3. Background... 6 3.1 JXTA Project ... 6 3.2 JXTA CMS ... 8 4. System architecture... 8

4.1 The framework of our system ... 8

4.2 System usage and it’s working flow... 10

4.3 Architecture of our system... 13

5. Peer-to-peer trading application... 15

6. Conclusions ... 19

7. 參考文獻... 19

List of Figures

Figure 1 Our research flow... 6

Figure 2 JXTA virtual network... 7

Figure 3 JXTA architecture... 7

Figure 4 An example of content advertisement. ... 8

Figure 5 The framework of our service... 9

Figure 6 Content distribution life cycle... 11

Figure 7 Screen shot of the distribution manager. ... 12

Figure 8 Dialog for modify REMOTE POLICY. ... 12

Figure 9 An example of content group. ... 13

Figure 10 Distribution Access Control Service in JXTA services layer... 13

Figure 11 System architecture... 14

Figure 12 Adding new custom property... 16

Figure 13 Setting value of custom property. ... 16

Figure 14 An extended architecture after adding the “Price” property. ... 18

Abstract

【中文】 點對點網路架構是一種讓大部份的溝通直接在網路上的每一個節點與節點之間直接進 行，而不使用中央伺服器的一種網路架構。在傳統的點對點網路環境下，一旦內容提供者 分享其數位內容於點對點網路後，對於其所提供的內容便失去了控制，並且其內容可由點 對點網路上的任一節點隨意的存取或散佈。本研究將提出一個機制，使得內容提供者可以 在其所提供的數位內容散佈出去之後，還能夠對其內容的散佈保有某些合理的控制與管 理。本系統建置於 JXTA 點對點協定之上，並將內容散佈控管的功能實作成 JXTA 協定的 一個服務。藉由使用這個服務，內容提供者不僅能夠很便利的控制與管理其內容的散佈， 亦能夠很輕易地延伸此系統來達到其獨特的應用。最後我們延伸此服務設計並實作一個適合 數位商品在點對點網路下交易的平台。值得注意的是我們的系統將著重於對數位內容於點對點 網路散佈期間的控管，而不是對使用者取得數位內容之後的行為控制。 關鍵詞： 點對點網路(P2P)，智慧財產權，數位版權管理 (DRM) 【英文】

A peer-to-peer (P2P) network architecture is a network that does not use a central server for communication but instead uses mostly connections between clients directly. In traditional peer-to-peer networks, once the content provider releases his digital content, the content is out of his control, and can be accessed or distributed by any other peers arbitrarily in the peer-to-peer network. This research will introduce a system that helps the content providers give some reasonable control about their own content distributions after their contents have been released. This system is based on JXTA protocol, and the control & management functionalities are implemented as a service in JXTA-based peer-to-peer network. By using our service, the content providers can not only control and manage the distribution of his contents conveniently, but also extend our service easily to do his own special application. In the end of this study, we will extend our service to present a system that are suitable for selling digital goods based on peer-to-peer architecture. – An Open P2P Digital Store. Our system will focus on how the digital goods can be distributed securely in peer-to-peer network, and the management of these digital goods, rather than the usage control after user obtaining the digital goods.

Keywords: Peer-to-Peer Network (P2P), Intellectual Property Rights, Digital Right Management (DRM)

1. Motivation

In recent years, peer-to-peer networks gain more attractions from people. In contrast to traditional client/server architecture, peer-to-peer systems reveal some advantages [3, 4, 9], including:

(A) Disperse the loading of the server to many peers; so that digital contents can be distributed without a centralized server, hence the cost of the central server can be reduced.

(B) Fast content distribution. By the nature of peer-to-peer networks, it provides a fast channel for content distribution.

(C) The bandwidth of all clients can be used. In traditional client/server architecture, the bandwidth available of a server is in inverse proportion to the number of its clients, this causes slower data transfer, so the peer-to-peer architecture can fully utilize the bandwidth of all peers from network.

(D) Better fault tolerance. In traditional client/server architecture, once the server is dead, all services will be unavailable, but in peer-to-peer networks, the lost of one node will not bring serious effect to the entire network.

(E) Heterogeneous hardware and software resources can participate together autonomously. Current personal computers even have stronger computation power than elder mainframe system, so peer-to-peer networks can be helpful to make full use of all computation devices around the worlds.

An important fact is that all contents have been shared on peer-to-peer networks can be accessed and distributed without any restriction. The problem is that not all contents should be accessed or distributed by anyone on peer-to-peer networks without any restriction, and the original content providers should reserve some rights to determine how their contents can be distributed on peer-to-peer networks [1, 2, 12].

This study will focus on this problem; we hope that the content provider will be able to give his own contents some reasonable control after his contents have been released on peer-to-peer networks.

2. Objective

server, so it’s easy to control and manage how the services can be provided. But in a pure peer-to-peer architecture, with the lacking of a centralized server, it’s not easy to control the distribution behavior of contents in peer-to-peer networks. Our system will combine the advantages of these two architectures, we will use a lot of distributed nodes to control and manage the content distributions, and the content transfer action is still performed directly between peer and peer. The goal of this research is to provide a service that helps the content providers to control and manage the distribution process of their own contents in peer-to-peer environment. We also provide a server side management utility for content providers to manage their contents conveniently and easily. The content providers can also extend our system easily to fit their specialized control requirement about their own contents.

The flow of this research is shown in Figure 1.

Figure 1 Our research flow.

3. Background

3.1 JXTA Project

JXTA (abbreviation of “Juxtapose”) is a set of open peer-to-peer protocol promoted by Sun Microsystems [5, 11, 13, 14], it allows allow any connected devices 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, depicted in Figure 2.

Figure 2 JXTA virtual network.

The architecture of JXTA can be divided into three layers, shown in Figure 3.

Figure 3 JXTA architecture.

Each layer builds on the capabilities of the layer below, and will be explained as follows:

(A) JXTA Core layer (Platform layer): The core layer provides the elements that are

absolutely essential to every P2P solution, including discovery, transport (firewall handling), the creation of peers and peer groups, and associated security primitives.

(B) JXTA Services layer: The services layer provides those network services that are desirable but not necessarily a part of every P2P solution. The network services may be searching resources, file sharing, or distributed file system, etc.

(C) JXTA Applications layer: The applications layer builds on the capabilities of the services

layer to provide the common P2P applications, such as P2P instant messaging, P2P conference system, etc.

3.2 JXTA CMS

The Content Management Service (CMS) is a JXTA service that supports the sharing and retrieval of content within a peer group.[7] The CMS manages the shared content for a local peer, and allows applications to browse and download content from remote peers. The shared content was represented by an advertisement. The content advertisement contains some meta-information describing the content, including the content name, length, mime type, id, and description. Only content name and id are necessary to describe a content, others are optional. Figure 4 is an example of a content advertisement:

Figure 4 An example of content advertisement.

4. System architecture

4.1 The framework of our system

We can see that different network topologies will affect the degree of difficulty on deploying distribution access control. We want to retain both advantages from centralized architecture and decentralized architecture, and minimize the disadvantages as more as possible. We choose JXTA as our peer-to-peer infrastructure. The topology of JXTA is between pure peer-to-peer architecture and hierarchical architecture. We will mix the centralized and decentralized control mechanism with decentralized distribution to build a distribution access control service.

In our architecture, a new component called “Distribution Manager” is introduced; this kind of node is responsible for maintaining all content distribution information and controls the content distribution behavior. The only requirement for content providers to use this service is that they must burden the cost of managing content distribution. This means in our architecture there will be a lot of distribution managers on peer-to-peer network, in proportion to the numbers of content providers. The distributed managers are our key to control the content distribution process. Figure 5 shows the framework of our service.

Figure 5 The framework of our service.

We will associate each content with two kinds of policies: LOCAL POLICY and REMOTE POLICY. The definition of POLICY in our system is described as follows:

A POLICY of one content is a set of properties defined by its content provider. The combination of these properties will determine whether one content access request should be granted. If all properties of a POLICY are satisfied, the request will be granted, otherwise the request will be rejected.

The LOCAL POLICY is binding with the content before the content can be distributed on network, and will be distributed with the content anywhere; the REMOTE POLICY is located at the distribution manager, and can be changed by the content provider at any time. Whenever a access request of one content has been made, the peer providing the content will try to find the distribution manager of the requested content first, if the distribution manager is online and connected successfully, then the REMOTE POLICY is applied for this access request, the distribution manager will evaluate all properties in REMOTE POLICY and determine whether this access request can be granted based on the current conditions; if the content manager has no respond, the LOCAL POLICY will be applied, the content providing peer will determine whether this access request should be granted itself by evaluate all properties in LOCAL POLICY.

Two basic assumptions of our distribution access control service are:

(A) We ignore all copyright piracy problems. That is, we assume that the person who provides the content is also the content’s owner. Our system is focus on the access control over the distribution processes, not to control how user will use the content he has acquired. The usage controls about digital content are addressed by Digital-Rights Management systems [6, 10].

(B) Anyone who has obtained the content successfully will not share the unprotected content to other peers if he is not the original content provider; or any content will require being in a protected format before it can be shared on peer-to-peer network. In our architecture at least one of these two conditions must be satisfied. The purpose these two conditions is an assumption of keeps the honest people honest.

By default our service will require all contents being in an encapsulated format before they can be shared on peer-to-peer network. After one download process is complete, the content will be extracted to original one automatically. This action is transparently to any peer.

The architecture of our system is trying to make a balance between centralized and decentralized architectures. Note that in our architecture, the distribution manager will still suffer from the scalability problem. When the numbers of requests about the contents managed by the same distribution manager become large, the distribution manager will eventually crash, but the effects may not serious. In hybrid architecture, the failure of the central index server will crash all services of entire network. But in our architecture, the failure of one distribution manager will only crash the file sharing of the content managed by this manager. An important thing is that the peer-to-peer network is not dedicated to file sharing only, some other applications like instant messaging, distribute computing will still working properly, so the failure of one distribution manager will only affect a small portion of services on network.

As mentioned, we hope to give the content provider some reasonable control after his content was distributed in peer-to-peer network, which means unlike traditional content distribution in peer-to-peer environment, all content distribution must be performed conditionally instead of arbitrarily.

The distribution of one content is controlled by the LOCAL POLICY or REMOTE POLICY associated with this content. In our system, the properties in LOCAL POLICY are predefined and cannot be changed. The REMOTE POLICY has a set of predefined properties, and the content provider can also add his own new properties.

4.2 System usage and it’s working flow

The functionalities of our service are divided into three parts: Distribution access control, Content distribution policy management, and Auxiliary functionality.

(A) Distribution access control

In our system, the life cycle of one content distribution will go through three phases: Registration phase, Distribution phase, and Destruction phase, as shown in Figure 6.

Figure 6 Content distribution life cycle.

(B) Content distribution policy management

The distribution manager provides user-friendly interface for content provider to manage the distribution policies of his own content. Figure 7 is a screen shot of the management interface. The main goal of the distribution manager is to provide an easy way for content providers to define, modify and manage the distribution rules about their own content. Our system allows the content provider to change their content distribution policy dynamically at any time. In this figure, all registered content will be list in a table in the right side of the window, and the content provider can select and edit the values of properties in REMOTE POLICY of his content, a screen shot of modifying properties in REMOTE POLICY is shown in Figure 8. Once the values of properties in REMOTE POLICY changed, the distribution behavior of associated content will be changed immediately.

Figure 7 Screen shot of the distribution manager.

Figure 8 Dialog for modify REMOTE POLICY.

We use the group-based access control for policy management. In contrast to role-based access control [8] used by many rights management systems, we have no idea about who will access our content in peer-to-peer environment, so we choose to group the contents that have similar distribution policies. The following figure shows an example of grouped content:

Figure 9 An example of content group.

All contents belong to the same group will apply the same REMOTE POLICY. Any changes made to a content group's distribution policy will automatically be inherited by all contents of that group, and when one content joins a content group will automatically apply the distribution policy of this content group. A content group can have subgroups. A subgroup will inherit the policy of its parent, and one content can only belong to a unique content group.

(C) Auxiliary functionality

We have some auxiliary functionalities provided by the distribution manager, including quality control, monitor, and statistics utility.

4.3 Architecture of our system

Our system is implemented as a service in JXTA Services layer, depicted in Figure 10.

The architecture of our content distribution access control & management service is depicted in Figure 11.

Figure 11 System architecture.

This system can be roughly divided into five parts: Plug-In, Secure, Distribution Manager, Content information Database, and Control Protocol. The functionality of each component will be explained briefly as follows:

(A) Plug-In

The Plug-In part contains the part that will be installed in the original CMS service.

(B) Secure

The Secure part is responsible for providing a secure distribution over the peer-to-peer network. The Content Encapsulation/Extraction module provides the capability to encapsulate the plain content to a protected format or extract the protected content to original one, as well as license modification, encapsulation, etc.

(C) Distribution Manager

This part is used by content provider. The interface provided by manger will allow the content provider to control and manage their content distribution easily; hence the content provider can share the content in the way he wants.

(D) Content information Database

This part is used by distribution manager to store all information about their associated content, including policies, events, and statistics.

(E) Control Protocol

All communications between peers and peers or between peers and managers are through our designated control protocol, the details can be found in Appendix.

5. Peer-to-peer trading application

Peer-to-peer networks facilitate and speed up digital information dissemination, but due to the abuse use of it, it almost becomes free heavens for pirated content. Take the music industry as an example, as a result of the emergence of digital music format (e.g. MP3 format) and peer-to-peer networks, the digital music being shared on peer-to-peer networks without any limitation, making music companies suffered from copyright infringement. In spite of peer-to-peer networks do harm to intellectual property rights; many companies still show their intentions to use peer-to-peer networks as one of their ways to sell their digital goods. The main reason that many companies prefer peer-to-peer architecture to traditional client/server architecture is its efficiency of information dissemination, accessibility, fault-tolerance, and low cost.

The most on-line business models today are still in client-server architecture. To achieve successful peer-to-peer on-line business, it’s important to have a good digital-right management system and distribution access control mechanism. Our service provides a distribution access control facility for peer-to-peer trading. The following example shows how to extend our service to become a trading system. This is just a sample application to demonstrate the idea of applying our service.

As mentioned before, our service provides a few basic properties in REMOTE POLICY. To add new properties, the content provider needs to follow two steps: add a new property and define how this property will be evaluated.

To achieve step 1 is very easy. To sell digital goods in peer-to-peer environment, the content provider may need to define the price of each content. The content provider can do this by just typing the property name in a text file in the directory of distribution manager. For example: in file “property.ini”:

Each line contains a new property to be added. In this sample we only add the first property. Once the “Price” property has been added in property.ini, the distribution manager will add this property in REMOTE POLICY for all content as shown in Figure 12.

Figure 12 Adding new custom property.

Initially, the values of new added property are null, the content provider can set these values by click the edit button:

As we can see in Figure 13, a new property appears below the horizontal line. The properties upon this line are basic properties provided by our service; below are new custom properties. After these values have been set, we will go to step 2: to define how this property will be evaluated.

We require the content provider to write one function whenever he adds one custom property. The general usage of our distribution manager by the content provider may looks like following code segment:

import net.jxta.DCS.Secure.Server.DistributionManager …

…

// create an instance of Distribution Manager

DistributionManager manager = new DistributionManager();

The content provider must create an instance of DistributionManager. To define how his custom property will be evaluated, he must implement one interface for every custom property:

public interface EvaluationListener {

public boolean evaluationFunction(String content_id, String content_name, String local_peer_name,

String request_peer_name, String peer_ip_address, Hashtable customPropertyMap);

}

This interface contains only one method: public boolean evaluationFunction (…); This method is used to evaluate the custom property; all arguments of this method are provided by DistributionManager for content provider to use. The function returns a boolean value to indicate whether the evaluation is succeeded or failed. For example, the content provider may define this function to check his accounts database to determine whether the requesting peer has enough balance in its account, if the balance is not enough, the evaluation will fail, and this access request will be rejected.

The code segment of adding the evaluation function may like this:

// create an instance of Distribution Manager

DistributionManager manager = new DistributionManager();

manager.getProperty("Price").add EvaluationListener(new PriceEvaluationListener());

The class PriceEvaluationListener is an implementation of the EvaluationListener, and the evaluationFunction will check the requesting peer name and account to determine whether this peer has enough balance in account (For simplicity we assume that each peer has to register an account to content provider in advance and its account ID is peer name).

The architecture of our sample application is shown in Figure 14:

Figure 14 An extended architecture after adding the “Price” property.

In our sample application, as long as requesting peer has enough balance in its account, this request will be granted and its balance will be decreased by the price of the content it requests. The simplified procedure diagram is shown in following figure:

6. Conclusions

In summary, we have proposed a mechanism for content distribution access control in peer-to-peer environment. Our service requires the content provider to burden the cost of managing content distribution. It’s based on pure peer-to-peer architecture with centralized policy management; it’s a balance between fully centralized architecture and fully distributed architecture, and retains most advantages from both of them. The features of this system are effective, efficient, fault tolerant, low cost, flexible, and multiple requests supported.

Our system is implemented as a service in JXTA-based peer-to-peer network, and providing an infrastructure for content provider to control the distribution process about their own contents. The management interface provided by the distribution manager enables the content providers to change the distribution policies of their contents dynamically. We use group-based content management to help the content providers manage their content policies easily. Our service provides an easy way for content providers to extend to different applications, and one example of trading application was demonstrated. Our service is especially suitable for group sharing rather than world-wide sharing.

The digital rights management systems usually focus on how to restrict the usage of content in one machine or in one application, but our content distribution control service focus on access control between machine and machine. Our service can act as an auxiliary segment in integrating peer-to-peer networks with digital right management systems.

7. 參考文獻

[1] E. Anderson and Jun Li, "Cooperative policy control for peer-to-peer data distribution,". New Security Paradigms Workshop (NSPW), Nova Scotia, Sept 2004.

[2] S. Androutsellis-Theotokis and D. Spinellis, “A survey of peer-to-peer content distribution technologies,” ACM Computing Surveys (CSUR), 36(4):335 – 371, December 2004.

[3] H. Balakrishnan, M. F. Kaashoek, D. Karger, R. Morris, and I. Stoica , ”Looking Up Data in P2P Systems,”. Communications of the ACM, February 2003.

[5] D. Brookshier, D. Govoni, and N. Krishnan. Sams. “JXTA: Java P2P Programming,”. 2002.

[6] I. Clarke, O. Sandberg, B. Wiley, and T. W. Hong, "Freenet: A distributed anonymous information storage and retrieval system,". Lecture Notes in Computer Science, No. 2009, pp. 46-66. 2001.

URL: http://freenet.sourceforge.net.

[7] JXTA Content Management System. URL: http://cms.jxta.org/

[8] D. Ferraiolo, R. Sandhu, S. Gavrila, R. Kuhn and R. Chandramouli, “A Proposed Standard for Role-Based Access Control,”. ACM Transactions on Information and System Security, Volume 4, Number 3, August 2001.

[9] Gnutella. URL: http://www.gnutella.com/

[10] Carl A.Gunter, Stephen T. Weeks, and Andrew K. Wright, “Models and Languages for Digital Rights,”. In Proceedings of the 34th Annual Hawaii International Conference on

System Sciences. 2001.

[11] E. Halepovic, R. Deters, “The Costs of Using JXTA,”. University of Saskatchewan. In

Proceedings of the Third International Conference on Peer-to-Peer Computing (P2P’03).

[12] T. Iwata, T. Abe, K. Ueda, and H. Sunaga, “A DRM system suitable for P2P content delivery and the study on its implementation,”. In Proceedings of The 9th Asia-Pacific

Conference on Communications, APCC 2003, Volume 2, 21-24 Sept. 2003, pp. 806-811.

[13] “JXTA” by Brendon J. Wilson, Brendon J. Wilson. 2002. URL: http://www.brendonwilson.com/projects/jxta/

[14] Project JXTA. URL: http://www.jxta.org/

8. 計畫成果自評

本計劃已完成下列幾項工作： (A) 做整體架構規劃

包含系統角色定位, 該有哪些功能 ，需要哪些 layer，每個 layer 之間要如何 cowork。 (B) 定義系統規格

包含每個 layer 之中要有哪些 component，每個 component 之中要有哪些 functionality。 (C) 實作系統雛型

包含研究 JXTA platform 並修改 JXTA Content Management Service，實作 DRM-enabled CMS) 。

(D) 實作出一個試驗性系統，提供完整 API，讓 P2P 應用程式開發者(based on JXTA)能夠加 以利用，使其 P2P 應用程式能夠很容易的參與以及使用 P2P 數位商店。朝向開發一個 open and free 的平台，讓數位商品能夠以 P2P 的型式來交易。

本研究之內容與原計畫極為相符，並已達成預期目標，研究成果的學術或應用價值頗 高，亦極適合在學術期刊發表。