5

Click here to load reader

SimP2P: a Peer-to-Peer System for Texture Distribution in Social Virtual Worlds

Embed Size (px)

Citation preview

Page 1: SimP2P: a Peer-to-Peer System for Texture Distribution in Social Virtual Worlds

SimP2P: a Peer-to-Peer System for Texture

Distribution in Social Virtual Worlds

Marcelo Santos¥, Stenio Fernandes

£, Carlos Kamienski

¥

¥Federal University of the ABC, Brazil, {marcelo.santos, cak}@ufabc.edu.br

£Federal University of Pernambuco, Brazil, [email protected]

Abstract – Social virtual worlds (MMOW) allow users to

dynamically create new content with high degree of

personalization and immersion in shared real time environments.

Popular MMOWs, such as Second Life (SL), are based on a

Client/Server (C/S) approach for guaranteeing a shared

consistent view of the virtual world, thus generating high

network traffic volumes. This is due to the intrinsic features of

MMOWs, where servers keep most information of the virtual

environment, unlike some other types of virtual worlds, such as

Massively Multiplayer Online Games (MMOG), such as World of

Warcraft, where clients keep all objects and textures stored

locally. Although the C/S approach is universally used because it

is reliable and easily controlled, it poses a high burden on server

hardware and bandwidth. In this paper, we propose SimP2P, a

peer-to-peer approach for sharing textures among clients for

MMOW environments, such as OpenSim. Our results show that

SimP2P is able to decrease significantly the traffic sent by the

OpenSim server, as well as to provide a much better Quality of

Experience (QoE) for users, measured by texture response time.

Keywords: Virtual Worlds, OpenSim, Second Life, Peer-to-

Peer, Scalability.

I. INTRODUCTION

Improvement of network technologies and increased processing power of computers have massively boosted the use of networked virtual environments, also known as Virtual Worlds (VW). Such environments provide a high level of immersion and interactivity that meet general requirements for a good experience in communication, socialization and learning. VW environments have nowadays a variety of utilization, from gaming to distance learning, according to the needs and imagination of the end user. These characteristics place VW as a service of enormous potential growth. We envisage that in some years having an avatar (i.e., a digital representation of the user) will be as common as owning an account for e-mail or instant messaging.

As virtual environments are becoming increasingly popular, user participation has also increased substantially, reaching millions of simultaneously logged in users. Traditionally, VW systems are typically developed using a Client / Server (C/S) approach, which has several technical and commercial disadvantages. Specifically, such approach leads to drawbacks into reliability, hardware costs, bandwidth network, high cost of processing, and maintenance. However, this model is currently dominant due to the ease of ensuring consistency within the VW and to simplify the exchange of messages and updates between clients [1]. Even though popular and

traditional VW systems are based on C/S (for instance, Second Life [2]), C/S is often not considered ideal to support an increasing workload [17]. Given these limitations of this architecture, there have been strong interests in developing a VW environments developed under the umbrella of a Peer-to-Peer (P2P) network [1][4][5][6][7].

Taking into account the characteristics of MMOW (Massively Multiplayer Online World) environments and their limitations, this paper presents and evaluates SimP2P, a P2P approach for virtual world environments, where the textures of objects are exchanged among peers. This approach substantially reduces the load on network utilization. To the best of our knowledge, there are no studies that assess the impact of the use of P2P network techniques for distributing MMOW textures. We focused our study in the OpenSim 1 virtual world simulation environment, yet SimP2P can be also used for Second Life (SL)2.

The rest of the paper is structured as follows. Section 2 discusses related work, whereas Section 3 gives an overview of VW. Section 4 presents the architecture of our approach, namely SimP2P. Section 5 describes the methodology used in this work and section 6 presents performance results. Section 7 discusses our important findings. Finally, section 8 draws some conclusions and presents topics for future research work.

II. RELATED WORK

Antonello et al. [3][10] conducted performance analysis on the client side of Second Life, analyzing metrics such as flow volume of UDP and TCP traffic under different actions of avatars. Their study was the first to show potential bottleneck problems such as the amount of bandwidth needed for applications similar to the SL. Server-side analysis was left for future work.

Fan Lu et al. [1] addressed implementation aspects of P2P networks for MMOG (Massively Multiplayer Online Games) environments. They mainly discussed incentive mechanisms to peers and also give a clear overview of P2P architectural issues in MMOW. In another paper [7], they also proposed a framework called Mediator, which provides a generic architecture for virtual worlds. It addresses key problems of MMOG environments by presenting a strategy with super-peers that are able to manage parts of the virtual world, through

1 http://opensimulator.org 2 http://secondlife.com (one must observe that Second Life presents

some limitations, since access to the server is not available).

Page 2: SimP2P: a Peer-to-Peer System for Texture Distribution in Social Virtual Worlds

the distribution of responsibilities, such as propagation of messages among peers and AoI (Area of Interest) management. The latter means that users´ visibility may be confined into a relatively static area so that they only need to be aware of events that happen inside their AoI. The Mediator strategy is fairly complete for deployment in MMOGs, but it is too complex to be adapted to MMOW. In addition, there is no source code available for the Moderator. Hu et al. [9] and Knutsson et al. [4] presented are strategies for AoI management and sharing in MMOG that helped us understanding the difficulty of event dissemination in virtual environments.

It is worth emphasizing that there are no results available in the literature regarding implementations of a P2P system MMOW that meet all the needs of users efficiently. It can be stated further that with the current proposals for P2P architectures for virtual worlds, it is virtually impossible to make adjustments in the structure of SL or OpenSim without rewriting much of the server and client’s code.

Essentially, all the papers cited have results from either simulation or analytical modeling. In some cases, there is just a proposal for an architecture in which the authors considered consistent for VWs. There is no real implementation available for tests in real environments.

III. VIRTUAL WORLDS

Virtual Worlds are digital environments that emulate complex physical spaces through representations of simulated environments, which contain objects and allow interactions with avatars [3].

Social virtual worlds have received most attention from industry and academic researcher. MMOW (Massively Multiplayer Online World) are a subdivision of MMOG (Massively Multiplayer Online Game) that allows great configuration flexibility to the end user. In general, MMOGs differ from MMOWs, because they cannot be characterized by a particular fiction (e.g. monsters and quests) and do not present levels of quantifiable results.

In MMOW environments, the client software stores a small amount of information of the VW, since its corresponding server keeps most information regarding the user-generated content. The cost of this approach is the additional burden on the server resources, such as processing power and network traffic. Currently, Second Life is the most popular MMOW and in the last quarter of 2010 it comprised an area of 2.090 km

2

where more than 750,000 unique users from different parts of the worlds spent more than 105 million hours connected and millions of dollars were exchanged in its virtual economy [16]. OpenSim is based on SL, but with an open source license agreement.

A. OpenSimulator

OpenSimulator (also called OpenSim) is a set of distributed services with an open source code model that may be used to build a virtual world similar to Second Life. The architecture of both OpenSim and Second Life is based on the Client/Server model, where the server keeps all the information about the environments and sends periodical updates to its client that in turn transforms data into a three-dimensional scenario in quasi-real time. Due to the openness of these environments and to the

dynamic creation of content by users, and their interaction in real time, such architecture poses a significant burden on the servers, which are responsible for receiving incoming updates from clients, processing them, and sending back a coherent single view of the virtual world region.

OpenSim works in two modes: Standalone or Grid. Standalone is limited to a small number of users since a single process is responsible for the entire simulation environment. Grid has the potential to be more efficient as the number of users grow. It is possible to distribute services among different servers. Grid mode is based on two types of servers: Robust.exe and Opensim.exe. The Virtual World is composed of a single Robust server and one or more OpenSim servers (also known as region server) that access the Robust server. In order to provide scalability with the number of users connected and resources consumed, a given region is assigned to a specific server. Therefore, a single region requires a very large demand for hardware and network resources on the server side.

IV. SIMP2P

The huge amount of network traffic volume generated by textures requests to the MMOW server [12][17][10] encouraged the strategy applied in this work. Our approach, called SimP2P, is based primarily on two changes in the C/S architecture of OpenSim.

First, we address how clients request textures3 from servers, by implementing an Area of Interest (AoI). The AoI is based on the Second Life behaviour, where the server sends only information of textures, objects, and avatars within a radius of 64 meters. Unlike SL, OpenSim server sends information about all objects that are within an entire region. It is left to the users whether or not they will request more details of objects. Thus, if a given user requests all textures without checking if his/her avatar is at the object surroundings, he/she can request textures that are outside his/her view. SimP2P clients have adopted similar behaviour as the SL ones, although some control management is done by themselves.

Second, we address the scalability issue in terms of network traffic. To do that, we made modifications on the client to use a distribution algorithm of textures in a P2P approach. OpenSim server was modified in a way that a list of avatars in the same region is sent to clients, where an avatar represents a peer. From the list of peers, each client randomly selects five peers to establish a TCP connection in order to exchange unidirectional textures, thus forming a content distribution network mesh. A given peer selects another peer only if there is any communication disruption with any peer it is currently connected to.

Texture search is done in a simple way. Client A sends a query to the 5 peers it is currently connected. Peers respond with a message queryHit or queryMiss, similar to flooding algorithms in a single level. The texture is requested to the first peer that responds with a queryHit message. If the client receives at least 4 queryMiss messages, it requests pending textures directly to the server instead of to the P2P network.

3 Textures are images that constitute the external characteristic of the objects

and generate most traffic between server and clients.

Page 3: SimP2P: a Peer-to-Peer System for Texture Distribution in Social Virtual Worlds

V. METHODOLOGY

All experiments were performed in the PlanetLab (PL) [14], which aims at being a platform for the study of new technologies and network protocols. We used 115 systems located in different parts of the world that represented clients connected to OpenSim server. Since PL systems share resources within the network, the OpenSim server was located within our university (Federal University of ABC) in a system outside PlanetLab network boundaries. In this way, we were able to accurately evaluate the OpenSim server behaviour. The server was deployed in a 64bit Linux box (OpenSUSE 11.2) with 8GB of RAM, Intel Xeon X3430 Quad Core 2.40GHz, and in a 1Gbps network link. The region used in all experiments in OpenSim is known as Fairie Castle [13]. In other words, we performed real experiments using machines distributed worldwide in PlanetLab, so that the results obtained are very trustworthy and may be obtained in a real deployment scenario of OpenSim.

In order to perform the experiments, we developed a client (in virtual world jargon, a bot) that simulates human actions in the VW that runs on each OpenSim system deployed in the PL. Each user recorded data of textures requests through the MySQL database and kept records of the network traffic using tcpdump [15]. During the experiment, we monitored all deployed OpenSim systems within PlanetLab. No performance problems were reported regarding hardware and network resources. This mainly occurred because we have selected systems with a good amount of memory, disk, and processing power necessary for a proper execution of the experiments.

Due to the lack of an analytical model for avatars’ mobility, we used a two-state Markov chain that switches between stop or walk states, with a 0.5 probability of staying in the same state or change it. Studies show that the avatar still spends more time standing still than walking [17]. Therefore the time spent in the walk state is generated by a uniform distribution ranging between 20 and 45 seconds, while the time in the standing still state varies between 60 and 120 seconds.

In order to generate a consistent arrival and departure of peers, we created a model for the avatars’ residence time, from measurements collected in Second Life environment. We have applied a good-of-fitness test on such data. Avatars’ residence time was then modeled as an exponential probability distribution. From the SL measurements, experiments were carried out by varying the ON time (time that an avatar stays connected) in 10, 15, 20, and 25 minutes. OFF times (time that an avatar stays disconnected) were 2, 3, 4, and 5 minutes. On average we have approximately 83% of users connected to each experiment, using the maximum number of clients supported by OpenSim.

We performed 8 different experiments, each one lasted for 360 minutes with 36 replications, i.e. each replication lasted for 10 minutes.

VI. PERFORMANCE ANALYSIS AND RESULTS

The results of the performance analysis revealed that our SimP2P approach is more efficient than the C/S model, as far as some metrics as throughput, number of textures received, and texture download time are concerned. We computed the

99% asymptotic confidence intervals, but the graphs do not show them because they are not significant.

A. Server Throughput

Figure 1 shows that the SimP2P has a clear gain as compared to the C/S approach as far as server traffic is concerned. Traffic reduction, measured at the OpenSim server output, ranges from 27% to 35%, at different ON times. As the P2P distribution strategy used is not pure P2P, but hybrid, clients send requests to the server whenever they cannot find the needed textures available in the peers. Therefore there is still incoming traffic at the server in the SimP2P approach.

Figure 1 – Server outbound throughput (AoI=64)

As a simple example, the same client connects to the server with an average of five times per hour, with an ON time of 10 minutes (i.e., 5 connections x 10 minutes ON time + 5

connections x 2 minutes OFF time → 50 + 10 = 60 minutes)

and asks 100 textures per connection. Therefore, the client requests 500 textures in one hour. Another experiment was performed, with ON time of 25 minutes and two connections at a time (2 x 25 minute connections ON + 2 connections x 5

minutes of OFF times→ 50 + 10 = 60 minutes). Each client

requests for 135 textures per connection (by walking more at the region they consequently requested more textures), in a total of 270 textures request in one hour and therefore 230 less texture requests as compared to ON time of 10 minutes. As the majority of the traffic is generated due to texture requests from clients, there is a decrease in average traffic flow, for both client and server, when increasing the ON time. This is because clients usually only request a texture once when they are connected and therefore the longer they stay connected, the less textures they request from the server. The exception is when textures are changed by users, but this do not change the client behavior since updated textures receive a new ID and therefore they are downloaded normally as other brand new textures.

Figure 2 – Server incoming throughput (AoI=64)

0

5

10

15

20

10 15 20 25

Mb

ps

ON Time (minutes)

cs p2p

00.30.60.91.21.51.8

10 15 20 25

Mb

ps

On Time (minutes)

cs p2p

Page 4: SimP2P: a Peer-to-Peer System for Texture Distribution in Social Virtual Worlds

Figure 2 shows a reduction around 10% to 20% of server incoming traffic in the P2P approach as compared to the C/S one. This occurs because there are fewer requests for textures from clients to the server in the P2P approach, generating less exchange of information between them.

B. Client Throughput

Figure 3 shows the average throughput for different client residence times. It is worth noticing a slight increase in incoming traffic as P2P clients (e.g., no more than 2%) due to a larger number of textures and received and to small traffic overhead inherent to control information of any P2P strategy.

Figure 3 – Client incoming throughput (AoI=64)

It is also important to note that although there is a large reduction of texture requests to the server, this does not imply in a major burden on the upload rate at peers. Outbound traffic certainly increases, but it does not exceed a rate of 50 Kbps. It is also observed that increasing the residence time results in decreased user traffic, as it has been shown at the server side.

C. Transfer Time

From the point of view of user Quality of Experience (QoE), the lower the transfer time of textures, the better visualization of the region. Comparing the approaches C/S and P2P one can notice a huge difference in the average time of textures transfer. The P2P approach is, in some experiments, 35 times faster (Table I).

TABLE I. TEXTURE AVERAGE TRANSFER TIME

ON Time 10 15 20 25

C/S 36,55 38,69 38,56 39,94

P2P 1,40 1,39 1,39 1,45

Taking a look at the confidence interval one cannot tell any improvement in the transfer time when ON time is varied. In all experiments the SimP2P approach clearly proved to be more efficient regarding textures transfer times.

D. Testure requests Figure 4 depicts a comparative analysis of the total number of requests for textures, during six hours of experiment, between the C/S and SimP2P approaches, in an AoI of 64-meter radius.

The number of texture requests by C/S and P2P was statistically the same when simulation was configured with the same ON time. By calculating the confidence interval (not shown in the graphs), a small overlap occurs due to natural fluctuations attributed to the randomness of the experiments.

As previously mentioned as the ON time increases there are fewer requests for textures.

Figure 4 – Number of textures REQUESTED by each peer

Users using the P2P approach receive more textures that those using a C/S approach (Figure 5). This behaviour is justified when analyzing the average download time of textures in each approach. While the C/S architecture had an average download time estimate ranging from 36 to 39 seconds, the average download time for the P2P strategy was, in all cases, less than 2 seconds (Table I). Since the request to the server takes up to 36 seconds to be completed, it turns out that frequently a peer sends a request but does not receive the texture before it disconnects itself from the server. Therefore, the ratio between requested and received reveals a more efficient strategy (i.e. it is closer to 1).

Figure 5 – Number of textures RECEIVED by each peer

A more detailed analysis of the texture requests shows that a peer receives an average of 75% to 77% of the textures directly from other peers and the remainder is requested directly to the OpenSim server. Quantifying the number of textures sent by each peer using the Kolmogorov-Smirnov fitness test, we obtained a good adherence to a uniform distribution. This result shows that there is a formation of a mesh network with no additional burden on a select group of peers, even without a reward mechanism for distributing content.

Figure 6 – Number of texture requests received by each peer

050

100150200250

in out in out in out in out

10 15 20 25

Kb

ps

On Time (minutes)

c/s p2p

0

500

1000

1500

2000

10 15 20 25

Re

qu

est

ed

te

xtu

res

ON Time (minutes)

CS P2P

0

450

900

1350

1800

10 15 20 25

Re

ceiv

ed

te

xtu

res

ON Time

CS P2P

0

1000

2000

3000

4000

1 11 21 31 41 51 61 71 81 91 101 111

Text

ure

Re

qu

est

s

PlanetLab Machines

Page 5: SimP2P: a Peer-to-Peer System for Texture Distribution in Social Virtual Worlds

VII. DISCUSSION

Network resources consumption at the OpenSim server is very high for a small number of avatars, reaching peaks of over 18 Mbps of output traffic, in experiments with an average of 95 avatars. This high demand contrasts, for example, with the reality of many educational institutions in the world that may wish to use virtual worlds as learning environments. With the SimP2P strategy was possible to reduce the average traffic in around 30%, thus greatly improving scalability from the server's point of view.

Traffic analysis at client and server sides revealed that throughput is driven by the user residence time. There is a reduction of the average volume of data in the case of an increase of the residence time, since a given texture only needs to be applied once during the entire connection. That is, the client requests a large amount of textures, but spends most time without requesting new ones, when their connection time is very high. When the user stops requesting textures, throughput is mainly due to the control traffic and avatar movement updates, which is much lower than traffic generated by transfer of textures [13].

Results show a good throughput regarding textures transfers in the P2P network. We envisage that this can still be improved through a more efficient algorithm for search and distribution in the P2P network. The SimP2P strategy also presented excellent results for the client, reducing up to 27 times the average waiting time for a texture. However, there is still room for improvements in the peer selection strategy in order to maximize the number of textures that can be found in the P2P network. We believe that the number of textures requested from the server, which reached around 23%, can be decreased.

One minor drawback when using our P2P approach was the increase of outbound traffic from the client. However, this value did not exceed 50 Kbps, which is a fair to uplink speeds of current broadband uplinks.

Also, we adapted our SimP2P solution and tested it in Second Life, even though we do not have access to the servers. From the client perspective the results are quite similar to those shown in section VI for OpenSim, thus confirming that the approach is flexible enough to work on different systems and do not depend exclusively on a controlled environment for yielding significant results.

VIII. CONCLUDING REMARKS

OpenSim is a virtual world that is rapidly gaining popularity among users due to its rich feature set and open source code, making it an attractive alternative to Second Life. However, scalability aspects still need to be addressed, as in all virtual world environments. Server hardware requirements are high, demanding deployment of expensive configurations, and high-speed network links.

This work not only proposed a P2P approach for a VW environment, but also implemented and conducted performance analysis in real scenarios, where clients exchange images that represent objects texture. Our approach presented

higher performance as compared to traditional C/S architecture. One of the major strengths is in the client as it does not require excessive changes in the current architecture. With the proposed SimP2P scalability is gained by keeping its essentials features, such as data persistence and user QoE improvement. This is due to higher rates of textures transfer. It also brought forth a significant impact in reducing the load of network traffic at the server side.

There are several possible directions for extensions of this work. Firstly, we intend to implement and test the SimP2P approach on other MMOW and to extend the analysis for Second Life. Secondly, an extension of the SimP2P approach for disseminating object creation events and control messages is also envisaged. Finally, we intend to implement other P2P algorithms to increase efficiency, such as incentive mechanisms and accurate object search in the network.

REFERENCES

[1] L. Fan, P. Trinder and H. Taylor, “Design Issues for Peer-to-Peer Massively Multiplayer Online Games”, in IJAMC, vol. 4, no. 2, 2010, pp 108-125.

[2] “Second Life”, http://secondlife.com, last access March 2011.

[3] R. Antonello, S. Fernandes, J. Moreira, C. Cunha, C. Kamienski, D. Sadok, “Traffic analysis and synthetic models of second life”, in Multimedia Systems, vol. 15, no. 1, 2009, pp 33-47.

[4] B. Knutsson, H. Lu., W. Xu., and B. Hopkins, “P2P Support for Massively Multiplayer Games,” in Proc. of INFOCOM. IEEE, vol. 1, 2004.

[5] T. Hampel, T. Bopp & R. Hinn, “A P2P Architecture for Massive Multiplayer Online Games,” in Proc. of SIGCOMM workshop on Network and system support for games, 2006, pp 48--es.

[6] S. Douglas, E. Tanin, and A. Harwood, “Enabling Massively Multi- Player Online Gaming Applications on a P2P Architecture,” in Proc. of the IEEE ICIA, 2005, pp 7-12.

[7] L. Fan, H. Taylor, and P. Trinder, “Mediator: A Design Framework for P2P MMOGs,” in Proc. of the 6th ACM SIGCOMM workshop on Network and system support for games, 2007, pp 43-48.

[8] C. Symborski. “Scalable User Content Distribution for Massively Multiplayer Online Worlds”, in IEEE Computer, vol. 41, no. 9, 2008, pp 38-44.

[9] S. Hu. J. Chen, T. Chen, “VON: a scalable peer-to-peer network for virtual environments”, In IEEE Network, vol. 20, no. 4, 2006, pp. 22-32.

[10] S. Fernandes, C. Kamienski, D. Sadok, J. Moreira, and R. Antonello. “Traffic analysis beyond this world: the case of Second Life”, in NOSSDAV, 2007.

[11] H. Liang, M. Motani. and Ooi, W.T., “Textures in Second Life: Measurement and Analysis,” in ICPADS, 2008, pp 823-828.

[12] “OpenSim Worlds”, http://opensimworlds.com, last access March 2011.

[13] M. Varvello and G. M. Voelker, “Second Life: a Social Network of Humans and Bots,” Nossdav’2010, June 2010, pp 9-14.

[14] “PlanetLab”, http://www.planet-lab.org, last access March 2011.

[15] “TcpDump”, http://www.tcpdump.org, last access March 2011.

[16] “Linden Labs”, http://lindenlab.com/about, last access June 2011.

[17] M. Varvello, S. Ferrari, E. Biersack, C. Diot, “Exploring Second Life”, IEEE/ACM Transactions on Networking, Vol 19, num 1, pp. 80-91, 2010.