Real-time Mobile Peer – to – Peer Video Streaming Overlay

8/6/2019 Real-time Mobile Peer to Peer Video Streaming Overlay

1/5

Real-time Mobile PeertoPeer Video Streaming

OverlayW.V. Wathsala, Ramith Jayasinghe, Nuwan R. Gunarathna

Lanka Software Foundation,

UCSC Building Complex, 35, Reid Avenue, Colombo7, Sri Lanka

{wathsala, ramithj, nuwanr}@opensource.lk

Abstract The Real Time P2P Video Streaming Overlay is areal time video streaming application that uses a peer topeer

overlay for streaming and discovery of content. Streams can be

created, discovered and viewed from plethora of heterogeneous

devices such as desktops, smart phones and internet tablets etc. It

comes with capabilities to perform real time video stream search

queries and aggregating those into user defined channels (filters).

The real time search allows users to search for live video streams

available on the network coming from various devices connected

to the network ranging from mobile phones to HD cameras

attached to PCs. Channels can be considered as standing queries

plus a collection of known and permanent set of video streamingresources which are at the disposal of the users allowing them to

access their favourite content easily.

Keywordsstreaming, P2P, overlay, mobile

I. INTRODUCTIONToday the Internet has passed the point where it could

become unusable as a means of sharing digital information

without existence of search engines. With power of searchengine technologies such as Google real - time search and web

2.0 paradigms have changed the life style of people by

making the World Wide Web a platform for entertainment andnews with a personal touch. For example, online diaries such

as Blogspot[6], Wordpress[7] allow people around the world

to share their ideas, experiences and knowledge while placeslike Flickr[9] let users to publish their photos in a searchable

format. Taking the content sharing and publishing to a new

era of social networking, web sites like Facebook[8] has allow

its users not only to share but also to make virtual

communities and networks that expand over geographical

boundaries. On the other hand file sharing software such as

Napster[10], Kazaa[11] brought paradigm of P2P to

mainstream, creating another opportunity for Internet users to

share content without central governance. Its obvious that,

underlying concepts of these softwares and services are to letusers to share something with others, instantly and

boundlessly. Extreme popularity of these softwares and

services allow us to believe that Internet users and humans in

general are fond of sharing and expressing themselves and are

always looking for newer means of doing so.

Because of these reasons, we believe that there should be

more opportunities to content publishers (especiallyindividuals and small and medium scale publishers) while

improving individual choice by introducing heterogonous

software and hardware infrastructure which enables live/real

time video streaming over a peer to peer network. The

environment we propose (over the time) will consist ofthousands of content publishers who are streaming various

media types such are localized news, sports, musical shows

etc., while consumers search and filter the media creating their

own channels as their per se. Since proposed system is a peer

to peer system every participant can be viewed as a

potential consumer and a producer.

However it should be mentioned that this is not the first

attempt on peer to peer media streaming [12], [13], [14].

Most of the previous works including both none real-time

streaming and real-time streaming does not have an integrated

distributed stream search service. In those systems peers

become aware of streams through a web site [12]. Secondly

none real-time peertopeer media streaming environments

hold redundantly stored media which can be searched and

accessed by peers, in such systems it is also possible for a peerto relay a stream receiving at the moment to another peer.

Relaying of streams is not a quite scalable method when it

comes to mobile devices that have less CPU power and

bandwidth. Existing real-time peer to peer streamingenvironments also use the above mentioned stream relaying

method which is not scalable where mobile devices are used.

System proposed here eliminates these two issues of real-time

streaming platforms. To overcome the two issues we are

proposing two overlay networks organized appropriately to

serve the requirements of being able to scale and being able to

search in real-time. The purpose of the system is searching a

stream and building a map of the stream delivery network and

extending it. Actual streaming takes place with existingstreaming protocols such as RTP and appropriate CODECs

once the nearest location of the stream has been identified by

the recipient. Therefore QoS is not a concern in this paper.

From here onwards the paper is organized as follows, in

section II the design of the overlays and algorithms are

discussed, in section III future works and implementation is

discussed and in the section IV the conclusion is presented.

II. DESIGNThe system is built to share and search video content on

real time fashion. At this point we should make two

assumptions and their basis clear.

A stream made available by a participating node is

available for the rest of the nodes in timeafter streaming has been started.

Before streaming starts a set of tags describing thestream is distributed in time by thepublisher which in turn can be searched by the

other nodes in timeWhen an overlay satisfies the above assumptions it is safe

to assume the system will act in a real-time fashion as

expected even with large values of n (number of peer).

However with modern Distributed Hash Tables (DHTs) such

time complexities are practical and also hop to hop time

counts are in milliseconds in the Internet. Therefore the entiresystem is built by integrating several Distributed Hash Tables

(DHTs) as shown in Fig. 1 and two of them are core overlays

or mandatory overlays corresponding to two assumptions

stated above. Namely they are the content overlay and the tag


2/5

overlay. The tag overlay is built on top of a DHT which

functions as a distributed tag cloud providing the basis for

content discovery and search. The content overlay is

responsible for distributing content over the network and

functions on top of a DHT. Beyond these two services any

overlay based onDHTs can be added to the system depending

on the application requirements such as overlays for

authentication, advertising, etc., which we will not be

covering here.

A.Hierarchical Structured OverlayMethods described [1],[2],[3] assumes multiple senders and

discusses algorithms for selecting the best sender. In those

approaches parts of the stream can be downloaded from

different senders making it impossible to stream in real-time.

Such systems may not be scalable for mobile devices as theyare not resourceful with respect to CPU power, RAM and

bandwidth.

In real-time streaming environment the video is uploaded to

the network on the fly from a single device while all other

devices are reading it as it becomes available. However it isimpossible to connect all interested stream recipients to the

streaming device or use peer to peer relaying techniques

used by [12], [13], [14] due to resource constraints such as

CPU power, RAM and available bandwidth on the mobile

device streaming the content. To overcome this problem we

propose a hierarchical structured overlay for distribution of

real-time video streams where devices lacking resources will

become Regular Nodes while resourceful devices become

Super Node. Super nodes form the peer to peer real-time

streaming network and should have adequate bandwidth to

perform this task. The sub overlay formed by the Super Nodes

will handle routing of media streams while Regular Nodes areonly involved in publishing and receiving media streams.

In this environment nodes join the DHT as regular nodes

and may get upgraded to super node status based on their

resource availability such as available bandwidth, CPU power

and RAM. To evaluate the suitability to become a super node

an approach similar to sender selection method discussed in [1]

can be used. The hierarchical overlay is shown in Fig. 2,

regular nodes are depicted as small circles and super nodes as

large circles. The only difference between super nodes and

regular nodes are that.

Only super nodes can function as bootstrap nodes. A node which has been elected as a super node

should at least have one super node as its immediate

neighbour.

Fig. 2 shows a graph satisfying above conditions. The keycharacteristics of such formation are that

Regular nodes always cluster around super nodes. All the super nodes excluding all the regular nodes

should form a sub graph.

This structure guarantees that no traffic other than the

nodes own will pass through a regular node which aretypically less resourceful and typically behind NATed and

firewalled networks like desktops and mobile devices.

Fig. 1 Overlays

Fig. 2 Hierarchical overlay

B. The Tag OverlayTag overlay enables the user to search for live streams in

real-time fashion. The search mechanism described here isimplanted on clients and is not a distributed process. Each tag

on a super node in the tag overlay contains keywords and

associated meta-data objects. A keyword is simply a string

which describes a particular stream. A meta-data object

contains a set of parameters such as stream key (whichidentifies the DHT key of the streaming device) and a

timestamp (if the holding nodes time is greater than the value

of this timestamp the metadata object will be deleted). The tag

overlay or the distributed tag cloud must be populated

accordingly by each user before using the content overlay as


3/5

shown in the Fig. 3. Regular nodes only submit tags to the

overlay and search for tags, super nodes are the node where

those submitted tags are stored and searched for those (note:

super nodes are also regular nodes therefore in addition to

special tasks they too can perform whatever performed by

regular nodes). When a regular node submits a tag and if the

same tag has been already stored in the overlay by a different

device the super node holding the tag will not create a new tag;

instead it will associate incoming meta-data with the existingtag, otherwise a new tag will be created by the destination

super node with associated metadata. In other words there is a

one to many relationship between keywords and tags.

Similarly if a tag has no more metadata objects associated to itthe super node will delete the tag itself from the system thus

freeing the system resources. This mechanism does not allow

for stale tags to last in the system for long periods of time

pointing to dead streams. To avoid premature deletion of a

metadata object the streaming node has to update the

timestamp in the metadata object stored in a super node in atimely fashion by sending messages. Fig 4 shows how

metadata {S0, S1, S6 and S9} has been associated with the tag

Cricket.

Fig. 3 Accessing tag overlay and content overlay separately

In the tag overlay shown in Fig. 4, Bobs device start a

stream by first publishing tags {Cricket, Sri Lanka, Dambulla,

ODI, England}. As depicted in the graph (content overlay) a

tag can have metadata objects that intern has pointers (stream

keys) to multiple streams if multiple devices have streams

tagged with same key word. Bobs stream is identified by the

stream key S6. The tags he submitted to the overlay are now

stored with metadata (S6 in this case1) in super nodes SN1,

SN3, SN4, and SN5.

Once the stream has been made available to the public over

the content overlay it can be contacted by clients through the

stream key after searching for the appropriate key words on

the tag overlay. As shown in Fig. 5, Ted may search for

keywords set {England, ODI, Cricket} and find a set of results,

S6 video stream being the closest match to his query. The

simplest form of this search is given below; however in realitysearch may become a more complex process than given below

1 Metadata data object is identified by the stream key ignoring the timestampfor convenience.

involving a reliability matrix, popularity matrix and

authentication protocols.

Fig. 4 Bobs device starting a stream after setting tags in the overlay

Fig. 5 Streams in action


4/5

TABLE 1

RESULTS TABLE

Key Word ResultsEngland S5, S6, S16

ODI S6, S9

Cricket S0, S1, S6, S9

TABLE 2

WEIGHTS TABLE

Unique Streams Found WeightS6 1

S9 0.66

S0 0.33

S1 0.33

S5 0.33

S9 0.33

The above query produces a set of results consisting of

streams S6, S9, S0, S1, S5 and they are ordered in ascending

order according to a weight function. Weight WSj of the

stream Sj is simply the number of keywords which are

positive for Sj out ofn number of key words (each denoted by

ki) that made up the users query. The formula to this

calculation is given below. If a stream Sj is associated with akey word ki it is denoted by ki,Sj, which can take a value either

0 or 1. If an association is found ki,Sj = 1elseki,Sj = 0.

(2)

As an example S9 appeared for two keywords in the query

consisting keywordsEngland, ODI, Cricketas shown in Table

1. Since there are three keywords involved here . In the above queryS9 is positive for both ODI and Cricket but negative for

England. Therefore , henceaccording to Eq. 2 Ws9 = (1 + 1 + 0)/3 = 0.66 as shown in

Table 2.

C. PeertoPeer Streaming OverlayAccording to the architecture of the system, regular nodes

only stream content to the network (in this case video streams

from devices) while super nodes are responsible of both

delivering streams and streaming to consumers.

The video stream submitted to the content overlay by the

streaming node will be routed to a super node closest to the

stream key of the video stream through the DHT. The super

node which receives this stream from the streaming node

becomes a rendezvous point on the DHT. The stream key ofthe metadata object found as a result of the previously

mentioned search process points to this rendezvous point.

Since all communications happen over the DHT any

intermediate super node in the overlay that falls in the path

between rendezvous point and intended recipient will also

have to read the stream as they are responsible of routing the

stream between two endpoints in the overlay.

LookupStream()i:Signature:

As for , and actions where isa message and j is a UID of a process.

States:

As for , plus: Initially Intially

Transitions:

As for :

Precondition:

As for , plus:If then

End ifEffect:

As for :If then

Else

End if

Effect:

As for in :

Fig. 6 I/O automaton for stream lookup

In Fig 5, the path between streaming node and the

rendezvous point of the stream identified by the key S6 is

given by the edge (SN1, SN4) and path between the end

recipient and the rendezvous point is given by the edge (SN0,

SN1, SN3). In the example Ted searched for key words

Cricket, ODI and Englandand ended up with the stream key

S6 corresponding to a video streamed by Bob. Since Ted

knows the stream key S6 he is now capable of requesting the

overlay to connect his node with the rendezvous point of the

video identified by the stream key S6, thus creating the edge

(SN0, SN1, SN3). After the path SN0 - SN1 - SN3 has been

created on theDHTanRTP connection can be established onthe same path relaying the stream from SN1 to SN3 via SN0.

As depicted in Fig. 5, after Ted starts receiving the stream

Alice who connects to the overlay through SN0 too wants the

same video stream identified by the key S6, but in this case no

new stream paths will be created between super nodes SN0

(Alices super node) and SN1 (the rendezvous point for S6) as

the stream requested by Alice is already passing through SN0.

Therefore SN0 will directly start streaming the video to

Alices node which is connected to SN0 in Fig 5 using RTP.

As a result of this approach only one connection will be


5/5

maintained per video stream between super nodes no matter

how many end users requested to watch the video stream

identified by the same key. This approach for streaming is

very economical due to effective bandwidth utilization and it

resembles the qualities of IP multicasting. In this case it is

possible to visualize the group of nodes which falls on the

same stream path as a multicast group.

The advantage of this architecture is that it ensures at most

one connection per stream is maintained in the sub graphformed by the super nodes. Therefore this model splits the

system bandwidth in to two partitions.

1) Super Node to Super Node Outbound Bandwidth:The network presented by this sub - graph is the most

resourceful network. The bandwidth is used for

streaming between two or more super nodes on

demand. Each super node in between the sender and

the recipient nodes contribute their bandwidth to the

stream established between them.The model can be used to specify the maximum

number of streams that can be streamed

simultaneously in the peer to peer overlay. Let denote the playback rate of the i

thstream on the

network, Let be the super node tosuper node outbound bandwidth of super node .Node is said to be saturated with streams iffollowing condition is satisfied.

(2)

Once a super node becomes saturated no more

streams can be transferred over it. If it is the only way

between a potential sender and a recipient of a stream

then that stream cannot be realized until comes outof the saturated state.

If a super node in the way is found to be saturated

then the saturated super node can forward the stream

establishment request to its super node neighbours

until a super node that streams the intended stream is

found. The I/O automaton is specified in Fig. 6.

2) Super Node to Regular Nodes Outbound Bandwidth:This is the simplest bandwidth management problem

in the system. If a super node has enough bandwidth

more regular nodes can connect to it. Let

be outbound bandwidth of super

node to the direction of regular nodes and be theith

stream transmitted to any of the regular nodes

connected to it. A super node can get saturated by

streaming videos to its regular peers if following

condition is satisfied.

(3)

If a regular node connects to a saturated super node

the super node should transfer the regular node to its

next immediate none saturated super node on the

overlay. This process too can be presented using an

I/O automaton similar to the one given in Fig. 6.

III.FUTURE WORK AND IMPLEMENTATIONFuture work will be done separately on peer to peer

real-time streaming and real-time searching. The stream

lookup algorithm can be simulated before a realimplementation and sender selection and bandwidth

management approaches mentioned in [1], [2], [3] also can be

considered when improving system performance.

Implementation will be done on Linux a platform using

ChimeraDHT. The system will be developed in C++ language

and should be ported to mobile platforms such as MeaGo,

Android and iPhone with appropriate language wrappers if

necessary.

IV.CONCLUSIONApart from entertainment, news and revenue models the

system will have an impact on the society as well. The social

aspect of this utility will ensure the free flow of information

which is quite essential in a free society. Since we are

proposing a free peer to peer platform for heterogeneous

devices such as mobile phones and PCs, reporting of social

events will be drastically changed. The society will be aware

and experience events in real-time due to real-time peertopeer streams which are searchable and capable of being

aggregated in to channels created by users themselves.

ACKNOWLEDGMENT

We thank our peers at Lanka Software Foundation and its

administration for the constructive role they have played while

continuously supporting to refine the concept and by proofreading this article.

REFERENCES

[1] Dongyan Xu , Mohamed Hefeeda , Susanne Hambrusch , BharatBhargava, On Peer to Peer Media Streaming. In Proc. Of IEEE

ICDCS02, 2002, pp 363371

[2] Mohamed Hefeeda, Ahsan Habib, Boyan Botev, Dongyan Xu, BharatBhargava, PROMISE: Peer to Peer Media Streaming Using

CollectCast. In Proc. of eleventh ACM international conference on

Multimedia, 2003, pp 4554

[3] Duc A. Tran, Kien Hua, Tai Do,A Peer to Peer Architecture forMedia Streaming , 2003.

[4] Chimera (n.d.) [Online]. Available:http://current.cs.ucsb.edu/projects/chimera

[5] A. Rowstron and P. Druschel, Pastry: Scalable, decentralized objectlocation and routing for large-scale peer-to-peer systems,Middleware'2001, Germany, November 2001.

[6] Blogspot (n.d.) [Online]. Available: http://www.blogspot.com[7] Wordpress (n.d.) [Online]. Available: http://www.wordpress.org[8] Facebook (n.d.) [Online]. Available: http://www.facebook.com[9] Flickr (n.d.) [Online]. Available: http://www.flickr.com[10] Kazza (n.d.) [Online]. Available: http://www.kazza.com[11] Napster (n.d) [Online]. Available: http://en.wikipedia.org/wiki/Napster[12] TVU (n.d) [Online]. Available:

http://en.wikipedia.org/wiki/TVUnetworks

[13] PPLive (n.d.) [Online]. Available: http://en.wikipedia.org/wiki/PPLivePPStream (n.d.) [Online]. Availabe:

http://en.wikipedia.org/wiki/PPStream

Documents

Real-time Mobile Peer – to – Peer Video Streaming Overlay