Capable of distributing high-bandwidth

INTRODUCTION

PROJECT STATEMENT

Implement a platform independent peer to peer audio and video streaming capable of distributing high-bandwidth live-content to all network peers preserving its quality.

AIM

The study of current multimedia content delivery system and re-molding them to suite peer-2-peer (P2P) environment based on bit-torrent [1] like protocol. Our prime aim is to provide an alternative to the current client-server architecture of audio-video data transfer by using the evolving P2P technology.

A method becoming popular these days consists in using the often idle capacity of the clients to share the distribution of the video with the servers, through the present mature Peer to Peer (P2P) systems. This approach also helps in avoiding local network congestions, because the servers (other clients) can be extremely close of the final client. On the negative side, the main drawback is that the clients (called peers in this context) connect and disconnect with high frequencies, in an autonomous and completely asynchronous way. So, implementing remedies to manage the delivery of the quality needed by the clients in a highly varying environment is also one of our aims.

LITERATURE SURVEY

BASS: BitTorrent Assisted Streaming System for Video-on-Demand

The traditional server-client solution to multimedia distribution is simply to send a separate copy to each client that requests the file. The bandwidth usage at the server scales linearly with the number of concurrent users and a flash crowd can quickly overwhelm the system. For general file distribution, BitTorrent targets this problem by leveraging the upstream bandwidth of the clients [2]. It splits a file into many pieces and sends different pieces to different clients, allowing them to trade pieces amongst each other. Clients that have completed the file and are only uploading are known as seeders and those that are still swapping pieces are leechers. BitTorrent uses a tracker program running on a server (as opposed to a gossip protocol) to disseminate lists of peers. To govern how pieces of the file are requested and swapped amongst peers, it follows rarest-piece-first and tit-for-tat policies, respectively. In rarest-piece-first, the client requests a piece based on the number of copies it sees available and 1chooses the least common one. In tit-for-tat, a leecher reciprocates to other leechers that send it pieces by giving higher priority to their requests. The interested reader is directed to a detailed explanation of the BitTorrent protocol.

P2P Streaming Systems: A Survey and Experiments

P2P streaming systems strive to optimize three important metrics [3]: SETUP delay (i.e. the time from when the user first tunes on the channel to when the video is visible), END TO END delay (i.e. delay between the content originator and the receiver, also known as playback delay) and PLAYBACK continuity (i.e. percentage of received data packets).

Selecting a distribution graph:

Tree-based overlays implement a tree distribution graph, rooted at the source of content. In principle, each node receives data from a parent node, which may be the source or a peer. If peers do not change too often, such systems require little overhead, since packets are forwarded from node to node without the need for extra messages. However, in high churn environments (i.e. fast turnover of peers in the tree), the tree must be continuously destroyed and rebuilt, a process that requires considerable control message overhead. As a side effect, nodes must buffer data for at least the time required to repair the tree, in order to avoid packet loss. Mesh-based overlays implement a mesh distribution graph, where each node contacts a subset of peers to obtain a number of chunks. Every node needs to know which chunks are owned by its peers and explicitly "pulls" the chunks it needs. This type of scheme involves overhead, due in part to the exchange of buffer maps between nodes (i.e. nodes advertise the set of chunks they own) and in part to the "pull" process (i.e. each node sends a request in order to receive the chunks). Thanks to the fact that each node relies on multiple peers to retrieve content, mesh based systems offer good resilience to node failures. On the negative side they require large buffers to support the chunk pull (clearly, large buffers are needed to increase the chances of finding a chunk).

Results of previous experiments:

Startup delay is measured as an average over fifty trials, testing a random channel on each trial. As we can see from Figure 1.1, this value is typically very low, about three seconds in most cases (i.e. we also observed a value of one second, evidently for a content partially saved on the client's hard disk), for an average of ten seconds and a maximum of thirty-five seconds.

Mastering JXTA

In the flow of our literature study we found out that JXTA [4] technology is a set of open protocols that enable any connected device on the network, ranging from cell phones and wireless PDAs to PCs and servers, to communicate and collaborate in a P2P manner. JXTA peers create a virtual network where any peer can interact with other peers and resources directly, even when some of the peers and resources are behind firewalls and network address translations (NATs) or on different network transports.

The JXTA protocols are a set of six protocols that have been specifically designed for ad hoc, pervasive, and multi-hop peer-to-peer (P2P) network computing. Using the JXTA protocols, peers can cooperate to form self-organized and self-configured peer groups independently of their positions in the network (edges, firewalls), and without the need of a centralized management infrastructure.

SCOPE

Software scope describes the data and control to be processed, function, performance, constraints, interfaces, reliability.

Context:

The software works in the areas where identification of the domain specific terms is critically important. It also works in areas where identification process would speed up the functioning of the system unit.

Function And Performance:

The condition under which the software is executing is important like if the software is given insufficient training or is not given enough data to be learnt from.

SYSTEM DESCRIPTION

The system consists of two main parts viz. peer and tracker.

  1. Peer
  2. Peer is software to be deployed on the user machine. It will be responsible for communicating with the tracker and other peers. A peer includes a P2P streaming engine and a media player. The streaming engine trades chunks with partner peers. This component will also display the statistics involved in the transfers in both visual and text format.

  3. Tracker

Tracker is software which accepts and allocates list peers to the requesting peer .For allocating peers an efficient peer allocation policy is implemented on the tracker. Its' also maintains consistency in its peer database.

Each cloud represents a group of peers related to a particular video. Peers in a group may either watch, seed , watch and seed or just store the video in its buffer. It is not necessary that a particular peer can be a part of only one cloud.

For example, if a peer is watching some video X and parallel seeding video Y or may also just store some video Z. In such a case the peer is a part of cloud for all the three videos X, Y and Z.

Media server (or the channel server) is the ultimate source of video for which this system would be trying to reduce load. Examples of video servers which we will come across are "youtube", "metacafe" , "soapbox".

Media Server can be treated as a peer that should be allocated to requesting peers only when there is less number of peers in the cloud of that video.

WORKING OF SYSTEM

P2P video streaming requires a very good content delivery network. There are two ways to implement a peer to peer data distribution graph. We can either use a tree based structure (push mechanism) or a mesh based structure (pull structure) for content delivery. BBVS uses the mesh based structure for content delivery.

Tree Based System

The tree based system have well-organized overlay structures and typically distribute video by actively pushing data from a peer to its children peers. One major drawback of tree-based streaming systems is their vulnerability to peer churn [3]. A peer departure will temporarily disrupt video delivery to all peers in the sub tree rooted at the departed peer P2P media streaming systems. Given a set of peers, there are many possible ways to construct a streaming tree to connect them up. The major considerations include the depth of the tree and the fan-out of the internal nodes. Peers at lower levels of the tree receive video after peers at upper levels. To reduce the delays for peers at the bottom level, one would prefer a streaming tree with fewest levels possible. In other words, the tree topology should fan out as wide as possible at each level. However, constrained by its uploading bandwidth, a peer on an internal node can only upload video at the full rate to a limited number of children peers. The maximum fan-out degree of a peer is bounded by its uploading capacity.

Mesh Based System

Now, we discuss about how the mesh based distribution system works. This being the actual method we have planned to implement, makes it necessary to describe it with much greater details.

In tree-based systems, a peer has only one parent in a single streaming tree and downloads all content of the video stream (or the sub-stream for the multi-tree case) from that parent. This design introduces a single point of failure. If a peer's parent leaves, the peer, as well as its descendants, cannot get streaming feed until it connects to another parent. The management of streaming trees is challenging in face of frequent peer churns. Many recent P2P streaming systems adopt mesh-based streaming approach [3]. In a mesh-based streaming system, there is no static streaming topology.

Peers establish and terminate peering relationships dynamically. At any given time, a peer maintains peering relationship with multiple neighboring peers. A peer may download/upload video from/to multiple neighbors simultaneously. If a peer's neighbor leaves, the peer can still download video content from remaining neighbors. At the same time, the peer will find new neighbors to keep a desired level of connectivity. The high peering degree in Mesh-based streaming systems makes them extremely robust against peer churn. A recent simulation study suggests that mesh-based systems have superior performance than tree-based systems. In this section, we briefly describe several key design components in mesh-based systems.

As shown in Fig. 1.5, mesh-pull P2P architectures [5] have the following characteristics. A video is divided into media chunks and is made available from an origin server for broadcast. All the video information is accessible for users at the channel server. A host, interested in viewing the video, requests the available video streams from the channel server (Step 1 in Fig. 1.5). The tracker server maintains a list of hosts who are interested in watching the same video. After a host selects the video in which it is interested, it retrieves a list of hosts currently watching the same video (Step 2 in Fig. 1.5). The host then establishes partner relationships (TCP/UDP connections) with a subset of hosts on the list (Step 3 in Fig. 1.5). These peers help each other and deliver video traffic cooperatively. The host also may establish a partner relationship with the origin server. Each host viewing the video caches and shares chunks with other hosts viewing the same video. In particular, each host receives buffer maps from its current partners. A buffer map from a remote partner indicates the chunks that are available on that partner. Using a chunk scheduling algorithm, each host requests the chunks that it will require in the near future from its partners. Each host continually seeks new partners from which it can download chunks.

Quick Look at working

When a new peer arrives in the pool it tries to access the media server (link 1) (refer fig 1.5).But BBVS host software routes the request to the tracker (link 2) and gets information related to availability of seeding peers in the P2P network. The new peer then connects to other peers instead of the media server (link 3).

Mesh formation and maintenance

Let's first look at how peers in the same video session form and maintain a mesh topology. Similar to P2P file sharing systems like BitTorrent, a mesh streaming system has a tracker to keep track of the active peers in the video session.

When a peer joins the streaming session, it will contact the tracker and report its own information, such as IP address and port number, etc. Then the tracker will return a peer list that contains the information of a random subset of active peers in the session. The number of peers on a list ranges from tens to hundreds. After receiving an initial list of active peers, the peer will try to make connections to some remote peers on the list. If a connection request is accepted by a remote peer, the local peer will add the remote peer into its neighbor list. After obtaining enough neighbors, the local peer starts to exchange video content with its neighbors. The Fig 1.6 shows the above initial setup process. To deal with frequent peer arrivals and departures, a peer constantly updates its peer list during the session. A peer can go to the tracker to ask for a fresh list of active peers. It can also find new peers by exchanging its peer list with its neighbors through the established connections. If a peer leaves the session gracefully, it will notify the tracker and its neighbors such that its information can be removed from their peer lists immediately. To handle unexpected peer departures, like computer crashes, peers regularly exchange keep-alive messages. A peer will remove a remote peer's information from its list if no keep-alive message is received within a pre-configured timeout period. A peering connection is established based on the mutual agreement between two peers at both ends.

Data Exchange

The basic data unit in mesh-based systems is video chunk. The source server divides the video content into small media chunks, each of which contains media data for a small time interval. Each chunk has a unique sequence number. A chunk with lower sequence number contains video with earlier playback time. Each chunk is then disseminated to all peers through the mesh. Since chunks may take different paths to reach a peer, they may arrive at a peer out of order. For continuous playback, a peer normally buffers received chunks in memory and put them back in order before presenting them to its video media player. Buffered chunks of one peer can be uploaded to its neighbors.

Depending on the system design, a peer might keep several minutes worth of video chunks in the buffer. For live streaming, the sequence numbers of buffered chunks increases steadily as the video playback progresses. There are two major flavors of data exchange designs in mesh-based systems: push and pull [5]. In a mesh-push system, a peer actively pushes a received chunk to its neighbors who have not obtained the chunk yet. In tree based system, a chunk should always be pushed from a peer to all its children peers in the streaming tree.

However, there is no clearly defined parent-child relationship in mesh-based system. Peer uploading bandwidth will be wasted in redundant pushes. And the schedules need to be reconstructed upon neighbor arrivals and departures. One natural way to avoid redundant pushes is to use pull instead of push. In a mesh-pull system, peers exchange chunk availability using buffer maps periodically.

A buffer map contains the sequence numbers of chunks currently available in a peer's buffer. After obtaining buffer maps from its neighbors, a peer can decide a chunk pull schedule that specifies from which peers to download which chunks. Then it will send requests to its neighbors to pull missing chunks. Redundant chunk transmissions can be avoided since a peer only downloads a missing chunk from only one neighbor.

Frequent buffer map exchanges and pull requests do incur more signaling overhead and might introduce additional delays in chunk retrieval. In Fig. 1.5, peer 3 generates its buffer map indicating the chunk availability in its buffer. Then it exchanges its buffer map with peer 1 and 2. Missing chunks will be requested and downloaded among all three peers.

Playing the chunks

After getting the chunks, they are played according to the chronology of their arrival. For this we use a media player which supports the codecs suitable for the transferred video.

The chunks will remain in the hosts' buffers till the user manually clears the buffer or the buffer fills to the maximum extent whichever happens first. Also if the user wants to save the video on his hard-disk, the chunks from the buffer will be encoded in some suitable video format.

What if..
  1. the video demanded by some peer is not available in the P2P network?
  2. In such situation, the tracker will treat the actual media server as a peer and allocate it to the requesting peer.

  3. a peer is miserly donating to the system by poor upload rate?

Such a peer is blacklisted and restrictions on the quality of service for that peer are put, so that it doesn't enjoy the best service with no contribution.

APPLICATIONS

  1. In case of websites which stream stored data (like youtube , metacafe or others), this system would be helpful as it will keep the least number of connections with their media server.
  2. Live streaming in case of news channels like CNN, BBC where the number of viewers may exceed more than a lakh at any instance. At some instant of time like a major accident or other similar event this number may certainly rise high enough to crash the CNN servers. In such situations this system of peer-casting would be very effective.
  3. An user can also share some video on the community without having to register to some video sharing site.

REQUIREMENT ANALYASIS

USER REQUIREMENTS

The system should stream the requested video without any jitter and optimize the bandwidth utilization. This should not put any large burden on the peer in terms of availability of system resources for other local processes.

MEMORY USAGE

The system should not overload the machine causing it to hang. It should be designed by considering the minimum system requirements. As the system may require to upload data more than it has downloaded, it must convert them into such a representation that it takes less memory in case of storage and transfer.

HIGH PERFORMANCE

As the system is supposed to provide multimedia data to the user, the user demands for high quality video and reduced jitter.

SYSTEM REQUIREMENTS

  • Study of streaming technology.
  • Study of video formats.
  • Study of the BitTorrent protocol.
  • Study of JXTA technology.
  • Study of trackers and their functions.
  • Study of media player.

FUNCTIONAL REQUIREMENTS

The system should be capable to stream video to a peer requesting for the same video. The source for this video should be some other peer(s) and not the media server. The user may jump to any time on the time line of the video during the playing the video and the system should be capable to provide the video from the requested position on the timeline. That is, it not a must to see the video in a sequential mode, it may be a random access. The user must be provided to save the watched video for later playback. This functionality should be available during and after the streaming starts. The system must present the statistical data related to the availability of the video, sharing ratio, upload speed, download speed, peers connected to, etc. All these attributes have to be shown in both text and graphical way. The user should be allowed to allocate some manually set bandwidth for streaming out of the total available bandwidth.

SOFTWARE AND HARDWARE REQUIREMENTS

Software requirements

  • Operating System - Windows 2000/Windows XP/Windows Vista, Macintosh, Linux, Solaris or any OS which is compatible with Java Runtime Environment.
  • Media player updated with codecs which are likely to use by the videos on the media server.
  • JXTA for peer to peer protocols.
  • Multimedia drivers

Hardware requirements

  • Minimum 256MB of RAM.
  • Intel Pentium III (or equivalent) CPU running at 500MHz or higher.
  • 100 MB of Hard disk space.
  • Internet connection with bandwidth 256 Kbps or more.
  • Additional hard-disk space to store the selected video to be stored on the disk.

SYSTEM ANALYSIS REPORT

System Engineering

BBVS uses a tracker program running on a server to disseminate lists of peers. Peer side program is responsible for updating the tracker about its aliveness and place request at the tracker for some new video to get a list of peers as a response. Peer is a source for the video it has downloaded.

Developing such a system will consist of three phases:

  1. Design phase: The working, control flow, data flows are decided and represented in this phase. We used the UML 2.0 notations to describe our system design.
  2. Implementation phase: In this we will actually program the machine to implement our design using JAVA.
  3. Testing Phase: In the testing phase, the system will be tested for various test cases at our site. Both black box and white box testing will be done and the system will be routed back to the implementation phase to remove the bugs, if any. The system will be then deployed for beta testing.
  4. Analysis: The analysis module is used to check the performance of the system and accuracy of the same is calculated.

System goals

The primary goal of our system is to reduce load on the media servers. When a particular video is viewed on a larger scale it results in tremendous load on the media servers. This load can be reduced by only providing other source for that video. Our system is one way to provide such alternate source in the form of peers.

We also aim to provide high bandwidth input to each client.

System constraints

The system constraints are as follows:

  • The number of peer if fall below the minimum required level then the system looses its significance. As the behavior of the video player is similar to a normal VoD. So for better performance the number of peers using the application should be more.
  • The bandwidth allocated to a particular peer by its ISP should be more than the bitrate of the video.
  • The ISP should allow maximum uploading capacity to the peers in the P2P pool.

System Performance:

The system performance mainly depends on the availability of peers willing to seed and make some contribution to the working of the system. The performance also depends on some network hardware issues like the poor connectivity to the internet, the power cuts etc.

SYSTEM DESIGN

The design of the system is categorized by the flow of data and control.

DATA FLOW DIAGRAMS

It represents the raw context into which the process fits. It shows the overall process as a single system. It shows the outside entities like Entity User or Entity Document which either receive information or contribute information to the system.

REFERENCES

  1. BitTorrent Protocol, http://www.bittorrent.org/beps/bep_0003.html,30-AUG-2009.
  2. Chris Dana, Danjue Li, David Harrison, Chen-Nee Chuah, "BASS: BitTorrent Assisted Streaming System for Video-on-Demand", Multimedia Signal processing, 2005 IEEE 7th Workshop on(2005), pp. 1-4.
  3. Yong Liu, Yang Guo, Chao Liang, "A survey on peer-to-peer video streaming systems", Springer Science + Business Media, 10 January 2008.
  4. Joseph D. Gradecki, Joe Gradecki, "Mastering JXTA: Building Java Peer to-Peer Applications", ISBN: 0471250848.
  5. Xiaojun Hei, Yong Liu, and Keith W. Ross, "IPTV over P2P Streaming Networks: The Mesh-Pull Approach, IEEE Communications Magazine, February 2008.

Please be aware that the free essay that you were just reading was not written by us. This essay, and all of the others available to view on the website, were provided to us by students in exchange for services that we offer. This relationship helps our students to get an even better deal while also contributing to the biggest free essay resource in the UK!