PLATFORM INDEPENDENT WEB-BASED PEER-TO-PEER … · Määttä M. (2010) Platform Independent...

DEPARTMENT OF ELECTRICAL AND INFORMATION ENGINEERINGDEGREE PROGRAMME IN ELECTRICAL ENGINEERING

PLATFORM INDEPENDENT WEB-BASEDPEER-TO-PEER APPLICATION

AuthorMiika Määttä

Supervisorprof. Mika Ylianttila

Accepted / 2010

Grade

Määttä M. (2010) Platform Independent Web-Based Peer-to-Peer Application.Department of Electrical and Information Engineering, University of Oulu, Oulu, Fin-land. Master’s thesis, 67 p.

ABSTRACT

The objective of this thesis was to build a platform independent real-time webapplication which uses a standard Peer-to-Peer network. In addition, the objec-tive was to define the limitations of the web applications in a Peer-to-Peer net-work. The contemporary web design techniques enable a fast and easy way ofimplementing powerful web applications that closely match the usability and per-formance of a native application. The platform independent nature of the webapplications allows an easy way of deploying the applications for a wide devicebase. Also, the popularity of Peer-to-Peer computing has increased, and there-fore the standardization organizations and the information technology industryhave started standardizing Peer-to-Peer algorithms and protocols. Because of theincreasing popularity of powerful web technologies and Peer-to-Peer networkingit is important to study the possibilities of a platform independent web applica-tion that uses a standard Peer-to-Peer network. In this thesis, the constructiveresearch method was used to reach the objective. The current Peer-to-Peer so-lutions are platform dependent and require separate installation from the user.The contribution of this thesis was to develop a platform independent prototypeweb application that does not require separate installation from the user. Theperformance of the web application developed in the thesis was compared to thecurrent Peer-to-Peer solutions. In this research, it was found out that it is possi-ble to develop a web application that uses a Peer-to-Peer network. Performancetests, in their turn, showed that the performance of the web technologies is not abottleneck in Peer-to-Peer networking. However, there are some limitations in thecontemporary platform independent web applications compared to the platformdependent applications. Communication between two platform independent ap-plications is not possible. Therefore, a media server is required to handle the realtime communication between the users. Due to this communication limitation,the web application cannot provide its own resources to the other users in a Peer-to-Peer network. As a consequence, a web application can only act as a client inthe Peer-to-Peer network at the moment.

Keywords: software development, peer-to-peer networking, web development,Flash.

Määttä M. (2010) Alustariippumaton web-pohjainen vertaisverkkosovellus.Oulun yliopisto, sähkö- ja tietotekniikan osasto. Diplomityö, 67 s.

TIIVISTELMÄ

Diplomityön tavoitteena oli rakentaa ohjelmistoalustasta riippumaton reaali-aikainen web-sovellus, joka käyttää standardia vertaisverkkoa. Lisäksi tavoit-teena oli selvittää web-sovelluksien puutteita vertaisverkossa. Nykyiset web-suunnittelumenetelmät nopeuttavat ja helpottavat tehokkaiden web-sovelluksientekemistä. Lisäksi nykyisten web-sovellusten käytettävyys ja tehokkuus ovatvertailukelpoisia alustastariippuvien sovellusten kanssa. Koska web-sovelluksetovat alustariippumattomia, niitä voidaan jakaa laajalti. Vertaisverkkojen suo-sion kasvamisen vuoksi standardisointiorganisaatiot ja teknologiateollisuus ovataloittaneet vertaisverkkoihin liittyvien osien standardoinnin. Web-teknologianja vertaisverkkojen suosion vuoksi on tärkeää tutkia Web-sovellusten hyödyn-tämistä vertaisverkoissa. Diplomityössä käytettiin konstruktiivista tutkimusme-todia. Nykyiset vertaisverkkoa käyttävät ratkaisut ovat alustariippuvia ja käyt-täjän on asennettava ne käyttämäänsä laitteeseen. Tämän työn tavoitteenaoli kehittää alustariippumaton web-sovellus, jota ei tarvitse erikseen asentaakäytettävään laitteeseen. Tutkimuksessa verrattiin alustariippumattoman web-sovelluksen suorituskykyä olemassa oleviin vertaisverkkosovelluksiin. Tutkimuk-sessa havaittiin, että web-sovellus voi käyttää vertaisverkkoa. Suorituskykymit-tauksessa havaittiin, että web-sovelluksen suorituskyky on riittävä toimimaanvertaisverkossa. Web-sovelluksessa oli kuitenkin puutteita verrattuna aiempiinvertaisverkkosovelluksiin, sillä web-sovellusten välille ei voitu muodostaa suoraayhteyttä. Sen sijaan sovellusten välinen realiaikainen yhteys voitiin muodostaapalvelimen kautta. Tämän vuoksi nykyisin web-sovellus voi toimia vertaisverkos-sa vain asiakaskoneena.

Avainsanat: ohjelmistokehitys, vertaisverkot, verkko-ohjelmointi, Flash.

TABLE OF CONTENTS

ABSTRACT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2TIIVISTELMÄ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3PREFACE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6ABBREVIATIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1. INTRODUCTION. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.1. Research background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.2. Research objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.3. Introduction to the research method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2. RICH INTERNET APPLICATIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.1. Basics of web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.2. Web application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.3. Structure of a web application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.4. Requirements for the contemporary web applications . . . . . . . . . . . . . . . . . 142.5. Characteristics of rich internet systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.5.1. Characteristics of Rich Internet Applications. . . . . . . . . . . . . . . . . . . . . 152.5.2. Examples of web technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3. PEER-TO-PEER NETWORKING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.1. Definition of Peer-to-Peer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.2. Classification of Peer-to-Peer architectures . . . . . . . . . . . . . . . . . . . . . . . . . 203.3. Characteristics of Peer-to-Peer system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.3.1. Degree of centralization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.3.2. Overlay network structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.3.3. Distributed Hash Table algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.4. Peer-to-Peer Session Initiation Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.4.1. Session Initiation Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.4.2. Session Initiation Protocol with Peer-to-Peer networking . . . . . . . . . . 25

4. DEVELOPMENT OF THE PEER-TO-PEER SOLUTION . . . . . . . . . . . . . . . . . 274.1. Defining the Peer-to-Peer service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.2. Technical design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.2.1. Objective of the design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.2.2. Development tools and environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.2.3. Technical requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.2.4. Basic architecture of the system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.3. Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.3.1. Objective of the implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.3.2. Implementation of the application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5. EVALUATION. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385.1. Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

5.1.1. Final application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385.1.2. Experiments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.2. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465.2.1. Web development techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465.2.2. Feasibility of the architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475.2.3. Functionality of the web application . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

6. SUMMARY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

7. REFERENCES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 528. APPENDICES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

PREFACE

This thesis was done for the DECICOM research project at MediaTeam group at theUniversity of Oulu, Finland. DECICOM (Decentralized Inter-Service Communica-tions) is a three-year project in the area of distributed Peer-to-Peer based servicesin mobile networks. The purpose of this thesis was to support DECICOM projectto achieve its objectives. First, I would like to thank my supervisor Professor MikaYlianttila. I would also like to thank my advisor M.Sc. Erkki Harjula for his guidanceand comments during the research. I also got great help from the Ericsson Nomadiclabpersonnel; I wish to thank them as well. Most importantly, I would like to thank Tuulia,Saku and Riina for voluntarily helping me to complete this process - I am sure I willreward your work with a great party!

April 5, 2010Miika Määttä

ABBREVIATIONS

AAC Advanced Audio CodingAjax asynchronous JavaScript and XMLAMF Action Message FormatAPI Application InterfaceASP Active Server PagesAVM ActionScript Virtual MachineBBB Big Blue ButtonCAN Content Addressable NetworkCASE Computer-Aided Software EngineeringCGI Common Gateway InterfaceCPU Control Processing UnitCSS Cascading Style SheetsDECICOM Decentralized Inter-Service CommunicationsDHT Distributed Hash TableFLA Flash document fileFLV Flash video filesFMS Flash Media ServerGPS Global Positioning SystemGUI Graphical User InterfaceHCI Human-Computer-InteractionHTML Hypertext Modelling LanguageHTTP Hypertext Transfer ProtocolIDE Integrated Development EnvironmentIETF Internet Engineering TaskforceIM Instant MessagingIP Internet ProtocolLGPL Lesser General Public LicenceLRM Local Relational ModelMP3 MPEG-1 Audio Layer 3MPEG-4 AVC Motion Picture Experts Group-4 Advanced Video CodingMPL Mozilla Public LicenseOBR Out-Of-Box ReadinessOOBE Out-Of-Box ExperienceOSFlash Open Source FlashP2P Peer-to-PeerP2PSIP Peer-to-Peer Session Initiation ProtocolP2PSIP WG Peer-to-Peer Session Initiation Protocol Work GroupPHP Hypertext PreprocessorPS Proxy ServerRFC Request For CommentsRIA Rich Internet ApplicationRTMFP Real Time Media Flow ProtocolRTMP Real-Time Messaging ProtocolS60 Series 60SDK Software Development Kit

SIP Session Initiation ProtocolSMS Short Message ServiceSWF Shockwave FlashTCP Transmission Control ProtocolTEKES Finnish Funding Agency for Technology and InnovationTTL Time-To-LiveUA User AgentUAC User Agent ClientUAS User Agent ServerUI User InterfaceUML Unified Modelling LanguageVoIP Voice Over Internet ProtocolW3C World Wide Web ConsortiumXML Extensible Markup LanguageXUL XML User Interface Language

1. INTRODUCTION

1.1. Research background

Use of internet has increased remarkably in the last decade. Nowadays, web appli-cations are used in almost every web domain. Current communication and networktechnologies are changing the way people interact with web applications, providingthem powerful mobile communication devices with ubiquitous access to network. Webservices and applications must be highly tailored to users’ special requirements. [1]

Contemporary design techniques enable a fast and easy way of implementing power-ful web applications. Development tools enable implementing of impressive GraphicalUser Interfaces (GUI) that closely match the usability and performance of a nativeapplication. [2]

Peer-to-Peer (P2P) based applications have gone through several evolutionary stepssince the first file sharing applications. Due to increasing popularity of P2P computing,the standardization organizations as well as the information technology industry havestarted concentrating on standardizing P2P algorithms and protocols. [3]

Recent technological advances in mobile networking and mobile device capabilitieshave made P2P networking possible in mobile domain as well. Session Initiation Pro-tocol (SIP) is the most important protocol for session management, instant messagingand presence information exchange in mobile networks. Since SIP provides a possi-bility of connecting a mobile device with any SIP-enabled computer in the internet, itremoves barriers between the mobile and fixed networking. The Internet EngineeringTask Force (IETF) has formed a work group for researching the possibility of server-less usage of Session Initiation Protocol (SIP). The protocol is called Peer-to-Peer SIP(P2PSIP). [3]

1.2. Research objective

The objective of this thesis was to study possibilities of using a standard P2PSIP net-work with the help of a platform independent web application. Using the web appli-cation should require only a web browser and therefore the usage of the applicationshould not require any SW installation from the user. At the same time, the objectivewas to find possible obstacles preventing contemporary web applications from usingthe P2PSIP networking. The web application should utilize P2PSIP overlay networkso that it is able to connect with peer computers in the network. The web applicationshould also be able to store and retrieve data to the overlay network and to connectwith other users.

Besides developing a platform independent web application, the objective was tostudy the performance of the application. Focus was on delays associated with joiningand establishing a connection between two users in P2PSIP overlay. The experimentswere executed using PlanetLab test network as P2PSIP overlay. These delays werecompared to corresponding results measured by Jouni Mäenpää and Gonzalo Camar-illo using a prototype application implemented in Java [4] . The same PlanetLab testnetwork was used in Mäenpää’s experiments [4] . Simply put, the research questioncould be presented as follows: Is it possible to develop a platform independent web

10

application which uses P2PSIP network and if so what are the limitations of the devel-opment?

The research question proper relates to Decentralized Inter-Service Communications(DECICOM) project. The plan was to develop the web application by means of pro-totyping the required functionalities. DECICOM project will use the application fordemonstration purposes inside the project.

1.3. Introduction to the research method

In this thesis, the constructive research method was used, which was a suitable method,because the purpose of this thesis was to develop a P2P application using P2PSIP over-lay network. However, the contribution of the solution planned in this thesis comparedto old solutions was clear. Old prototype applications were developed as platformdependent and they also required users to install the application in the device. Theobjective of this thesis was to develop a web application that is platform independentand does not require separate installation from the user. [5]

The constructive research means that a solution is built or constructed using existingknowledge in new ways. Constructive research gives a possibility for adding newmissing links that are needed to support the whole structure. The construction researchis done by designing and developing using tailored building blocks to find the gaps andsupport the future solution envisaged. For example, algorithms, models, diagrams andsoftware development methods are typical artefacts used for construction in researchand engineering. Constructive solutions are usually designed and developed instead ofbeing discovered. [6]

The following phases are proposed for the constructive approach: [6]

• Find a practical and relevant problem which also has research potential.

• Adopt a general and comprehensive understanding of the topic.

• Construct and innovate a solution idea.

• Demonstrate that the solution is functional.

• Show the research contribution and the theoretical connections of the solution.

• Examine the applicability of the solution.

The scientific validity of the research is based on how well it solves problems orreveals new problems. The criteria for relevant, simple and ease of use are also com-monly applied for the functioning application in constructive research. [6]

The research starts from Chapter 2, which explains the basics of the web systemsand web applications. Chapter 2 also lists the characteristics and requirements of con-temporary web applications. Chapter 3 defines the term P2P in a more detailed leveland illustrates different types of P2P architectures listed by researchers. Chapter 4 ex-plains the phases of the development. The development tools and selected techniquesare reviewed in Chapter 4 as well. Chapter 5 shows the final web application and theresults of the performance of the application. Also, the web application developmentis discussed and analysed in Chapter 5. Chapter 6 summarizes the research.

11

2. RICH INTERNET APPLICATIONS

2.1. Basics of web

One of the traditional web architectures is known as a client/server model. Aclient/server model is illustrated in Figure 1. Clients and servers are connected toeach other and in this way they form the web. The connection between the clientand the server can be established using for example Transmission Control Protocol(TCP). That is commonly used communication protocol for creating connections andtransferring data between computers. [7, 8]

If a client wants to receive information from a server, it sends a request into theweb in which the servers are listening to the network traffic. Clients and servers usecommon software rules and protocols, such as Hypertext Transfer Protocol (HTTP),which specify the format of the request. When the server receives the request from theweb, it locates the requested information in its local file system, and sends it back tothe client computer using TCP connection. [7, 8]

Usually, the contents of the web server is called a web page. Most web pages arebuilt using textual documents, such as Hypertext Modelling Language (HTML) orExtensible Markup Language (XML). HTML is used to express the content and thevisual formatting of a web page. HTML is a tag language, which means that HTMLcontains tags that define how text is to be formatted (e.g. font, size and colour) onthe display. HTML is a standard managed by World Wide Web Consortium (W3C).HTML is a hypertext language, which means that HTML documents can have linksthat give the user a way to navigate between the documents of the web system. XMLis also a markup language offering web designers another way to express web pagecontent. XML is also managed by W3C. [7, 8]

Figure 1. Basic client/server web system.

2.2. Web application

A web application can be defined as an extension on a web system that gives the user apossibility to access business logic with a web browser. According to Conallen, a broad

12

definition of a web application is: "a web application is a web system that allows itsusers to execute business logic with a web browser." [9]

There are several ways to implement a web application which has business logicbuilt in it. For example, instead of requesting the HTML formatted web page from theserver’s file system, the client can request the web server to load and run a module.The output of a module can be a formatted HTML page or any other dynamic webcontent. The original mechanism that allows user input to be processed in a web systemis the Common Gateway Interface (CGI). It is a standard interface which allows theuser to execute CGI modules (also called CGI scripts) on the server. CGI scripts areusually written in Perl, C or C++ programming language. Most CGI-enabled webserver applications require that CGI script must reside in a special directory, fromwhere the client requests it instead of requesting a HTML file. After the requestedCGI script is executed on server side, it returns the generated dynamic content to theclient. [10]

Nowadays, there are more powerful alternatives for interfacing with databases inorder to generate dynamic web content (e.g. ASP, PHP and Java servlets), which alsoare scripting languages. Hence, traditional CGI programming is getting less attention.Figure 2 illustrates basic technologies for generating dynamic web content. [10]

Figure 2. Basic enablers of a web application.

2.3. Structure of a web application

Traditional SW application architecture is so called 1-tier architecture, where every-thing is run on one computer (data storage, business logic, user interface). This doesnot fill the needs of a web based application which requires a connection betweenremote computers. Therefore, the application is divided into logical tiers, or chunks,each of which has different roles. [11]

A client/server solution shown in Figure 1 is called two-tier architecture, where thefirst tier is the client and the other one is the server. However, the two-tier solutiondoes not allow to separate modern web applications into several specialized functionallayers. The most common approach for today’s web applications is a 3-tier architec-ture. The 3-tier architecture is illustrated in Figure 3. In the 3-tier architecture, a web

13

browser usually acts as a client, an application server handles the business logic, andthe third tier is handling the database functions. [12, 13]

Figure 3. 3-tier architecture of a web system.

With most complex web applications, the 3-tier architecture falls short in flexibilityand scalability. This happens mainly because of too wide a business logic tier whichhas too many functions that could be separated into more specialized tiers. There-fore, an n-tier, or a multi-tiered architecture, can provide better structure for complexweb applications. The letter "n" means any number of tiers. The biggest advance inthe multi-tier approach is that complex business logic can be separated into severalfunctional layers. [13]

Figure 4 contains an example of a 5-tier architecture where presentation tier andintegration tier are added to simplify the business logic tier. In this example, the pre-sentation tier hides the complexity of the result formatting from the business logic tier.The integration tier handles all the complex communication between the data tier andthe business logic tier. The business logic tier needs to make only a simple call to theintegration tier to receive the required data. [13]

14

Figure 4. Multi-tier architecture of a web system.

2.4. Requirements for the contemporary web applications

Today, web applications are used in almost every web domain. Current communicationand network technologies are changing the way people interact with web applications,providing them powerful mobile communication devices with ubiquitous access to net-work. Services and applications must be highly tailored to users’ special requirements.Hence, for example context-awareness and multichannel access should be taken intoconsideration in web application design. [1]

Here, according to Ceri et al., context is defined as: "any information that can beused to characterize the interaction of a user with a software system (and vice-versa),as well as the environment where such interaction occurs". Mainly, this means thatby enhancing the context awareness of web applications, also the usefulness of theapplication increases since the content provider is able to detect more informationof the user’s usage environment, such as the location of the used device or the user.Personalization of web applications has already demonstrated to be beneficial for bothusers and content providers. [1]

Multichannel access to the network is also seen increasingly useful, especially bycontent providers. Multichannel access means accessing the service from various de-vices using various web browsers. Communication protocols and mark-up languagesmake multichannel deployment possible because a totally separated parallel design isnot needed to enable presentation in different devices. Hence, it is possible to makemultichannel development cost-effectively. [1]

Some of the main problems faced by traditional web applications are listed by JoshuaDuhl and Preciado et.al: [14, 15]

• Process problems: complex web applications require very long HTML pages orthat the user must navigate through several pages to complete a single task (e.g.the task of booking a flight)

15

• Data Problems: traditional web applications do not support exploring the datainteractively. Usually, the user must find the desired data from the hypertextusing input forms. The complexity of the data shown to the user would reduce ifsome effective data visualization and interactive manipulation would be used.

• Configuration problems: often web applications let the user to configure a prod-uct or a system, but is unable to present a visual and intuitive picture of custom-build product. (e.g. ordering customized product from a web service).

• Feedback Problems: highly interactive web applications must be able to respondto user input and be able to change their state or interface without the need fora full-page refresh or interruptive communications with a server (e.g. games).These capabilities are quite limited with traditional web applications.

Common features required from web applications are the following: the presenta-tion capabilities must enable behaviours like drag-and-drop and effective integrationof audio and video. Animated vector graphics should be provided to enable a userinterface that closely matches native applications. An integrated interaction modelbetween server and client to improve real time communication must be provided. [2]

2.5. Characteristics of rich internet systems

2.5.1. Characteristics of Rich Internet Applications

According to Preciado et al., current web, Multimedia and Hypermedia methodologiesof web engineering community are incomplete and unable to respond to the new func-tionalities that users need [15] . Jeremy Allaire from Macromedia introduced the term"Rich Internet Application" (RIA) to overcome the drawbacks of both desktop and webapplications. RIAs are proposed as a solution to answer the needs of the users. Nor-mally, RIAs are loaded with some initial data by the client. Then, the RIA can managedata rendering, event processing and communication with the server only when it isrequired by the application. There are several directions and technologies to extendthe interactivity in web applications by running part of the application in the client.According to Bozzon et al., the technologies are classified into four categories: [9]

• Scripting-based in which the client side logic is implemented via scripting lan-guages, such as JavaScript, and interfaces are based on a combination of HTMLand Cascading Style Sheets (CSS). CSS is used to describe the style of a docu-ment written in a markup language, such as HTML.

• Plugin-based, where advanced rendering and event processing are granted bybrowser’s plugins interpreting XML, general-purpose programs or media files(Flash, Flex, Laszlo, Xamlon)

• Browser-based, where rich interaction is natively supported by some browsersthat interpret declarative interface definition languages. For example XML UserInterface Language (XUL).

16

• Web-based desktop technologies in which applications are downloaded from theweb but executed outside the browser (Java Web Start, Window Smart Client).

Preciado et al. present the general requirements for RIA as listed parameters inTable 2.1. [15]

Table 2.1. RIA parametersInteraction Possibility to specify the user (active)

behavioursMultimedia Possibility to support the representation of

graphics, audio, video, streaming and livemultimedia

Tool CASE Availability of a Computer-Aided Software Engineering(CASE) tool supporting the methodology

Visual Possibility to avoid screen refreshments andContinuity blink experiencesSynchronization To provide an active (related with user

interaction) and a passive (related with predefinedbehaviours) representation of interface elements

N-Tier Possibility to provide separate layersdevelopment for applicationsDynamic data Possibility to carry data to/from the server atretrieval run timeParallel requests to Possibility to retrieve data from one or moredifferent sources simultaneous sources, both in a synchronous

and asynchronous wayPersonalization Extensions for internationalization and localization,

accessibility, multi-device access, etc.Interactive It allows real-time interactive collaborationcollaboration between different users in order to work

together on the same task.

Potential of RIAs comparing to traditional web applications and desktop applica-tions (including client-server capabilities) are presented in Table 2.2. RIA is usuallydistributed through web and it offers improved interfaces allowing embedding audio,video and other media contents, for example under one plug-in installation (such asFlash Player). RIA also reduces communication overhead by avoiding continuous webpage refreshment. Therefore, RIAs can provide better data sorting, filtering, complexvisual rendering, etc. [9, 15]

17

Table 2.2. Comparison of Desktop, traditional web applications, and RIAsFeature C/S, Web RIA

DesktopUniversal client (browser) NO YES YESClient installation Complex Simple SimpleInteraction capabilities Rich Limited RichServer-side business logic YES YES YESClient-side business logic YES Limited YESFull page refresh required NO YES NOFrequent server round-trips NO YES NOServer-to-client communication YES NO YESDisconnected functioning YES NO YES

2.5.2. Examples of web technologies

RIA tools

There are several different web development techniques that can be used in designinginteractive and animated web applications. Most of these techniques consist of someobject oriented scripting language and some web modelling language. The followinglist contains some of the known web technologies:

• Curl is for designing interactive web applications. Among other techniques,Curl combines HTML and JavaScript. JavaScript is an object oriented program-ming language, which is good for creating functionality for the web application.HTML again is easier for designing the layout and the format of the web appli-cation. [16]

• Ajax is a group of interrelated web development techniques used to create inter-activity on web applications. Ajax itself is not a technology at all, but a groupof technologies. For example, JavaScript, HTML and XML belong to thesetechnologies. [17]

• JavaFX is a software platform, which enables developing rich internet appli-cations. Using JavaFX developers can build and deploy JavaFX applications,which are supported in any computer or device that has Java enabled. JavaFXapplications are developed using JavaFX scripting language. [18]

• Flash platform is a technology owned by Adobe Systems that is used to create in-teractivity and animation on web applications. Flash applications are developedcombining MXML and ActionScript programming languages. MXML languageis a modelling language based on XML. MXML is used to design the layout ofthe web application. Although functionality can be implemented using MXMLas well, ActionScript is more suitable for designing complex functionality. [19]

There are a lot of similarities in all technologies mentioned above. The Flash tech-nology will be studied further. Flash was originally introduced by Macromedia, but

18

nowadays it is owned by Adobe Systems Inc. Flash has several features that answer theneeds of the users for rich internet applications. Flash combines streaming animation,vector-based graphics, and ActionScript for creating multichannel accessible and in-teractive content. All Flash content is eventually published to Shockwave Flash (SWF)file which is a repository object that can be presented by the Flash Player. [19, 20]

The SWF files can be embedded in a server-side language document, such asHTML [21] . Browsers treat an SWF file as any other embedded object on the webpage and displays it by using Flash Player [21] . Besides Adobe, there are also severalother entities providing Flash Players for displaying SWF content [22] .

Different web applications, like Flash applications, can be developed by using an In-tegrated Development Environment (IDE) [23] . Software development of applicationscan be eased by using an IDE which enables the use of different individual tools fromone development platform [23] . Adobe Systems provides IDEs, like Flex Builder,for developing Flash applications [21] . Open Source Flash (OSFlash) community hasseveral open source alternatives providing Flash IDEs (e.g. Ajax Animator) [22] .

Media servers and Real-Time Messaging Protocol

Media servers are servers that are used in storing media content for internet applica-tions. Media servers are usually open socket servers. The main difference betweenopen socket servers and normal web servers is that as soon as information from a nor-mal web server is received, the connection is closed. Especially with RIAs, it may looklike one is still connected to the web server because the data sent from the server mightcontain animated and interactive content. Actually, the connection is closed right afterthe web server sends the page with all associated data and one’s computer sends backa response that says the data has received. [24]

With an open socket server, the connection stays open until the application termi-nates the connection. Therefore, audio, video, text, and any other data can be streamedin real time. Real-Time Messaging Protocol (RTMP) has been developed by AdobeSystems for streaming audio, video and other data over the internet between AdobeFlash Platform technologies, such as Flash Player and Flash Media Server (FMS).When using RTMP, the web application first connects to a web server via HTTP andthen to a media server using RTMP. Hence, the web application is using simultaneouslytwo different protocols: HTTP for web site and RTMP for streaming media. [24]

Adobe has opened the RTMP as an open specification for development communitiesto create products that enable delivery of Adobe Flash Player compatible audio andvideo formats [25] . For example, OSFlash community has several different opensource Flash projects [22] . Adobe Systems provides a commercial RTMP server calledFlash Media Server [24] . OSFlash community has an open source project called Red5,the target of which is to implement an open source RTMP media server written inJava [22] .

19

3. PEER-TO-PEER NETWORKING

3.1. Definition of Peer-to-Peer

Peer-to-Peer (P2P) in short means direct connection between two peer computer with-out a central server or authority. Usually, the terms "node", "peer" or "user" are used torefer to the entities connected in to a P2P network. The most distinctive difference be-tween traditional client/server and P2P architecture is the concept of peers in a networkacting as servers and clients. The term servent, which derives from a combination ofthe terms server and client, is used to describe such an entity. [26, 27]

The most important P2P applications that have received considerable research atten-tion are used for content distribution. Typically, content distribution applications allowpersonal computers to function as distributed storages by contributing digital contentto other computers in the network in a coordinated manner. [26, 27]

P2P is not only about content distribution and file sharing. P2P architectures aredesigned for the sharing of distributed computer resources by direct exchange, ratherthan requiring the intermediation or support of a centralized server or authority. Sharedcomputer resources can be for example content, storage, Control Processing Unit(CPU) cycles or network link capacity. In P2P architecture, the nodes are distributedand are not dependent on each other. Because of the distributed nature of the P2P archi-tecture, the P2P system is able to adapt to failures and accommodate transient popula-tions of nodes while maintaining acceptable connectivity and performance. Examplesof such distributed computing systems are Napster, Gnutella, Seti@ sharing Home,OceanStore and many others. [26, 27]

The motivation for using P2P architecture in applications derives from their abilityto function, scale, and self-organize in the presence of a highly transient populationof nodes, network, and computer failures. Also, the P2P system is not dependent ona central server. Therefore, a P2P system overheads its administration much less thantraditional web architecture. P2P architectures typically have scalability, resistance tocensorship and centralized control, and increased access to resources. Hence, also re-sponsibility of the administration, maintenance and even the ownership of P2P systemsare usually distributed among the users, instead of a single company or person. [26, 27]

There are several different definitions of P2P, which all usually have quite a lot ofsimilarities. One of the definitions of P2P is proposed by Rüdiger Schollmeier: "Adistributed network architecture may be called a Peer-to-Peer (P-to-P, P2P,...) network,if the participants share a part of their own hardware resources (processing power, stor-age capacity, network link capacity, printers,...). These shared resources are necessaryto provide the Service and content offered by the network (e.g. file sharing or sharedworkspaces for collaboration). They are accessible by other peers directly, withoutpassing intermediary entities. The participants of such a network are thus resource(Service and content) providers as well as resource (Service and content) requesters(Servent-concept)." [26]

20

3.2. Classification of Peer-to-Peer architectures

According to Theotokis et al., P2P architectures have been divided into a variety ofdifferent application categories listed below: [27]

• Communication and Collaboration. Systems that provide the infrastructure forfacilitating direct, usually real-time, communication and collaboration betweenpeer computers belong to this category, for example, chat and instant messagingapplications such as Chat/Irc, Instant Messaging (Aol, Icq, Yahoo, Msn), andJabber.

• Distributed Computation. This category includes systems that take advantage ofthe available peer computer processing power (CPU cycles). Computer intensivetasks are divided into smaller work units and distributed to different peer comput-ers. After the corresponding work units are executed in the peer computers, theresults are sent back to the peer that originally sent the request. Central coordi-nation is needed for dividing and distributing the tasks and collecting the results.Examples of distributed computation systems are Seti@home, genome@home,and others.

• Internet Service Support. Systems in this category are emerged for supportinga variety of internet services. For example, P2P multicast systems, internet in-direction infrastructures, and security applications, providing protection againstdenial of service or virus attacks.

• Database Systems. According to the Local Relational Model (LRM), all the datastored in P2P network is assumed to be comprised of inconsistent local relationaldatabases interconnected by sets of “acquaintances” that define translation rulesand semantic dependencies between them. Another example of a Database Sys-tem introduced in Theotokis et al. study is "PIER". It is a scalable distributedquery engine built on top of a P2P overlay network topology. It allows relationalqueries between thousands of computers in overlay network.

• Content Distribution. Currently, most of the Peer-to-Peer systems belong to thiscategory. These systems are designed for the sharing of digital media and otherdata between users. Content distribution systems vary from simple file sharingapplications to more complex systems that create a distributed storage mediumfor secure and efficient publishing, organizing, indexing, searching, updating,and retrieving of data. Some examples of such systems are the late Napster,Publius, Gnutella, Kazaa, Freenet, MojoNation, Oceanstore, PAST, Chord, Scan,FreeHaven, Groove, and Mnemosyne.

3.3. Characteristics of Peer-to-Peer system

3.3.1. Degree of centralization

The operation of P2P system relies on a network of peer computers and connectionbetween them. The network lies on top of a physical computer network, which is

21

typically Internet Protocol (IP) network. Therefore, the P2P network is referred as"overlay" network. In the purest, P2P overlay network should be totally decentralized,but in practice this is not always true. Overlay networks are distinguished according totheir structure and degree of centralization. These characters affect P2P systems oper-ability since they affect its fault tolerance, self-maintainability, adaptability to failures,performance, scalability and security. [26, 27]

P2P systems are divided into subcategories according to the centralization level andstructure of the P2P overlay network. According to Rüdiger Schollmeier’s subdefi-nitions of different P2P systems, they are distinguished between "pure" and "hybrid"P2P networking concepts. In a "pure" P2P system, all the central entities in the networkare forbidden and the system must not suffer any loss of network service, whereas a"hybrid" system requires a central entity to provide some parts of the offered networkservices. [26] A more accurate categorization of P2P overlay network centralizationlevels is given in Theotokis’ study. He identifies the following three categories. [27]

Purely decentralized architectures

This ideal P2P architecture model is completely independent of central coordinationsince all the nodes, acting as servers and clients (servents), perform all the requiredtasks in the network. Gnutella is an example of a purely decentralized architecture.Figure 5 illustrates an example of Gnutella network architecture. [27]

Figure 5. Gnutella network architecture.

Gnutella builds a virtual overlay network allowing its users to share files with otherpeers. After joining the network, a node identifies itself with nodes it is connected to.To locate the required file, the servent sends a query to all its neighbours in Gnutellanetwork and each node forwards the query to all neighbours. The response messagesare routed back along the opposite path. To reduce the spread of messages through thenetwork, each message contains a Time-To-Live (TTL) information. After every for-ward, the TTL value is decremented, and when it reaches zero, the message is dropped.When the target file has been identified at a certain node, the node that sent the requestinitiates a download by establishing a direct connection between itself and the nodecontaining the data. [27, 28]

22

Partially centralized architectures

The basic idea of the systems in Partially Centralized Architectures category is similarto the one in purely decentralized architectures. However, some of the nodes, termed assuper peers, have a more important role than other peers. Supernodes are acting as localcentral indexes for files shared by local peers. However, the operability of the networkmust not rely on a single supernode. Therefore, network must be able to assign newsupernode dynamically if one supernode fails to achieve the task it is working on. Theway how supernodes are assigned varies between different P2P systems. One exampleof partially centralized architecture is Kazaa. [27, 29]

Main advantages of partially centralized systems in comparison to purely decentral-ized are that discovery time is reduced and most of the workload can be handled bythe supernodes, whereas nodes with less CPU power, bandwidth or storage capabilitieshave less workload. Figure 6 illustrates an example of partially centralized architec-ture. [27, 29]

Figure 6. Partially centralized network architecture.

Hybrid decentralized architectures

Systems in the Hybrid Decentralized Architectures category have a central server fa-cilitating the interaction between peers. A central server maintains directories of meta-data, which contain information about the shared files stored by each peer. Hence, thecentral server is a single point of failure and the system is vulnerable to censorship,technical failure, or malicious attack. However, peer nodes are in direct interactionbetween each other when exchanging files, for instance. The central server performsthe lookups and identification of the nodes storing the required resources. Therefore,locating the required resource is fast and efficient. [27]

Figure 7 highlights the architecture of a typical hybrid decentralized P2P system.Every client computer stores the content shared with the rest of the network. Eachclient connects to a central directory server. The central directory maintains the re-

23

quired information of each user of the network and the information of the content usersare storing. The client requests certain files from the central server, which respondswith a list of peers storing the requested content. Then, the client opens a connectionbetween one or more peers holding the requested content and downloads it. Napster isan example of a hybrid decentralized architecture. [27]

Figure 7. Hybrid decentralized network architecture.

3.3.2. Overlay network structure

Structure of the overlay network reveals whether it is created non-deterministically asnodes and content are added or whether its creation is based on specific rules. There-fore, networks are categorized in terms of their structure as unstructured and structurednetworks. [27]

In unstructured P2P networks, the placement of the content is completely unrelatedto the overlay topology and the content typically needs to be located. There are dif-ferent search mechanisms, ranging from brute force methods to more sophisticatedand resource-preserving strategies. In brute force methods, the content is locatedpropagating queries randomly to the peers in the network until the correct content isfound. In more sophisticated search methods, the search mechanism selects to whichneighbours the queries are forwarded based on some logic. Unstructured systemsare usually more appropriate for accommodating highly-transient node populations.Examples of unstructured systems are Napster, Publius, Gnutella, Kazaa, Edutella andFreeHaven. [27]

Structured systems have emerged mainly in an attempt to improve the scalabilityissues that unstructured systems were originally faced with. Structured networks havetightly controlled overlay topologies and files (or pointers to them) are placed at pre-cisely specified locations. Structured systems provide a mapping between content (e.g.file identifier) and location (e.g. node address), in the form of a distributed routing tableto route queries efficiently to the nodes with the desired content. [27]

24

A disadvantage of structured systems is that it is difficult to maintain the structurerequired for efficiently route messages in a very transient node population, where nodesare joining and leaving at a high rate. Examples of structured systems in Theotokis etal. study are for example Chord, CAN, PAST and Tapestry. Chord, CAN, PAST andTapestry are also the names used for the lookup algorithms for finding the nodes in astructured systems. The term "loosely structured systems" is used for the systems thatare a combination of structured and unstructured systems. [27]

3.3.3. Distributed Hash Table algorithms

Structured P2P systems without any centralized servers or hierarchy require some kindof mechanism for controlling content placement and routing. Several research groupshave presented a simple and general interface, a Distributed Hash Table (DHT). Dataitems are inserted in a DHT and found by defining a unique key for that data. Toimplement DHT, the underlying algorithm must recognize which peer is responsiblefor storing the data for a corresponding key. Therefore, each peer maintains contactinformation of a small number of peers ("neighbours") in a routing table. Such peersform an overlay network. Messages to store and retrieve keys are routed between peersin overlay network. [30]

A DHT implements only one operation: lookup(key) returns the identity (e.g. IPaddress) of the node currently responsible for a given key. Basically, the main require-ments are that data can be identified using unique numeric keys, and that users arewilling to store keys for each other. A simple distributed storage application could usethis interface as follows: the user who publishes a file under a particular unique nameconverts the name to a numeric key using some hash function, then calls lookup(key)and sends the file to the resulting node. Someone who wants to read the file, convertsthe name to a key, calls lookup(key), and requests the resulting node for a copy of thefile. [30]

There are substantial differences between the ways DHT algorithms build and main-tain their routing tables as nodes join and leave. Examples of DHT technologies usedin Peer-to-Peer networking are CAN, Chord, Pastry and Tapestry. The following issuesmust be addressed when implementing DTH-algorithm: [30]

• Keys must be mapped to nodes in a load-balanced way. Basically, all algorithmsdo this in the same way. Nodes and keys are mapped using a hash function intoa string of digits. Hashing the key to a given digit string is then assigned to thenode with the “closest” digit string in question (e.g. the one that is the closestnumeric successor to s, or the one with the longest matching prefix).

• Any node that receives a query for a key identifier X must be able to forwardit to a node whose ID is closer to X. To do this, each node maintains a routingtable with entries for a small number of other nodes. This method guarantiesthat eventually the request arrives at the closest node. There are differences inthe ways the forwarding is made between different algorithms.

25

• As mentioned above, to forward lookup messages, each node must build andmaintain a routing table containing identifiers of some other nodes selected by amechanism defined by the corresponding DHT algorithm.

3.4. Peer-to-Peer Session Initiation Protocol

3.4.1. Session Initiation Protocol

Session Initiation Protocol (SIP) is an application-layer signalling protocol for con-trolling, creating, modifying, and terminating sessions with one or more participants.These sessions can be for example internet telephone calls, multimedia distribution,or multimedia conferences. SIP is standardized by Internet Engineering Task Force(IETF). [31]

SIP sessions between users are created by sending invitations that carry descriptionof the session. SIP uses elements called proxy servers (also called SIP proxy) to routerequests to the user’s current location. SIP proxy also provides functionality, suchas registration, authentication and authorization of the users for the services. SIP isdesigned to be independent of the underlying transport protocol layer. [31]

Typical elements of the SIP network are SIP User Agent (UA), SIP Proxy Server(PS), SIP Registrar server, and SIP Redirect server. These are described below withmore details: [32, 33]

• SIP UAs are the applications that react to one another. When a dialog is estab-lished, UAs communicate with other UAs. It can reside in the user’s computeror in a server. There are two separate parts in UA, User Agent Server (UAS)and User Agent Client (UAC), both providing different functions. UAC is theoriginator of the SIP sessions. It establishes a dialogue and maintains that dia-logue with the destination user agent. UAS is the recipient of the request madeby UAC. UAS responds to requests from UACs.

• SIP PS is one of the main elements in SIP network. It is responsible for forward-ing the SIP requests to the target UAS or another proxy on behalf of the UAC.Proxy provides the routing function in SIP network.

• SIP Registrar server authenticates and records the current location of the UA.The device where UA is locating sends its new location information to the SIPregistrar when the location is changed. The location information is saved tolocation database or location server.

• SIP Redirect server is used to provide an alternative address for a SIP request.The reason why alternative address is needed might be for example load balanc-ing between the proxies routing the requests.

3.4.2. Session Initiation Protocol with Peer-to-Peer networking

Recently, using Session Initiation Protocol (SIP) in serverless environment has re-ceived a lot of attention in research communities and technology industry. [3] IETF

26

has established a working group called Peer-to-Peer Session Initiation Protocol WorkGroup (P2PSIP WG). The target of the P2PSIP WG is to develop protocols and mech-anisms for the use of the SIP in environments where the service of establishing andmanaging sessions is principally handled by a collection of intelligent endpoints, ratherthan centralized servers as in SIP as currently deployed. [34]

The Peer-to-Peer overlay would consist of P2PSIP peers and P2PSIP clients. P2PSIPclients would act very much like SIP UAs. P2PSIP peers would act as super nodes.The super node, similar to the SIP registrar and proxy server, locates other users bycommunicating with other super-nodes. The idea is that the node which has enough ca-pacity can become a super node. Figure 8 illustrates the difference between traditionalclient/server SIP and P2PSIP network architectures. (Figure 8a). Figure 8b presentsa P2PSIP network architecture where the traditional SIP network is transferred moreinto a P2P networking-like architecture. [35]

(a)

(b)

Figure 8. (a) Traditional client/server SIP network architecture. (b) P2PSIP networkarchitecture.

27

4. DEVELOPMENT OF THE PEER-TO-PEER SOLUTION

4.1. Defining the Peer-to-Peer service

The objective of this thesis was to implement a platform independent web applicationwhich uses standard P2PSIP network. It would be the first platform independent pro-totype application using the standard P2PSIP overlay network. Another objective ofthe design of the web application was that it does not require any separate installationactivities from the user. The web application was needed for demonstration purposesin the Decentralized Inter-Service Communications (DECICOM) project. [36]

DECICOM focuses on the research and development of technology enablers fordistributed mobile applications and services, and the new business scenarios aroundthem. DECICOM provides a communication framework for P2P and hybrid P2P-Client/Server communication systems. The project aims to influence global standard-ization of the essential enabling technologies for P2P systems in a concrete man-ner. [37]

MediaTeam from the University of Oulu and Networking Laboratory from theHelsinki University of Technology are the research partners of the DECICOMproject [37] . Industrial and financing partners of the DECICOM are: Nokia Re-search Center, L M Ericsson, Nethawk, Futurice, Icecom and TEKES. This studywas assigned and implemented in co-operation with MediaTeam Oulu and L M Er-icsson. [36]

Among other studies, the DECICOM project has developed several prototypes ofP2P applications. Most of them are mobile P2P solutions developed for Symbian basedS60 or Linux based Maemo application platforms. The earlier studies have proved thefunctionality of the P2P networking. However, they are not using the standard P2PSIPoverlay network. [37]

The earlier prototypes were also developed to support only a specific operating sys-tem or an application platform as native applications [37] . Every time such a solutionis ported on a different application platform or an operating system, new developmentefforts are required. One of the targets of the RIAs is multichannel accessibility. Theusers with ubiquitous access to network use web services with various devices and var-ious operating systems. With existing solutions, for example, a prototype implementedfor Symbian S60 mobile phone cannot be used by a user with a desktop computer thathas Windows operating system. [38]

Users face practical problems when they start using a new system or service. Noviceusage is an important and growing theme in Human-Computer-Interaction (HCI). Es-pecially in the last decade since home has increasingly become as a networked entitywith various connected devices and services. Therefore, Out-Of-Box Readiness (OBR)is another important goal to achieve in the design of the web service. The term OBRis used by a manufacturer to develop as good Out-Of-Box Experience (OOBE) for theuser as possible. OOBE means how the user experiences a new product, in this case, aweb application. [39]

The operating system dependent native P2P application prototypes developed earlierby DECICOM project must be installed separately by the user. That was seen as aweak point since it degrades the OOBE of the service by making the mobilization ofthe service more difficult [40] .

28

4.2. Technical design

4.2.1. Objective of the design

The kick-off meeting for the development part of the thesis was arranged between L MEricsson and MediaTeam Oulu. In that meeting, it was agreed to develop an applicationrunning on top of a web browser that uses a P2PSIP overlay network.

The main options for the technology platform to be used in the development wereAjax (JavaScript based) and Flash (ActionScript based). The web browser plugin basedFlash technology was agreed to be used to develop the solution. The main reason forthis was that the Flash supports TCP socket connection, whereas the Ajax does not.The basic technical functionalities that the prototype web application must be able touse, when interacting with the P2PSIP overlay, are storing and retrieving data from theoverlay and an ability to connect to a peer in the overlay. Connection to peers in theoverlay is made using TCP socket connection.

The basic technical functionalities required from the overlay are listed above. Theplan was that the prototype web application uses the P2PSIP overlay through theP2PSIP Application Interface (API). L M Ericsson was responsible for implement-ing the P2PSIP API, which provides the basic functionality to communicate with thestandard P2PSIP overlay network. It was agreed that the prototype web applicationshould enable VoIP (Voice over Internet Protocol) and basic Instant Messaging (IM)functionality between users. Practically IM means chat.

4.2.2. Development tools and environment

Flash

The Flash technology was selected as the technology to develop the web applicationfor this project. The main reason for this was that Flash is considered as the mostpopular technology in web application development. Therefore, it was known that thenumber of the Flash developers is high. [20] Also, unlike Ajax, Flash platform sup-ports TCP socket connection, which was needed to get the application use the standardP2PSIP overlay network. [17] What is more, animated graphical examples of Flashapplications could be found from several web domains. In prototyping phase, it waseasily proven that, with Flash technology, the basic use cases, such as VoIP and IM,were straight forward to implement. [19]

Adobe Flex 3 is a Software Development Kit (SDK) for development and deploy-ment of Flash rich internet applications. [20] Flex 3 SDK is released under the opensource Mozilla Public License (MPL) [41] . Flex Builder 3 is an IDE which enablesvisual design of Flash applications. Flex Builder 3 requires a license from AdobeSystems. Current Flash applications are coded using MXML and ActionScript 3.0 pro-gramming languages. Such applications are also called as Flex applications. MXMLis an XML based declarative markup language and it is used to display the layoutof the Flex applications. Also interactivity and functionality can be developed usingMXML language, although most of the interactivity is usually developed using Ac-tionScript. [19]

29

ActionScript 3.0 is an object oriented programming language for creating applica-tions. However, ActionScript and MXML languages are combined in Flex and both ofthem have their benefits. MXML is easier for designing layout, while ActionScript isbetter for designing business logic. All MXML code is converted as ActionScript codein compilation. MXML documents are essentially ActionScript classes. ActionScriptapplications are compiled and built to a Shockwave Flash (SWF) files. A SWF file cancontain animated vector graphics and functionality. [42]

SWF files are also called as Flash movie files and they can be replayed by the FlashPlayer. It is also possible to add video in SWF files. The format of the Flash videofiles is FLV. An FLV file must be imported to a Flash document file, which will becalled as an FLA file. They all are published as SWF files. However, there is also anoption to replay an external video from Flash application. This is an advantage, sinceembedding the video in the SWF file significantly increases the size of the file. TheFLV or H.264 video container file can be loaded by the SWF file at runtime. Thathappens for example when the web page loads or playback is separately initialized byActionScript command from the web application. [43] H.264 is also a standard forthe coded representation of visual information. H.264 is also known as MPEG-4 AVCformat. [44]

The Flash Player is a browser plugin, which can replay SWF files from web sites.It means that Flash Player executes the Flash application and displays and renders thevisual and interactive content. The Flash Player supports the majority of operatingsystems and browsers. There is also Flash Lite player for mobile phones. However,it is important to notice that all the Flash applications cannot be replayed with everyFlash Player. [19]

For example Flash Player version 9 and the newer ones have two separate Action-Script Virtual Machines (AVM1 and AVM2). AVMs execute technically the Flashapplications. Dual AVM architecture is designed to support Flash applications imple-mented for old versions of Flash Player. AVM1 executes Flash applications designedfor older Flash Players. AVM2 is designed fundamentally in a different way thanAVM1 and it executes the Flash applications made for newer versions of Flash Player.Older versions of Flash Players have only AVM1. Therefore, Flash applications thatare designed for the latest Flash Players cannot be executed in old Flash Players. [19]

The latest version of the Flash Player is version 10. All Flash applications designedfor Flash Player 10 do not work in Flash Player 9 if new functionality designed forversion 10 is used. However, Adobe estimates that each new version of the Flash Playerhas been adopted in more than 80 percent of the computers in less than a year afterpublishing. [20] Compatibility is still a problem in devices that do not support the latestversion of the Flash Player, for example in mobile devices. New Flash applicationsdeveloped in ActionScript 3 are not supported by the Flash Lite player. Also, the latestLinux based mobile devices like Nokia N900 (built on top of Maemo5) supports onlyFlash Player 9 [45] . Although, according to news in tech forums, Flash Player 10should be released in 2010 for Linux based mobile platforms, such as Android 2.0 [46].

Real-Time Messaging Protocol (RTMP) supports real time communication betweendifferent Flash platform technologies. However, currently it does not support directconnection between two Flash Player applications. Adobe has published a projectcalled Stratus which should support sending real time data from a Flash client to

30

another. Stratus project is still in beta phase and supported only in Flash Player 10.It also requires Adobe Flash Media Server (FMS) to work. [20] It was decided notto use the Stratus in this thesis. Therefore, an RTMP supported server is needed forhandling the real time communication between the web applications. [19]

Media server

Red5 media server was considered as the best option for handling the media serveractivities for the web application in this thesis. Red5 is an open source Flash serverimplemented in Java. Red5 supports open socket connection and RTMP protocol.Therefore, a continuous connection between the client and the server can be main-tained, which enables real time communication. Red5 open source project is hostedby Open Source Flash (OSFlash). OSFlash is an open source community hosting opensource projects for the Flash platform. [22] Red5 uses Lesser General Public License(LGPL) [47] . Among other features, Red5 supports features listed below: [22]

• Streaming audio and video (FLV, H.264, AAC, and MP3). The Red5 Flash servercan stream audio and video coming in and going out from the server.

• Recording client streams (FLV). This means that the Red5 Flash server can storeincoming FLV video stream.

• Shared objects. Shared objects can store data on the Red5 Flash server for otherclients to retrieve. The remote shared objects are stored in the Red5 server.Whenever a client makes changes to the shared object, the change is visible forother clients as well. It is possible to share data, such as IM, in real time usingremote shared objects. To use remote shared objects, the user must be connectedto the media server with the RTMP protocol.

• Live stream publishing. The Red5 Flash server is able to broadcast audio orvideo stream in real time for Flash clients.

• Remoting between a Flash client and the Red5 Flash server. The data exchangebetween the two entities must be done in Action Message Format (AMF). Thereare different versions of the AMF. The AMF 3 version is used with ActionScript3.0 and that is also supported in new versions of Red5 Flash server.

• Real-Time Messaging Protocol (RTMP). The RTMP is introduced by AdobeSystems and is used for real time communication between different Flash plat-form technologies, such as Flash Player and Red5 Flash server.

Also Adobe FMS supports RTMP and all the features in the web application shouldbe feasible to implement using FMS. Adobe FMS requires a license and Red5 is anopen source project. [24] Therefore, the main reason to select the Red5 server to beused in this thesis was that the chargeable license was not needed. [22]

31

4.2.3. Technical requirements

A more detailed way of making the VoIP and IM features for the web application wasdefined after a short study of existing Flash solutions that used some media serverfor connecting two Flash clients. At least one example of a basic VoIP Flash ap-plication hosted in Google Code community was found. The application was calledRed5Phone. Red5Phone enabled basic voice calls between two Flash clients using SIPconnection. [48]

Red5Phone is built on top of the Red5 server. The downside of the Red5Phone isthat it requires implementation of a web application residing on the Red5 server. Theapplication includes Flash part and SIP part. SIP part is needed to enable SIP con-nection between UAC and SIP proxy. The SIP part of the application is implementedin Java as a server side web application. Red5Phone Flash part used ActionScriptfunctionality to call methods in Java implemented SIP part. In the design of the P2Psystem of this thesis, it was already known that the Red5 media server was requiredfor connecting the Flash clients. However, we did not want the Red5 server to containa server side web application or business logic. Therefore, the Red5Phone conceptas such was not sufficient for this project. Figure 9 illustrates the architecture of theRed5Phone. Another example using Red5 server was Big Blue Button (BBB), whichhave much more functionality implemented than in Red5Phone. But the basic archi-tecture is similar to the one in Red5Phone and it also requires an extensions on top ofthe Red5 server. [48, 49]

Figure 9. Red5phone architecture.

However, it was noticed that opening a plain RTMP connection between two Flashweb applications also required a minimum web application on the Red5 server side.Unlike Red5Phone solution, the minimum server side web application did not requireimplementation of logic residing on the server. The server still must contain the basicconfiguration files that allow the Flash web application to connect to the Red5 server.Red5 stores all web application definitions as folders inside the “webapps” directory.

32

In order to create a new application, a new subfolder must be created beneath “we-bapps”. This folder should get the same name as the web application connecting to theserver. A “WEB-INF” folder must be created inside the new web application folder.Red5 documentation includes templates about the basic configuration files that mustexist in the "WEB-INF" folder. [22]

To enable RTMP connection between Flash clients, the contents of the configurationfiles could be minimal. The following basic configuration files can be found from eachRed5 server side web application: [22]

• web.xml. The main configuration file of the Red5 web application. To ensurethat Flash web applications are able to make RTMP connection to the Red5 webapplication, only the "WebAppRootKey" parameter is required. Basically, thatis a unique name of the web application.

• red5-web.xml. This is a Handler Configuration file. It defines the services andhandlers the web application is using.

• red5-web.properties. This file defines properties and is a configuration file forred5-web.xml.

After the Red5 server has been installed and the basic server side web applicationdefined with required configuration data, it is possible to create an RTMP connectionbetween Flash web application and Red5 server. With an RTMP connection to theRed5 server, a Flash web application can create remote shared objects. A shared objectcan store data on the server for other Flash clients to retrieve. The remote sharedobject can be for example a plain text field, which is used as an IM chat text field.When one user changes the chat text, it is updated for all the users connected to theobject in question. Another important feature for the prototype Flash application wasstreaming audio. After RTMP connection is established with the client and the server,the NetStream Class enables streaming real time audio through the Red5 server. [50]

The connection between the Flash client and the P2PSIP overlay network is estab-lished using TCP socket connection. Socket class enables ActionScript to make socketconnections and to read and write raw binary data. P2PSIP API creates the connectionand handling of the communication between Flash application and peers in the P2PSIPoverlay. [50]

4.2.4. Basic architecture of the system

After studying the technical capabilities of the Flash technology platform and Red5server, the high level architecture of the P2P system was defined. The functionalitiesrequired by the system were prototyped and proven doable. Figure 10 illustrates thehigh level system architecture.

33

Figure 10. High level system architecture.

As described in Figure 10, the clients may vary from a PC computer to a FlashPlayer supported mobile device. The basic idea is that the Flash application (the SWFfile) resides in a HTTP server and can be connected by any device containing a webbrowser. The SWF file is downloaded by the web browser and replayed by the FlashPlayer (1.). Then, the Flash application and the logic behind that are executed locallyby the user and the network traffic is minimized, which is one of the basic ideas ofRIAs.

When logging in the service, Flash application establishes TCP socket connectionto a peer in the P2PPSIP overlay network using P2PSIP API (2.). When connection isestablished, the Flash application can store and retrieve data from the overlay network(3.). Key/value pairs are used to store data in the overlay network. As it was agreed, thecommunication between Flash applications will happen through the RTMP supportedRed5 servers. Therefore, the Flash application must open an RTMP connection withan available Red5 server as well (4.). At its simplest, the overlay network contains thelist of available Red5 servers. When the client connects to the overlay, it can requestfor a free Red5 server address 3.) and connect to it. The overlay network also storesthe information about which Red5 server each user is connected to.

Hence, when the user A wants to connect with user B, user A can ask if user B isconnected or not and what Red5 server user B is using (3.). After that user A canestablish an RTMP connection to the same Red5 server as user B and open a real timecommunication channel between two users (5.). As described in the fiugre 10, Red5server can be installed to a peer computer or some other computer outside the overlaynetwork. Any peer computer might act as a client and peer. Naturally, the devices inthe overlay network must contain the P2PSIP peer capabilities, such as DHT algorithm

34

and capability to maintain data stored to the overlay network. Therefore, acting as apeer requires installation of additional SW to the computer.

4.3. Implementation

4.3.1. Objective of the implementation

More specific functional requirements for the web application were defined accordingto the high level architecture defined in the design phase. Regarding high level designand prototyping using Flash applications and Red5 Flash server, it was proved that thedesired system should be possible to implement.

The definition of the P2PSIP API was started at the same time as developing theFlash web application. The main part of the Flash application development was madewith the P2PSIP API emulator, which was called the dummy P2PSIP API. The actualoverlay network did not exist, but the emulator simulated the operations of the overlaynetwork. Therefore, it was known that the first definitions of the API might change asthe development work proceeds.

The list of functional requirements from the user perspective was defined more ac-curately before starting the actual implementation. A classification was given to eachhigh level requirement according to the importance of each requirement. The classi-fications were used as defined by the IETF Request For Comments (RFC) document2119. Capital letters are used in classification keywords to distinguish them from othertext. In short, "MUST" classification for a requirement means that it is absolute andmust be fulfilled. "MAY" stands for "optional", meaning that the requirement is trulyoptional. The high level functionality requirements are listed in Table 4.3. [51]

Table 4.3. Functional requirements of the Flash application# Requirement Level1 Intuitive and animated GUI MUST2 VoIP call between Flash clients MUST3 Instant Messaging (IM) functionality between Flash clients MUST4 Shared calendar MAY5 File sharing MAY

It was expected that the P2PSIP API will probably not stay unchanged. Also thefunctional requirements listed in Table 4.3 were defined only in a high level beforestarting the implementation. The definition of the UI was done during the imple-mentation work too. Hence, agility was required from the way of working and thedevelopment tools used in this thesis. Those issues were taken into account when thetechnology and the tools were selected. In addition, the high level system architecturewas designed to be quite flexible to allow changes in the implementation.

35

4.3.2. Implementation of the application

Overview

The UI flow of the web application was constructed using Flex Builder 3. Flex Builderhas a powerful GUI design tool, which generates the MXML code automatically.Hence, customizing the GUI and making changes during the development was easy. Ascreenshot of the GUI design tool is illustrated in Figure 11.

Figure 11. Flex Builder 3 GUI design tool.

The Unified Modelling Language (UML) was used to describe the functionality ofthe application. UML is a modelling language that is used to specify and visualizesoftware systems. [52]

The final UI flow of the application is described in the UML state diagram in Ap-pendix 1. The UI consists of only two main UI components: the "main view" andthe "communication view". From the "main view", the user can arrange contacts andstart the "communication view" with a desired contact. From the communication view,the user can chat and call her friends. Functionality of the GUI can be seen moreaccurately from the screenshots in Chapter 5.

36

Used classes

The UML class diagram of the application can be seen from Appendix 2. The func-tionality of the application consists of three main parts: RTMPchat main application,ChatMngr and VoipMngr classes. The P2PSIPClient class is the interface between theGUI part of the application and the P2PSIP overlay network. The interface is alsocalled as P2PSIP API in this thesis.

The RTMPchat class includes all the methods controlling the UI of the application.The interactive UI components, for example buttons implemented in MXML, call theActionScript methods. The methods are listed in the class diagram (Appendix 2).

The objects of other three classes are introduced in the main application and in-stances of those are created to enable communication with the other users. As men-tioned above, the P2PSIPClient class is the interface between the main application andthe P2PSIP overlay. The user can request the information of the other users throughthe P2PSIPClient class. This application stores the online statuses and the Red5 serveraddresses to the overlay. Also, the list of all the users of the service and the personalcontacts of each user are stored to the overlay network.

Mainly the get and put functions of the P2PSIP API are used in this application. Getis used to retrieve data from the overlay network. Default responsehandler functionis called as a callback function for each get, unless the developer defines a specificresponsehandler function. The specific responsehandler function can be defined ineach get request separately. The responsehandler function is called after the request ishandled. The responsehandler function receives the requested key and correspondingvalue as parameters. Put function is used to store data to the overlay network. A moreaccurate description of the public functions of the P2PSIP API is given in Appendix 3.

After receiving contact information from the overlay through the P2PSIPClient re-sponsehandler functions, the user can communicate with the other users using ChatM-ngr and VoipMngr classes. The real time communication is done using RTMP connec-tion through the Red5 server. Classes use remote shared objects residing in the Red5server and audio streams through the Red5 server to communicate with each other.

Sequence diagrams

Intercommunication between classes is described in the UML sequence diagrams inAppendices 4- 9. All needed operations to understand the functionality of the applica-tion are shown in those sequence diagrams.

The first sequence diagram in Appendix 4 illustrates the login process, which estab-lishes the required connections, which are the TCP socket connection to the P2PSIPoverlay and the RTMP connection to the available Red5 server. The shared objects toenable the real time communication between users are also created. The event listen-ers are initialized to react in case another user contacts using chat or VoIP. After loginprocess, the application is ready to communicate with the other users and is shown as"online" user.

Maintaining the lists of the other users is shown in Appendix 5. A list of all usersand a list of personal friends of each user are maintained in the P2PSIP overlay. Theapplication updates both lists when the user changes the personal contact list. The ap-

37

plication also synchronizes the list of users in every ten seconds and after a successfullogin.

Appendix 6 shows how the user is kept logged in. The Put function of the P2PSIPAPI gives a possibility to define a Time-To-Live (TTL) parameter for the key/valuepair stored to the overlay. User information is stored to the overlay using the usernameas a key and used Red5 server address as a value. When the user logs out from theservice, the username key is removed from the overlay. However, if the user closesthe web browser before logging out properly, the stored username key is not removedfrom the overlay. Therefore, a TTL value is given as a parameter when the usernameis stored to the overlay using the put function. The keepLoggedIn timer mentioned inAppendix 6 makes sure that the username key is stored to the overlay every time beforethe TTL goes off. If the user closes the browser or for example the network connectionis lost suddenly, after the TTL period, the user is shown offline for the other users.

Appendix 7 illustrates the situation when the user opens a communication with afriend who is online. First, the application asks the address of the Red5 server thefriend is using. After that, the availabilityCheck function is used to check that the useris not communicating with someone else. If the user is available, the caller connectsto the callee’s shared object and sets the friend and herself busy. IM communicationhappens using the remote shared object as a text field which is visible for both users.

As shown earlier in UML state diagram in Appendix 1, a VoIP call can be establishedonly from the communication window. Therefore, the chat connection is already openbefore making a call. Making a call to a friend is described in Appendix 8. A VoIP callis also started by checking if the user is available and not connected to someone else.Checking of the VoIP availability is done separately from IM availability to enablethe possibility that the user can chat to one friend and call to another simultaneously.However, this is not made possible in the UI design of this application. After noticingthat the callee is available, the incoming and outgoing audio streams are created bythe caller. If the callee accepts the call, then the callee’s corresponding audio streamsare created and both users start to replay each others’ audio streams. Appendix 9correspondingly shows establishing the VoIP connection from the callee’s point ofview.

Integration and verification

As mentioned above, the main part of the development of the web application wasmade with the dummy version of the P2PSIP API. It meant that the actual P2PSIPoverlay did not exist and the API used an emulator script that simulated the P2PSIPoverlay. After the P2PSIP overlay network part was implemented, the Flash applica-tion was integrated with the actual P2PSIP API, which also used the actual overlaynetwork instead of an emulator.

The full functionality and more complex use cases were tested after the actualP2PSIP API and the overlay network were up and running. Some minor issues werefound, but most of the functionality implemented against the API using the emula-tor script was working as expected. The list of the test cases for verifying the basicfunctionality are listed in Appendix 10.

38

5. EVALUATION

The objective of this thesis was to find out possibilities of using P2PSIP overlay func-tionality with a platform independent web application. The results of this constructiveresearch are presented in section 5.1. The results include the functionality and theapplicability of the solution.

The UI of the final application is presented and the usage of the application is de-scribed in section 5.1.1. The feasibility of the solution is studied mainly by comparingthe performance of the P2P system in this thesis to existing P2PSIP solutions. Thesefeasibility experiments are described in detail in section 5.1.2.

Conclusions and the future work of this thesis are discussed in section 5.2. Section5.2.1 concentrates on the benefits of web development techniques. The feasibility ofthe architecture proposed in this thesis for P2P usage is discussed in section 5.2.2.Section 5.2.3 concentrates on the functionality of the web application.

5.1. Results

5.1.1. Final application

Figure 12 shows the idle state of the web application after logging in. Friends can beremoved from the personal contact list by selecting a friend’s name and pressing the"Remove" button. User can also contact friends from this view by selecting a friendand pressing the "Contact" button.

Figure 12. Idle state after logging in to the web application.

After selecting "all users" tab, the state is changed to an all users view, as shown inFigure 13. The user can select one of the friends from the list and press "add" button

39

to add a contact to the personal friends list. After pressing "add" button, the view ischanged back to the personal friends view.

Figure 13. All users view of the web application.

By pressing "Hide Contacts" button, the contact list is hidden. In the view in Fig-ure 14 the user can press "Show Contacts" button and then the contacts window isbrought back. When minimizing the application by hiding the contacts window, theapplication is shown as a compact panel taking only a little space from the display.

Figure 14. Contact list of the web application is hidden.

Error notifications of the actions that are not allowed are given as pop up windows.Pop up windows contain a description of the problem occurred. The communicationwindow pops up when someone starts communicating with the user. In Figure 15,a friend is calling the user. The user can press the "Answer" button to start the VoIPconnection or reject the call by pressing the "Reject" button. Both users can also chat toeach other when the communication window is open. If the call is rejected or cancelled,the communication window still remains open and the users can chat. But if either ofthe users presses the close button, the communication window is closed and both of theusers are available for other users to contact. In case someone tries to contact a friendwho is in communication with someone else, a pop up window is opened notifying thatthe user is busy.

40

Figure 15. Incoming call from a friend.

The communication view of the web application is always the same, no matter if theuser is on the starting or receiving side of the communication. The user is contactingone of her friends in Figure 16. As can be seen, the communication window is similarto the one in incoming call in Figure 15. Only the animations and the texts are different,describing what is happening. The user can make a VoIP call from the communicationwindow by pressing the "Call" button. After making a call, the calling bar appearsin the communication window, as shown in Figure 17. After either user presses the"Close" button, the communication window is closed and users are set available.

The basic functionality of the application is working as expected. All closing andopening actions are animated using basic animation functions of Flex. Hence, theUI flow of the application is smooth. However, the application contains some smallknown issues. There was no need to fix those since they do not prevent demonstrationof the concept. For example, the objective was not to concentrate on privacy or securityissues. Hence, authentication is not made when users are logging into the service.

Also, some special usernames would cause problems, because some keys in theoverlay are occupied for storing a list of users of the service. The username of a useris stored as a key to the overlay as well. If the user would sign in using some occupiedkey as a username, it would overwrite some existing data from the overlay. However,that was not seen as a problem in this thesis, although it would have to be fixed if theservice would be used for commercial purposes.

Another problem occurs if the user suddenly closes the application or loses networkconnection without logging out. In that case, the username key is not removed from theoverlay and the user seems to be online even if she is not. During the implementation,it was noticed as a crucial issue since it is quite common that users only close thebrowser instead of first logging out from the service. Therefore, a Time-to-Live (TTL)parameter was given when storing username keys to the overlay. By default, the TTL

41

Figure 16. Communication window started and message sent to a friend.

Figure 17. User calling to one of his friends.

is endless and keys stored to the overlay do not disappear. But if a TTL is given as aparameter when storing a key to the overlay, the key will be removed after the TTLruns out.

When a user logs in, the username/Red5 address pair is stored to the overlay withthe TTL parameter. The keepLoggedIn timer was implemented to store the user-

42

name/Red5 pair again with the TTL parameter before the original TTL runs out. Thatis done repeatedly all the time the user is logged in. If the application is closed, itdoes not store the username/Red5 pair anymore. Then, the username/Red5 pair will beremoved from the overlay after the TTL runs out. After that, the user is seen offline,which should be the case here. The same functionality is used to notify the user if afriend suddenly closes the application or the browser during the communication.

5.1.2. Experiments

The performance of the web application developed in this thesis was measured and theresults are presented in this section. Sub-section "P2PSIP Java prototype performance"describes the results of the experiment executed by Jouni Mäenpää and Gonzalo Ca-marillo during 2008 and 2009. Mäenpää et al. measured the performance of the Javaprototype which used P2PSIP overlay. [4] Those results are used as a reference pointfor the results measured in the experiment in this thesis. The experiment is describedin sub-section "Web application performance". The performance results between thesetwo experiments are also compared in the same sub-section.

P2PSIP Java prototype performance

Mäenpää et al. executed an experiment comparing the performance of an applicationusing P2PSIP and traditional client/server based SIP solutions. The tests were carriedout in the PlanetLab test network. [4]

The P2PSIP prototype application was implemented in Java programming language.The P2PSIP prototype was uploaded into PlanetLab nodes. The PlanetLab nodes cre-ated a global P2PSIP overlay network. Peer-to-Peer Protocol (P2PP) was used asthe peer protocol in Mäenpää et al.’s experiment. P2PP is one of the proposed peerprotocols sent to P2PSIP WG. P2PP is an application-layer binary protocol designedfor creating and maintaining an overlay network. Chord DHT algorithm was used toorganize the overlay. [4]

According to Mäenpää’s study, the experiments were executed using several dif-ferent overlay network sizes and churn rates. The churn rate means the arrival anddeparture rate of users in the overlay. The sizes of the overlay used were 250, 500 and1,000 number of peers. The churn rates varied from 1s to 40s. In practice, it means thedelay how often a peer leaves and joins the overlay. Therefore, in the highest churn rateand smallest overlay size, the average session duration is 4min. With the lowest churnrate and the biggest overlay size, the average duration of session is 11h. It was alsonoted that for example in Skype network the median session time duration is severalhours. [4]

Each churn rate and network size combination was measured and repeated 15 times.In the experiment, each user initiated 13 VoIP calls per day, out of which 17% weremade during the so called busy hour to stress the overlay more. Peers joined the overlayby contacting a bootstrap peer first. The bootstrap peer of the overlay was located inHelsinki. The join request was routed from the bootstrap peer to an admitting peer. Theadmitting peer became the first successor of the joining peer on the Chord ring. [4]

43

The whole joining process consists of three P2PP transactions initiated by the Javaprototype. The transactions are Query, Join and Publish. To make a VoIP call, the callerfirst requests the contact address of the friend from the overlay by using LooupObjecttransaction. After that, a direct connection between two users is established. Thesedelays of the Java prototype are shown in Table 5.4. The number of peers was 1,000and the churn rate was the highest (1s). For comparison, also the corresponding delaysof the traditional client/server based SIP client are listed in Table 5.4. 1,000 SIP UAswere uploaded to a set of PlanetLab nodes to simulate 1,000 simultaneous users. [4]

Table 5.4. Joining process and call setup delay of P2PSIP prototype and traditionalclient/server based SIP client

Operation P2PSIP client delay SIP client delayJoining process 4592.35ms 233.42msSetup a call 1866.12ms 674.92ms

Web application performance

The performance of the web application developed in this thesis was measured in thePlanetLab test network as well, although the overlay constructed only of one peer (thebootstrap peer). The bootstrap peer was located in Helsinki. The tests were carried outsimply by measuring the delay of each operation ten times and calculating the averagedelay. Figure 18 illustrates the one peer system architecture used in the experiment.

Figure 18. The system architecture of the P2PSIP system used in performance experi-ment of the web application.

44

The numbers in Figure describe the process how users join the overlay and startcommunicating. Those are explained in the description of Figure 10. Only one Red5server was available during the experiment. Therefore, the users were connected to thesame Red5 server, which made the call set-up delay shorter than if both users wouldhave been connected to different Red5 servers. Hence, the delay of connecting toa Red5 server was measured. This delay should be the only additional delay whenconnecting to the callee which is connected to a different Red5 server than the caller.

Despite the differences between the overlay sizes in this thesis and the experimentexecuted by Mäenpää et al., the results of both experiments could be compared. Thereason is that the experiment carried out by Mäenpää et al. contained the averageinternal delays of the bigger overlay for each P2PP transaction. The internal delays ofthe bigger overlay used by Mäenpää et al. could be added to the results received fromthe experiment carried out in this thesis. The internal delays of the P2PP transactionsin the 1,000 peer overlay according to Mäenpää et al. are listed in Table 5.5. The churnrate of the overlay was 1s. [4]

Table 5.5. Internal delays of the P2PSIP network with overlay of 1000 peers and 1schurn rate

Transaction DelayJoin 1068.69msPublish 1191.35msLookupObject 799.70ms

The whole joining process delay of the web application in this thesis was measuredfrom the moment user presses the login button to the moment the user has stored itscontact address to the overlay. The joining process of the application in this thesisdiffers somewhat from the Java prototype used by Mäenpää et al. The joining pro-cess of the web application consists of LookupPeer, Join, LookupObject and PublishP2PP transactions. First, the LookupPeer returns the admitting peer address and Jointransaction connects to the admitting peer. Then LookupObject returns the availableRed5 address. And finally, the key/value pair (username/Red5 address) is stored to theoverlay by Publish transaction. After that, the user is able to start communication withother users and the joining process is ready from the user’s point of view. Other usersmay start communication with the user only after the username/Red5 address informa-tion is actually stored to the overlay, meaning that the information is visible for otherusers in the overlay after the overlay’s internal delay of the Publish transaction.

The estimated joining process delay of the P2PSIP web application of this thesis in1,000 peer overlay is calculated as explained below. As can be seen from the totalresults of the experiment in Appendix 11, the average joining process delay with onepeer overlay is 470.70ms. As explained, the joining process consisted of LookupPeer,Join, LookupObject and Publish transactions to the overlay. Table 5.5 contains thecorresponding internal delays of the overlay of 1,000 peers.

It can be assumed that the overlay delay for LookupPeer and LookupObject trans-action is the same. The Join transaction delay of 1,000 peer overlay was ignored.The reason for this was that in this experiment the LookupPeer query returned the

45

admitting peer address. Then, the Join transaction is made straight between the webapplication and the admitting peer instead of going via the bootstrap peer. Hence, thetotal estimated delay of the joining process to the 1,000 peer overlay is calculated byadding the following values together: joining process in one peer overlay 470.70ms,LookupPeer 799.70ms, LookupObject 799.70ms and Publish 1191.35ms.

The delay for initializing a VoIP call was measured from the moment the user pressesthe call button to the moment audio streams through the Red5 server are initiated andthe callee receives the notification of an incoming call. Also, the delay for initiatingan IM communication was measured, although the transactions between the web ap-plication and the overlay are similar in both VoIP and IM initiation cases. The webapplication makes a LookupObject transaction to receive the username/Red5 addressinformation of the callee. In both cases, communication between the clients is finallyinitiated using RTMP connection through a Red5 server. However, the difference be-tween VoIP and IM communication through the Red5 server is that the remote sharedobject is used for IM communication and NetStream is used for VoIP. Hence, alsothe differences between delays in creating a shared object and initiating a NetStreambetween clients were found out.

The call set-up delay estimate in 1,000 peer overlay was calculated as explainedbelow. As can be seen from the measurements in Appendix 11, the average delay insetting up a call was 422.5ms. Two separate call set-up delays were calculated. Theshorter delay described a situation where both users are connected to the same Red5server. The longer delay contains extra 124ms delay, which is taken when connectionto another Red5 server is established. Hence, the longer delay describes a situationwhen the users are connected to separate Red5 servers. Also, the additional 799.70msdelay was added to describe the internal LookupObject delay of 1,000 peer overlay.

The estimates of the average call set-up delay and join process delay in 1,000 peeroverlay are presented in Table 5.6. Also, the delays of the P2PSIP Java prototype andthe traditional client/server SIP application were added to Table 5.6 for comparison.The Java prototype was in 1,000 peer overlay, with a churn rate of 1s.

Table 5.6. Comparison of total joining process and call set-up delays between P2PSIPweb application, P2PSIP Java application and traditional client/server SIP application.First P2PSIP web application call set-up delay when both users connected to the sameRed5 and the other delay when the users are in different Red5 servers

Operation P2PSIP P2PSIP Traditional client/serverweb application Java application SIP application

Joining process 3261ms 4592ms 233msSet-up a call 1222ms 1866ms 675ms

1346ms

As can be seen from the results in Table 5.6, the delays of the platform independentweb application are smaller than corresponding Java application delays. The resultscan be considered only as suggestive. The reason for this is that the test environmentwas simple and all the parts of it were located in Finland. The bootstrap peer and theclient computers were all in the capital area of Finland. Hence, all the P2PSIP overlay

46

operations took place in that area. The Red5 server was located in Oulu. Also, all themeasurements were carried out in a short period.

The results strongly suggest that the performance of the platform independent webapplication is not the bottleneck in the P2PSIP system. Most probably the differencesbetween web application and Java prototype depend more on the network traffic andthe overlay operability than the technology used to implement the application.

Row I in Appendix 11 shows the delay of joining to the overlay of one peer (Lookup-Peer and Join transactions). Row II shows the time taken when the user joins the over-lay, receives the free Red5 server address and connects to the Red5 server in question.After that, the username/Red5 address pair is stored to the overlay (Publish). Row IIIshows the average time used for creating a new connection to a Red5 server. RowsIV and V show the time taken for setting up a VoIP call and an IM connection withanother user. Row VI shows the delay of receiving a key/value pair (username/Red5address) from the overlay by using a LookupObject transaction.

5.2. Discussion

5.2.1. Web development techniques

The use of web development tools and an IDE designed for a certain purpose makedevelopment of web applications efficient and fast. Part of the development was doneusing Linux based Eclipse IDE for Flash development purposes [53] . But most parts,especially the UI components, were developed using Windows based Flex Builder3 IDE. Eclipse and Flex builder were efficient for coding, but the graphical designtool was available only in Flex Builder. The graphical design tool was good sinceit was possible to draw the UI graphically and add UI components by dragging anddropping. Coding the UI components using MXML language is quite easy for anexperienced programmer, but the graphical design tool makes designing much moreefficient because the MXML code is automatically generated by the tool. One benefitof using Flex Builder was also that it supported predictive typing for Flex applications.Because of that, the programmer does not need to be so careful with the programmingsyntax.

Development of web applications in a web development environment is assumedto be faster and easier than development of native C++ applications, for example.Especially the ubiquity of the web applications enables the multichannel access andtherefore a wider device base compared to native applications. Naturally, there arealso some downsides in the web application development compared to the native ap-plications. Probably the clearest benefit in native applications is their performance.Web applications usually require for example a virtual machine or a browser pluginunderneath to work on top of a native SW platform. Hence, even small applicationsrequire a virtual machine to be running simultaneously, which takes a lot of resourcesfrom the system (e.g. memory). Of course, virtual machines give a great benefit fordeploying applications. An application can be executed on top of a compatible vir-tual machine and the application is dependent only on the virtual machine and canbe executed in every device that has the compatible virtual machine. Then, the sameapplication can be used in different devices and operating systems.

47

One disadvantage of web applications running on top of a virtual machine or abrowser plugin is that they might not be able to use all the resources of the system.If, for example, a virtual machine does not contain a certain API to a certain resource,there is no way for the developer to use the resource in question. For example, con-temporary mobile computers have several embedded devices, such as camera, GlobalPositioning System (GPS) and modem. The virtual machine is not able to use those ifthe APIs are not implemented or they are not public for the developers. Usually, theAPIs exist for the native language and therefore the application developer has morepossibilities to implement functionality. In mobile devices, the security aspect is oftenthe reason for not to provide the APIs for web application developers. For example, amalware sending Short Message Service (SMS) or making a call with a mobile phonemight cause extra costs for the users. Also, often web applications cannot be digitallysigned to control the capabilities of the applications.

5.2.2. Feasibility of the architecture

The web application development for this thesis was started together with the P2PSIPAPI definition. The development was done mainly by using the dummy P2PSIP API,which was an emulator simulating the actual P2PSIP API and the overlay networkbehind it. Therefore, the development work required flexibility and agility to changethe design of the application or the P2PSIP API during the implementation.

It was known that the P2PSIP overlay emulator will not work exactly as the actualP2PSIP overlay would. For example, the actual P2PSIP overlay may not be as robustand reliable as the emulator. Also, the actual overlay would most probably have a no-table delay between the request and the response. The delay in emulator overlay wasminimal. These known issues were taken into account when designing and implement-ing the application. These issues were solved for example by finding the functions thatmay cause extra waiting for the user because of the delay in actual overlay network. Insuch functions, the application informs the user that the application is not frozen, butit is waiting for the response from the overlay. The application also notifies the user ifthe response for the request is never received from the overlay.

The emulator of the overlay network also supported only one connected client at atime. That caused some problems for testing of the application. The final and widertesting with multiple users at the same time was executed after the actual P2PSIP APIand the overlay were ready. Some errors were found because of incomplete testingagainst the emulator overlay. Fixing the errors did not require a lot of effort because themain shortages of the overlay emulator against the actual one were known beforehand.

The architecture of the system can be considered as a partially centralized P2P archi-tecture [27] . The web application developed can act only as a client in the architecture.The client in this system cannot store data or share any of their resources with otherusers. This means that the normal user cannot act as a peer in the system. As describedin the Chapter 3, the peers in the overlay network can be called as super peers. Superpeers in this system provide storing capability for all the clients in the network.

P2PSIP network is used for storing the information of the users logged in to the ser-vice, the list of each user’s personal contacts and the location of the Red5 server whicheach user is connected to. In practice, the web application developed in this thesis

48

always connects to the same peer (bootstrap peer) first. Therefore, the functionalityof the system is dependent on the availability of the bootstrap peer whose address isdefined in the web application. Hence, the actual solution of the P2P system in thisthesis could be categorized as a hybrid P2P architecture as well [27] . However, the ar-chitecture of the system supports changing the application to connect randomly to anyavailable peer. It was not implemented since the size of the overlay in the experimentof this thesis was only one peer.

Although the web application was using P2PSIP overlay network, it cannot be calledas a full P2P application. The reason for this is that the contemporary Flash technologydoes not support a direct RTMP connection between two Flash Players. A server thatsupports RTMP protocol was required in between the Flash Players. The Red5 serverwas used to handle the RTMP connection between the Flash Players.

The point of comparison in the experiment was the Java application using P2PSIPoverlay network. As was seen in the experiment results, the performance of the webapplication developed in this thesis does not seem to be a bottleneck. All the delaysseemed reasonable from the user’s point of view. By improving the internal function-ality and the architecture of the web application, the performance could be improved.However, the delays within the application and Red5 server were so small that mostprobably those would not be significant from the whole system point of view. In theexperiment, the delays within the application and between the application and Red5server were only hundreds of milliseconds, although the effect of stressing the Red5server by the number of users at the same time was not tested. Therefore, no estimatewas done on how many Red5 servers would be needed if the number of users in theoverlay would rise significantly.

The undoubted benefit of the Java P2PSIP prototype solution implemented by Mäen-pää et al. was the capability to establish a direct SIP connection between two clients.Also, unlike the web application in this thesis, the Java prototype could act as a peerafter joining the overlay. Although the web application was able to use the P2PSIPoverlay by storing and retrieving data to it, it can act only as a client in the system.

Adobe Systems has introduced a new Real Time Media Flow Protocol (RTMFP) thatsupports direct connection between two Flash Players. RTMFP has similar features asRTMP when communicating with a media server, but in addition it supports streamingreal time data between two Flash Players. However, that is still in beta phase and sup-ported only in Flash Player version 10. It also requires FMS to establish the connectionbetween clients. [20] Implementing full P2P functionality between two contemporaryweb application does not seem to be possible with current Flash technology. But itremains to be seen how, for example, the coming RTMFP supported Flash Player willwork and will the open source media servers, like Red5, support the RTMFP as well.

5.2.3. Functionality of the web application

The web application was ready in the beginning of 2010 and was demonstrated in-side the development project. The official demonstration of the whole system willtake place later during the spring 2010 in DECICOM project. The usability of theapplication was considered very good inside the project. Especially the animationsin the application were appreciated by the people who saw the application. Even the

49

animations were not related to the P2P technology, those reflected well the importanceof demonstrating that the P2P technology could be used with flexible web applications.The usability of the application was not officially measured and it was not the objectiveof this research.

All "MUST" and "MAY" level functional requirements were defined in Chapter 4.Table 5.7 contains the "MUST" priority features of the Flash application that wereimplemented. All "MUST" level requirements were implemented. The description ofthe requirements was quite vague and therefore the developer of the application couldinfluence a lot in the functionality details of the each use case. The functional testingof the implemented features was carried out successfully. None of the tested featuresfailed. The test results can be found from Appendix 10.

Table 5.7. Implemented high level features of the Flash application# Requirement1 Intuitive and animated GUI2 VoIP call between Flash clients3 Instant Messaging (IM) functionality between Flash clients

Besides "MUST" level requirements there were two "MAY" level requirements:shared calendar and file sharing. Because of the tight schedule of the thesis, thefunctionality requirements classified as "MAY" were not planned. Also, the "MAY"requirements were defined only in a high level. However, extending the functionalityof the web application is possible. The design and the architecture of the applicationwere documented and it was decided that if DECICOM project has resources, thefunctionality of the application can be extended later.

There are a lot of commercial applications that contain similar features as the webapplication in this thesis. For example, Skype provides VoIP and IM features [54] .However, those are not platform independent and usually require some SW installationfrom the user. The RIAs in general were discovered to provide an easy way to developmultichannel accessible applications that are easy to distribute to the users. Especiallythe possibility to execute most of the functionality locally in the user’s computer in-stead of running it on a server makes the application smooth despite slow networkconnection.

50

6. SUMMARY

A possibility to develop a platform independent web application using serverlessP2PSIP network was studied in this thesis. The motivation behind developing a P2Papplication was that P2P architecture reduces the need of maintenance and administra-tion work. Because of the distributed nature of P2P, it is able to adapt to failures andstill maintain acceptable connectivity and performance. Therefore, P2P architectureis self-maintainable and resistant to censorship and centralized control. The benefit ofweb applications in this context is that they do not require separate installation from theuser. The web application is downloaded and used just like a normal web page. Webapplications can also be multichannel accessible, which means that the same applica-tion can be accessed by a wide diversity of devices and operating systems. Therefore,web applications are often platform independent.

The meaning of a web application was defined in Chapter 2. Also, the diverse andinteractive type of web application called Rich Internet Application (RIA) was intro-duced. In Chapter 3, the term P2P was defined in more detail and different categoriesof P2P network architectures were introduced. The serverless way of using SIP, calledP2PSIP was also presented.

Flash was selected as the technology to develop the web application using P2PSIPoverlay. The basic functionality and capabilities required to implement P2P web ap-plication were prototyped first. After knowing the capabilities of the Flash application,the high level system architecture was defined.

It was proved in this thesis that by using contemporary web applications and de-velopment techniques it is possible to develop a web application that uses P2PSIPoverlay network. The system architecture designed in this thesis belongs to partiallycentralized P2P architectures. The actual implementation was closer to a hybrid decen-tralized P2P architecture. [27] The reason for this was that the overlay network used inthe study contained only one peer and there was no need to implement the applicationto connect randomly to any available peer. Therefore, the actual solution is dependenton one peer.

As defined by Theotokis et al., in partially centralized architecture peers in the over-lay are called super peers. The web application developed in this thesis may act onlyas a client. Only the super peers can share and provide resources for the clients. Theshared resource used by the prototype web applications is data storing capacity. TheP2PSIP network is totally independent of the web application used. Any kind of webapplication developed in Flash can use the same P2PSIP API and form a P2P webservice.

The communication between clients goes through a media server. Two contempo-rary Flash applications cannot communicate directly with each other. That was a clearlimitation when comparing web application to existing P2P solutions. Red5 mediaserver was used to create communication between web applications. RTMP connec-tion, which enables real time communication between users, was formed from webapplication to Red5 server.

The performance of the web application was measured by comparing the delays ofthe basic functionality of the web application to an existing P2P application. Mäenpääet al. have examined the delays of the Java prototype using P2PSIP overlay. It was seenfrom the results that the development technique is not the bottleneck on feasibility of

51

a P2PSIP application. The results also showed that the delays of the web applicationwere even shorter than corresponding delays of the Java prototype. Most probably, thefeasibility of a P2P system relies much more on the capability of the network and thefunctionality of the P2PSIP overlay than the technology used.

In conclusion, the capabilities of web application were seen positive for P2P usage.Also, a straight connection between two web applications might be possible in thefuture, for example by using the coming RTMFP protocol.

52

7. REFERENCES

[1] Ceri S., Daniel F., Matera M. & Facca F.M. (2007) Model-driven development ofcontext-aware Web applications. ACM Trans. Internet Technol. 7, p. 2.

[2] Driver M., Valdes R. & Phifer G. (2005) Rich Internet Applications Are the NextEvolution of the Web. Tech. rep., Gartner.

[3] Seet B.C. (2009) Mobile Peer-to-Peer Computing for Next Generation Dis-tributed Environments: Advancing Conceptual and Algorithmic Applications. In-formation Science Reference - Imprint of: IGI Publishing, Hershey, PA, 326–347p.

[4] Mäenpää J. & Gonzalo C. (2009) Analysis of Delays in a Peer-to-Peer SessionInitiation Protocol Overlay Network. Finland.

[5] Dodig-Crnkovic G. (2009) Constructivist Research and Info-ComputationalKnowledge Generation. In: Model-Based Reasoning In Science And Technology- Abduction, Logic, and Computational Discovery Conference.

[6] Kasanen E., Lukka K. & Siitonen A. (1993) The constructive approach in man-agement accounting. In: Journal of Management Accounting Research (5), pp.243–264.

[7] Conallen, Jim (2003) Building Web applications with UML. Addison-WesleyLongman Publishing Co., Boston, MA, USA, 2 ed.

[8] Whittaker, Jason (2002) The Internet: the basics. Routledge, London, UK, 1 ed.

[9] Bozzon A., Comai S., Fraternali P. & Carughi G.T. (2006) Conceptual modelingand code generation for rich internet applications. In: ICWE ’06: Proceedingsof the 6th international conference on Web engineering, ACM, New York, NY,USA, pp. 353–360.

[10] Robbins J.N. (2006) Web design in a nutshell. O’Reilly Media, Sebastopol, CA,USA, 3 ed.

[11] Neubauer M. & Thiemann P. (2005) From sequential programs to multi-tier ap-plications by program transformation. SIGPLAN Not. 40, pp. 221–232.

[12] Zimmermann O., Tomlinson M. & Peuser S. (2003) Perspectives on Web Ser-vices: Applying SOAP, WSDL and UDDI to Real-World Projects. Springer, NewYork, USA, 1 ed.

[13] Petersen J. (Accessed 17-03-2010) Benefits of using n-tiered approach for webapplications. URL: http://www.adobe.com/devnet/coldfusion/articles/ntier.html.

[14] Duhl J. (2003) Rich Internet Applications. Tech. rep., IDC, MA, 01701 , USA.

[15] Preciado J.C., Linaje M., Sanchez F. & Comai S. (2005) Necessity of method-ologies to model Rich Internet Applications. In: WSE ’05: Proceedings of theSeventh IEEE International Symposium on Web Site Evolution, IEEE ComputerSociety, Washington, DC, USA, pp. 7–13.

53

[16] Sheehan P. (2003) Enterprise Curl. Pearson Education, Upper Saddle River, NJ,USA, 1 ed.

[17] Mahemoff M. (2006) Ajax Design Patterns. O’Reilly Media, Inc., Sebastobol,CA, USA, 1 ed.

[18] Weaver J.L. (2007) JavaFX Script: Dynamic Java Scripting for RichInternet/Client-side Applications. Apress, 1 ed.

[19] Kazoun C. & Lott J. (2008) Programming Flex 3: The Comprehensive Guideto Creating Rich Internet Applications with Adobe Flex. Adobe Dev Library -Imprint of: O’Reilly Media, Sebastopol, CA, USA, 1 ed.

[20] Adobe Systems Inc. (Accessed 17-03-2010) Adobe Flex 3. URL:http://www.adobe.com/products/flex/.

[21] Brumbaugh-Duncan C. (2002) The Flash MX project. New Riders Publishing,USA, 1 ed.

[22] Open Source Flash (Accessed 17-03-2010). URL: http://osflash.org.

[23] Jarvensivu J., Kosola M., Kuusipalo M., Reijula P. & Mikkonen T. (2006) De-veloping an Open Source Integrated Development Environment for a Mobile De-vice. In: ICSEA ’06: Proceedings of the International Conference on SoftwareEngineering Advances, IEEE Computer Society, Washington, DC, USA, p. 55.

[24] Sanders W.B. (2008) Learning flash media server 3. O’Reilly, Sebastopol, CA,USA, 1 ed.

[25] Adobe Systems Inc. (Accessed 17-03-2010) Real-Time Messaging Protocol(RTMP) specification. URL: http://www.adobe.com/devnet/rtmp/.

[26] Schollmeier R. (2001) A Definition of Peer-to-Peer Networking for the Classifi-cation of Peer-to-Peer Architectures and Applications. In: P2P ’01: Proceedingsof the First International Conference on Peer-to-Peer Computing, IEEE ComputerSociety, Washington, DC, USA, p. 101.

[27] Androutsellis-Theotokis S. & Spinellis D. (2004) A survey of peer-to-peer con-tent distribution technologies. ACM Comput. Surv. 36, pp. 335–371.

[28] Gnutella (Accessed 17-03-2010) Gnutella Protocol Development. URL:http://rfc-gnutella.sourceforge.net/.

[29] Kazaa (Accessed 17-03-2010). URL: http://www.kazaa.com/.

[30] Balakrishnan H., Kaashoek M.F., Karger D., Morris R. & Stoica I. (2003) Look-ing up data in P2P systems. Commun. ACM 46, pp. 43–48.

[31] Rosenberg J., Schulzrinne H., Camarillo G., Johnston A., Peterson J., SparksR., Handley M. & Schooler E. (Accessed 17-03-2010) SIP: Session InitiationProtocol. IETF RFC 3261. URL: http://www.ietf.org/rfc/rfc3261.txt.

54

[32] Russell T. (2008) Session Initiation Protocol (SIP): Controlling Convergent Net-works. McGraw-Hill Osborne Media, 1 ed.

[33] Davidson J., Peters J., Bhatia M., Kalidindi S. & Mukherjee S. (2006) Voice overIP Fundamentals. Cisco Press, In, USA, 2 ed.

[34] IEFT (Accessed 17-03-2010) Peer-to-Peer Session Initiation Protocol (ActiveWG). URL: http://tools.ietf.org/wg/p2psip/.

[35] Singh K. & Schulzrinne H. (2005) Peer-to-peer internet telephony using sip. In:NOSSDAV ’05: Proceedings of the international workshop on Network and op-erating systems support for digital audio and video, ACM, New York, NY, USA,pp. 63–68.

[36] DECICOM, Networking Laboratory, Helsinki University of Technology (Ac-cessed 17-03-2010). URL: http://www.netlab.tkk.fi/tutkimus/decicom/.

[37] MediaTeam, University of Oulu (Accessed 17-03-2010). URL:http://www.mediateam.oulu.fi/.

[38] Kapitsaki G.M., Kateros D.A., Prezerakos G.N. & Venieris I.S. (2009) Model-driven development of composite context-aware web applications. Inf. Softw.Technol. 51, pp. 1244–1260.

[39] Grinter R.E., Edwards W.K., Chetty M., Poole E.S., Sung J.Y., Yang J., CrabtreeA., Tolmie P., Rodden T., Greenhalgh C. & Benford S. (2009) The ins and outsof home networking: The case for useful and usable domestic networking. ACMTrans. Comput.-Hum. Interact. 16, pp. 1–28.

[40] Ketola P. (2005) Special issue on out-of-box experience and consumer devices.Personal Ubiquitous Comput. 9, pp. 187–190.

[41] Mozilla (Accessed 17-03-2010) Mozilla Code Licensing. URL:http://www.mozilla.org/MPL/.

[42] Moock C. (2007) Essential actionscript 3.0. O’Reilly, 1 ed.

[43] Reinhardt R. (2009) Video with Adobe Flash CS4 Professional Studio Tech-niques. Adobe Press.

[44] Richardson I.E.G. (2003) H.264 and MPEG-4 video compression: video codingfor next-generation multimedia. John Wiley & Sons Inc., NJ, USA, 1 ed.

[45] Nokia (Accessed 17-03-2010). URL: http://maemo.nokia.com/n900/.

[46] Motorola (Accessed 17-03-2010). URL: http://www.motorola.com/Consumers/US-EN/Consumer-Product-and-Services/Mobile-Phones/Motorola-DROID-US-EN.

[47] Open Source Initiative (Accessed 17-03-2010). URL:http://www.opensource.org/licenses/lgpl-license.php.

[48] red5phone (Accessed 17-03-2010). URL: http://code.google.com/p/red5phone/.

55

[49] BigBlueButton (Accessed 17-03-2010). URL: http://bigbluebutton.org/.

[50] Adobe Systems Inc. (Accessed 17-03-2010) Adobe Flex 3.5 Language Refer-ence. URL: http://livedocs.adobe.com/flex/3/langref/.

[51] Bradner S. IEFT (Accessed 17-03-2010) Key words for use in RFCs to IndicateRequirement Levels. IEFT, URL: http://www.ietf.org/rfc/rfc2119.txt.

[52] Larman C. (2001) Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process. Prentice Hall PTR, UpperSaddle River, NJ, USA, 2 ed.

[53] Eclipse Foundation (Accessed 17-03-2010). URL: http://www.eclipse.org/.

[54] Skype (Accessed 17-03-2010). URL: http://about.skype.com/.

56

8. APPENDICES

Appendix 1 State chart of the GUI

Appendix 2 Class diagram of the application

Appendix 3 P2PSIP API functions

Appendix 4 Sequence Diagrams of login process

Appendix 5 Sequence diagram of the adding and removing friends

Appendix 6 Sequence diagram for showing how user is kept logged in

Appendix 7 Sequence diagram for describing how communication window with a friendis opened

Appendix 8 Sequence diagram of making a call and ending the call

Appendix 9 Sequence diagram of incoming call and caller ending the call

Appendix 10 The list of basic functional test cases and results

Appendix 11 Performance test results in one peer overlay. Delays are shown in milliseconds

57

Appendix 1: State chart of the GUI

58

Appendix 2: Class diagram of the application

59

Appendix 3: P2PSIP API functions

• P2PSIPClient(responseHandler:Function = null, errorHandler:Function = null,stateHandler:Function = null) /* Constructor. Parameters: responseHandlerDefault handler for query responses. Params: key:String, value:ByteArray. Ifthere is no value for the given key, null is given as value. errorHandler: Handlerfor errors. Key is the query key that caused the error or null if the error is notabout query. Params: key:String, error:String. stateHandler: Handler for statechanges. Params: newState:int */

• connect(address:String, port:uint) /* opens the socket connection and connectsto the specified peer */

• disconnect() /* closes the connection to the peer */

• get(key:String, handler:Function = null) /* Query for data from the overlay. Theresponse is given to the default responseHandler (which is given as constructorparameter) or to a key-specific handler (given as the second parameter here). */

• getServer(key:String, respHandler:Function, serverIndex:int = -1) /* Query fora flash server to which one can register into. The response is a server URI as aString. */

• put(key:String, value:ByteArray, lifetime:int = -1, respHandler:Function = null)/* Store arbitrary data to the DHT. Parameters: key: The key of the data. value:The value to store. lifetime: How long time (seconds) to store the value.Default = -1 (maximum time / forever). respHandler: The function that is calledwhen the put finishes. */

• putString(key:String, value:String, lifetime:int = -1, respHandler:Function =null) /* Store String (UTF-8) data to the DHT. */

• putArray(key:String, value:Array, lifetime:int = -1, respHandler:Function =null) /* Store ActionScript Array to the overlay. When getting the value, dovalue.readObject() and cast to Array object for the returned ByteArray. */

• remove(key:String, respHandler:Function = null) /* Remove data from theoverlay. */

60

Appendix 4: Sequence Diagrams of login process

61

Appendix 5: Sequence diagram of the adding and removingfriends

62

Appendix 6: Sequence diagram for showing how user is keptlogged in

63

Appendix 7: Sequence diagram for describing howcommunication window with a friend is opened

64

Appendix 8: Sequence diagram of making a call and ending thecall

65

Appendix 9: Sequence diagram of incoming call and caller endingthe call

66

Appendix 10: The list of basic functional test cases and results

# Test case Result1 login to the service PASS2 logout of the service PASS3 hide and show contacts PASS4 change between "friends" and "all users" tabs PASS5 add friends PASS6 remove friends PASS7 start communication with a friend and chat PASS8 close communication with a friend -> communication starter closes PASS9 close communication with a friend -> communication receiver closes PASS10 call to a friend -> friend answers -> start new call PASS11 call to a friend -> friend rejects -> start new call PASS12 call to a friend -> cancel the call -> start new call PASS13 call to a friend -> friend answers -> friend ends the call -> start new call PASS14 call to a friend -> friend answers -> caller ends the call -> start new call PASS15 caller closes the communication window during the call PASS16 callee closes the communication window during the call PASS17 try to contact a friend who is offline -> should not be possible PASS18 try to contact a friend who is busy -> should not be possible PASS19 logout during a communication PASS20 close the browses during a communication PASS21 see if friend statuses are changed when they login and logout PASS

67

Appendix 11: Performance test results in one peer overlay. Delaysare shown in milliseconds

Action 1 2 3 4 5 6 7 8 9 10 Avg.I Connected to 325 269 270 332 313 323 278 303 300 364 307.7the overlayII Connected to 501 417 428 472 493 501 450 460 438 547 470.7the overlay andRed5III Create 129 111 123 120 136 128 129 110 110 144 124.0connectionto a Red5IV Set-up 431 374 435 513 444 445 445 403 344 391 422.5a VoIP callV Set-up an IM 237 251 239 243 293 261 235 251 267 231 250.8connectionVI Get 32 23 32 42 34 23 25 32 79 24 34.6key/value pair(LookupObject)

Date post:	04-Jan-2020
Category:	Documents
Upload:	others
View:	2 times
Download:	0 times

PLATFORM INDEPENDENT WEB-BASED PEER-TO-PEER … · Määttä M. (2010) Platform Independent...

Documents