SOLUTIONS FOR ENABLING COMMUNICATION BETWEEN

DIFFERENT PROPRIETARY PEER-TO-PEER SYSTEMS

Renjie Pi, Junjie Tong and Ke Xu

Beijing University of Posts and Telecommunications, Beijing, P.R. China

Keywords: Peer-to-peer systems, Service-oriented architecture, Network storage.

Abstract: The Streaming traffic is one of the fastest growing traffic on the internet. Although the streaming traffic is

growing fast, the peer-to-peer systems have solved this problem as its scalability and its fault tolerance

against failures of centralized infrastructures. But because of the enormous growth in the number of peer-to-

peer applications in recent years, they have occupied the most bandwidth of the internet, and it’s essential

to integrate them into the global content delivery infrastructure. In this paper, we propose two solutions for

communicating between different proprietary peer-to-peer systems. One solution is to add a logical layer

for enabling the communications between the existing peer-to-peer systems, while the other one is a

service-oriented architecture by using the integrated network storage.

1 INTRODUCTION

The effectiveness of using the P2P technology for

content distribution has been proven by many

deployed systems (Emule; PPlive; PPStream; CNTV;

Coben, 2003). These P2P systems offer three major

types service for the end users. One type of service

is P2P file downloading, for example implemented

by Emule (Emule) and BitTorrent (Coben, 2003).

When a peer is downloading a file, it can get certain

part of the file from the other peers which are

downloading the same file from the content provider

server. And the server load is significantly reduced.

The peers may experience different downloading

rates, often depending on how much they are able to

contribute to the whole overlay network and the

corresponding mechanism in the P2P system. The

second type is P2P live streaming, for example

implemented by PPlive (PPlive) and CBox (CNTV).

In a live streaming session, a live video content is

disseminated to all users in realtime and the video

playbacks on all users are synchronized. There many

different overlay structures for implementing this

service including Tree-based structure and Mesh-

based structure. Tree-based structure includes the

single-tree streaming and multi-tree streaming (Liu

et al., 2008). The third type is P2P video-on-demand

(P2P-VoD). In this service, contents are also

delivered by streaming, but peers can watch

different parts of a video at the same time, hence

diluting their ability to help each other and offload

the server. This service needs the peers contribute a

small amount storage to offer the data for other

peers with a sophisticated distributed scheduling

mechanism for directing peers to help each other in

real time (Huang et al., 2008).

The P2P technology can be utilized in designing

highly scalable and robust applications at low cost,

compared with traditional client-server paradigms.

But as the number of the P2P systems increases

dramatically, some problems are coming up. The

first particular problem is the substantial stress that

the P2P systems place on the network infrastructure

and the users. As the increasing traffic on the

internet place too much load on the overlay, the

other users on the internet have to suffer the

increasing delay time and low performance. And the

users have to install the different software to watch

the content. The second problem is that more

participants beyond traditional P2P streaming

vendors are joining the efforts in the development of

P2P streaming systems. Some of these additional

participants include infrastructure vendors as

Akamai, ChinaCache, and ISPs. That is, the P2P

streaming ecosystem is becoming an increasing

diverse industry with participants from the source,

infrastructure, delivery and local P2P distribution to

the terminals (Zhang et al.). The third problem is the

580

Pi R., Tong J. and Xu K..

SOLUTIONS FOR ENABLING COMMUNICATION BETWEEN DIFFERENT PROPRIETARY PEER-TO-PEER SYSTEMS.

DOI: 10.5220/0003590905800585

In Proceedings of the 13th International Conference on Enterprise Information Systems (SSE-2011), pages 580-585

ISBN: 978-989-8425-53-9

 2011 SCITEPRESS (Science and Technology Publications, Lda.)

proprietary P2P streaming systems using different

streaming protocols and it’s hard for a peer

communicating with the other peers located in the

other P2P overlay to save the bandwidth, the storage

resource and computing resource.

To solve the above problems, in this paper, we

propose two solutions. The first solution is oriented

for enabling the peers in different proprietary P2P

systems to communicate with each other aiming for

accessing the data. By using this solution, it adds a

logical layer in the existing P2P systems. And the

other solution proposes a service-oriented

architecture for developing the P2P systems

avoiding the above problems. And this architecture

has using the network storage for storing the

contents which brings the architecture some new

features.

In the following sections, we will first introduce

the two solutions and then we will outlook the future

solution for the P2P systems which interacts with

cloud storage and cloud computing.

2 THE ADDITIONAL LAYER

In this section, we descript the additional layer to the

existing P2P systems mentioned in the first solution.

We mainly define its location in the P2P systems, its

inner construction and its functions. But before that,

we first have to define the preconditions of adding

this layer.

2.1 Preconditions

Before implementing the additional layer, there have

to be some preconditions to be described first. The

entities including in a specific P2P system will be

defined as below.

The peer: A peer is an end user on which

processing the P2P system and not only receives

contents and streaming, but also stores and uploads

contents and streaming to other participant peers.

The chunk: An integrating content is divided

into several chunks by last time or the certain size. A

chunk is considered as the basic unit of the

partitioned content or streaming. Peers may use a

chunk as a unit of storage, advertisement and

exchange among peers. Note that a P2P system may

use different units for advertisement and data

exchange, maybe a chunk or several chunks.

The tracker: A tracker is a server on which

processing the software to provide a directory

service which maintains a list of peers storing

chunks for a specific content and answer the queries

from peers for the peer lists.

Above, we describe the three main entities of a

specific P2P system. Although there are enough

hardware components, we should have

corresponding protocols and mechanisms to enable

the communications between them. The main

protocols of a specific P2P system including the

below ones.

Tracker protocol: For enabling the

communication between the tracker and the peer, we

define this protocol. And this protocol defines the

standard format/encoding of information between

peers and the tracker, such as peer list, content

availability, peers’ status and streaming status

including online time, link status, peers’ capability

and some other parameters. And it also defines the

standard messages between the peers and the tracker.

By using these messages, peers report streaming

status and request to the tracker, and the tracker

reply to the requests.

The peer protocol: The peers can use this

protocol for requesting more potential peers from

the other peers. In this protocol, we define the

standard format/encoding of information among

peers, such as chunk description. And we also

define the standard messages among peers defining

how peers advertise chunk availability and their

neighbor peers’ information to each other, as well as

the signaling for requesting chunks among peers

(Zhang et al.).

Above, we define and describe the main entities

and protocols in a specific P2P system. Before

enabling the communication between the different

proprietary P2P systems, the preconditions include

the following ones.

(1)Including the same main entities. There are

peers and track in the system. And the contents and

the streaming are partitioned by chunks.

(2)Using the same format/encoding of

information in the track protocol and the peer

protocol. So the messages can be transmitted

between different P2P systems and be translated

correctly.

By the above conditions, we can show the

architecture of a specific P2P system in the

following figure.

SOLUTIONS FOR ENABLING COMMUNICATION BETWEEN DIFFERENT PROPRIETARY PEER-TO-PEER

SYSTEMS

581

Figure 1: The common architecture of the P2P system.

2.2 Overview of the Additional Layer

In this section, we will describe the location of the

additional layer and its corresponding construction

and functions, as well as its features.

2.2.1 The Location and Inner Construction

We can see the common architecture of the P2P

system, the additional layer will be named P2P-

Bridge. And we see its location in figure 2 by

modifying the figure 1.

Figure 2: The Location of the P2P-Bridge Layer.

The figure 2 shows the P2P-Bridge’s location

clearly, and it is located above the overlay

management layer implemented by the tracker.

Through the P2P-Bridge, the two trackers in

different proprietary P2P systems can communicate

with each other to exchange the information.

In the P2P-Bridge, it has its own inner

construction and we can divide the layer into several

logical parts.

Figure 3: The Construction of the Layer.

Figure 3 shows the components of the layer. It

contains three components: the message handler,

status management and the name transfer.

The message handler is to handle the message

between the trackers. While the message arrives, it

analyses it first. And then modifies the message to a

unified message with certain format and encoding

way.

The status management will keep the status of the

other trackers which can communicate with the local

tracker. And it also maintains their status including

the link status, storage and the resources status of

the other P2P overlay.

The name transfer maintains a name table for

looking the corresponding name of the content or

streaming as the same one may have a different

name in another P2P system. And it also maintains

some mechanisms for converting the users’ requests.

Although we introduce the components briefly,

we will describe it fully in the following part.

2.2.2 The Function and the Processing

The main goal of the P2P-Bridge layer is to enable

the communication between the different proprietary

P2P systems. We can achieve this goal by several

steps.

First, we have to handle the messages from

different P2P systems. As we have suggested that

the format/encoding are the same, so we can

understand the messages easily. Then we have to

modify the message into a suitable format which

used in the P2P system which we want to

communicate with. At the same time, we extract the

name of the requesting content or streaming from

the message. Then we will look into the name tables

which are maintained by the name transfer. Then we

add the corresponding name into the modified

message. All over the processing, we have to

maintain some information to choose the most

suitable P2P overlay, to ensure the other tracker is

not uploaded and refresh the name tables on time.

The message handler is for receiving the

message, and modifying the message briefly into the

format which is suitable in another P2P system. At

the same time, it extracts the name of the content or

streaming and passes it to the name transfer.

The name transfer receives the name from the

message handler. Then it looks into the name table

which it maintains for searching the name in another

P2P system. Then the name transfer returns the

corresponding name to the message handler, if it

successfully finds it.

ICEIS 2011 - 13th International Conference on Enterprise Information Systems

582

The message handler modifies the message again

after receiving the name returned from the name

transfer.

After doing the above things, the message is

modified into the suitable format which the tracker

in another P2P system’s tracker can understand and

handle it.

The status management is for maintains the

connection between the trackers and it can also be

used to compute the mount of the traffic between the

different P2P systems for charging.

2.2.3 Features

By adding this layer in the existing P2P systems, we

can easily enable the communication between the

different proprietary P2P systems. And there have

several features by deploying the layer.

Convenient. We don’t have to change the whole

architecture or the inner construction of the system.

Manageable. By adding some mechanisms in the

status management, we can manage the connections

suitable for the whole P2P overlay.

Scalable. We can add the complex component

into the P2P-Bridge easily. And it will be

compatible for the whole logical layer and the P2P

system.

2.2.4 Other Issues

Although the solution deals with the problem well,

there are some open issues existing.

The naming space. In the layer, we have to

maintain the name tables for searching. Maybe we

can unify the naming space first, it will be more

flexible. And in (Hu et al., 2009), it proposes an

approach to accurately identify different P2P

applications from the network traffic for managing a

number of network traffic issues.

The chunk information. Maybe the request

contains the requested chunks. And as the different

strategy of dividing the content, the chunk is defined

differently in different proprietary P2P systems. So

we have to modify the chunk information or define

the unify chunk information first.

The above issues are the two main ones, and

maybe other issues existed.

3 THE SERVICE-ORIENTED

ARCHITECTURE

For handling the problem of how to enable the

communication between different proprietary P2P

systems, there some ways have been proposed on

the high level.

In (Dabek et al.), it has proposed a common API

for structured peer-to-peer overlays and the key

abstractions that can be built on them. The authors

propose the KBR API for enabling the developers

implement it as an RPC program with flexibility and

effectiveness. And in (Delmastro et al., 2006), the

author has proposed an extension of the common

API as a generalization of fixed and mobile

structured P2P systems, exploiting the cross-layer

approach to export network routing table

information and the current state of the overlay even

at the application layer.

A Service Oriented Infrastructure consists of

four categories of components: Service Planning,

Service Systems, Service Management, and Service

Stakeholders. The service planning should be driven

by business domain requirements. The service

systems will be designed and implemented based on

above service plan. The service management

component includes both system operation

management and IT service management in

functional level. And the service stakeholders

should be identified for roles and responsibilities,

and should be aligned with business operational

structures (Zao, 2008). We can see its construction

clearly from the figure 4.

Figure 4: The Construction of the SOI.

As the storage systems are becoming the domain

investment in data centers and a crucial assert,

making the rate of growth of storage a strategic

business problem and a major business opportunity

for storage vendors, it’s essential for us to concern

the storage part in developing the P2P system

(Gibson and Meter, 2000).

SOLUTIONS FOR ENABLING COMMUNICATION BETWEEN DIFFERENT PROPRIETARY PEER-TO-PEER

SYSTEMS

583

In this paper, we propose the second solution for

enabling the communication between different

proprietary P2P systems basing on a service-

oriented architecture. In the following sections, we

will describe the construction of the architecture

first, and then its features different from the first

solution. And the proposed architecture uses the

integrated network storage for providing the

common accessing API for the storage or

architecture users and developers.

3.1 Overview of the Architecture

In figure 5, it shows the overview for implementing

the architecture. We have divided the whole system

into four main components.

The content providers are the source server for

providing the contents and streaming for the clients.

The component below the content providers is the

storage network conforming by the servers

providing the storage service for the contents and

streaming and the accessing service for the

proprietary P2P system below. The component

below the storage network is the P2P system. There

can be different proprietary P2P systems. And the

clients who install the proprietary P2P system is the

last component in the whole system.

The architecture we proposed is to define unified

interface to provide storage service for the content

providers, and also define the unified interface to

provide accessing service for the different

proprietary P2P systems.

3.2 The Construction of the

Architecture

In this part, we will describe the logical components

constructing the architecture. And introduce the

function of the main components.

The architecture provides two main types service.

One is the storage service while the other one is the

accessing service. First, let’s introduce the function

of the parts in the two service layers.

In the storage service layer, there are three

logical parts. The first one is the naming which

assigns a unique name for the content or streaming

received from the servers and extract common

properties to construct the unique identification for

every content and streaming. The second one is the

status management part which maintain the

information of the source servers especially the load

of the servers. The third one is the content publish

part which is responsible for choosing proper

Figure 5: Overview of the Whole Implementation.

Figure 6: The Construction of the Architecture.

storage server to publish the content or streaming

correctly.

After using the storage service, the contents and

streaming will be stored in the storage network.

Then the content will be published to the

different P2P systems by sending messages to the

tracker, maybe its name will be changed at the end

users software.

Then the clients can get the data by using the

unified accessing interface. And between the clients,

they can also help each other by the proprietary

protocol.

In the accessing service, there are also three parts.

One is the authentication which is for registering

and recognizing the tracker server in the proprietary

P2P system. The second part is the looking or

ICEIS 2011 - 13th International Conference on Enterprise Information Systems

584

searching which is for looking the clients’

requesting source in the storage network. And the

data transmission part is responsible for the data

transmission between the storage servers and the

clients.

There also important problem exists, and that is

how to construct the storage network. It has

relationship of publishing the resources, looking for

the resources, managing the resource on the storage

network. And maybe we can implement the P2P

technology in the storage network for the

performance and scalability of the overlay.

Although there is no data exchange between the

different proprietary P2P systems, but they get the

content and resources from the same overlay and

this architecture integrates the resources and the P2P

systems. Considering the P2P system as a part, it can

be seen the data transmission between different

proprietary P2P systems and we also add the

message function in the architecture for the

communications between the trackers.

4 COMPARISON

We have proposed two solutions for enabling the

communication between different proprietary P2P

systems emphasizing different aims. The first one is

to revolute the existing systems easily. And the other

one is for the integrating the P2P resources and

interviewing.

The second difference is the cost. The first one is

low while the other one is high. As the second one

needs more participants.

The third difference is the design model. The

first one is modifying the existing ones, while the

other one oriented at the level of the architecture

with some new features.

5 CONCLUSIONS

Although we have proposed two solutions for

reduce the wasting of the content and streaming

storage resources in the P2P systems and enabling

the developing process of the P2P system easier. We

lack the thinking about the mobile environment to

implement the P2P software. And in the future, there

will be more flexible and scalable solutions for the

P2P content and streaming distribution even the data

distribution in uniformed format.

ACKNOWLEDGEMENTS

This work is supported by the National Key project

of Scientific and Technical Supporting Programs of

China (Grant Nos.2008BAH24B04,

2008BAH21B03; the National Natural Science

Foundation of China (Grant No.61072060)); the

program of the Co-Construction with Beijing

Municipal Commission of Education of China.

REFERENCES

Emule, http://www.emule.com/

PPlive, http://www.pplive.com/

PPStream, http://www.ppstream.com/

CNTV, http://www.cntv.cn/index.shtml

B. Coben. “Incentives Build Robustness in Bittorrent”.

http://bitconjure.org/BitTorrent/ bitttorrentecon.pdf,

May 2003.

Yang Liu, Yang Guo, Chao Liang. “A Survey on peer-to-

peer video streaming systems”. December 6, 2007.

Springer Science&Bussiness Media, LLC 2008.

Yan Huang, Tom Z. J. Fu, Dah-Ming Chiu. “Challenges,

Design and Analysis of a Large-scale P2P-VoD

System”. SIGCOMM’08, August 17-22, 2008.

Zhang Y., Zong N., Camarillo G., Seng J., and Y. Yang.

“Problem Statement of P2P Steaming Protocol”.

http://datatracker.ietf.org/doc/draft-ietf-ppsp-problem-

statement/?include_text=1.

Chen-Chi Wu, Kuan-Ta Chen, Yu-Chun Chang, Chin-

Laung Lei. “Peer-to-Peer Application Recoginition

Based on Signaling Activity”. 2009. ICC '09. IEEE

International Conference on Communications, June

2009.

(Dabek et al.) Frank Dabek, Ben Zhao, Peter Druschel,

John Kubiatowicz. “Towards a Common API for

structured Peer-to-Peer Overlays”. http://project-

iris.net/irisbib/papers/iptps:apis/.

Delmastro F., Conti M., Gregori E.. “P2P common API

for structured overlay networks: a cross-layer

extetnsion”. July, 2006.

Yan Zhao. “Service Oriented Infrastructure Framework”.

2008.IEEE Congress on Services, July 2008.

Garth A. Gibson, Rodney Van Meter. “Network Attached

Storage Architecure”. Communications of the ACM,

November 2000. Vol 43. No 11.

SOLUTIONS FOR ENABLING COMMUNICATION BETWEEN DIFFERENT PROPRIETARY PEER-TO-PEER

SYSTEMS

585