Bluetube
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Bluetube

on

  • 320 views

 

Statistics

Views

Total Views
320
Views on SlideShare
313
Embed Views
7

Actions

Likes
0
Downloads
0
Comments
0

2 Embeds 7

http://www.linkedin.com 5
https://www.linkedin.com 2

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Bluetube Presentation Transcript

  • 1. “The most profound technologies arethose that disappear” - Mark Weiser
  • 2. Outline Goal Motivation Challenges of video streaming overBluetooth PAN Our approach Evaluation of approach Implementation Demo Conclusion The University of Texas at Austin 2
  • 3. Goal• Tie up three promising technologies – Video On Demand, Bluetooth, P2P• To provide video on demand services in Bluetooth , using pure P2P approach• A Pure P2P approach has a broader range of applicability, as one need not rely on server infrastructure anywhere . [as needed for a Hybrid P2P approach]
  • 4. Motivation• Increased usage of Bluetooth devices• Promises of Bluetooth 3.0 – data rates up to 480Mbps, energy efficient – making them a very attractive platform for development of ‘Smart Applications’• Video-On-Demand is one of the most popular applications of the past decade• P2P applications call the shots, in today’s Internet. Eg: Skype, Yahoo Messenger, Gnutella
  • 5. Challenges• Low end devices ; Devices can barely handle video processing• Limitations of current Bluetooth technology (data rates only upto 2.0Mbps)• A single sender – N recipients problem that can cause a bottleneck at the sender• Fault tolerance is difficult to achieve in a dynamic environment• Load balancing issues need to be addressed• Support multiple sessions at the same server
  • 6. Solution Sketch• One video session per request will overload the server , which is also a low end device• Simple 1 to N broadcast of video chunks from the Server will not work• Server directly serves only some clients.• A content distribution tree is formed amongst the clients• Early client serve late coming clients
  • 7. Logical Topology of the System
  • 8. Benefits of introducing Head Node• A client can have only a single video session. A server can support multiple server sessions.• Out bound bandwidth is limited (about 200 kilobytes per second only)• An attempt to achieve optimal load balancing throughout the entire network• Server serves only one node per session• Seems a good idea. But …
  • 9. The Notion of Generations
  • 10. Join Algorithm
  • 11. Catalog Maintenance• Build a global catalog using periodic exchange of control information (Send only updates, not the entire data) and query it locally• Provides fast search times• Use soft state with ER• Some information that this catalog could store are video lists at other nodes, current buffer usages, message processing backlogs, processor utilization and number of active server sessions• Optimize by writing expired state to disk and garbage collect later
  • 12. Fault Tolerance• Failure of Head Node – Replicate the Head Node – Promote a child as head node when the server cannot support head node replication• Failure of Server – Can do something about the intermittent failures of the servers by buffering future chunks at other nodes – Bandwidth is free. No issues• Failure of Client nodes – Handled as in P2VOD
  • 13. Load balancing• Head node can become too overloaded for large G. [Large G offers higher fault tolerance].• Hence, head node can be replicated to overcome this bottleneck• A dynamic load balancing algorithm that can adapt the amount of replication and G, based on current load
  • 14. Metrics• Service Acceptance ratio : Given the parameters that model the system, what percentage of nodes can successfully join the system and receive the services• Workload : The amount of work that is pending at each node at any particular time.• Jitter : The amount of time a node waits for services during a given finite duration run of the protocol
  • 15. SAR [Theoretical]
  • 16. Average Jitter [Theoretical]
  • 17. Workload distribution [Simulated]
  • 18. Bluetube Implementation
  • 19. Bluetube: Key points• Currently supports MPEG-1 videos (good starting point)• Video splitting – Videos are split into chunks (beforehand) and stored• Application launched as server or client at any given instant• Supports late coming peers• RFCOMM
  • 20. Server properties• Selectively publishes videos• Listens for client requests• Upon receiving video request, sends “chunks” of the video to client• Can handle multiple client requests (upto a maximum of 6)
  • 21. Client properties• Performs a devices search followed by services search• Published videos get displayed on client screen• Client selects a video to play• Receives video chunks from server• Chunk player plays chunks while buffering remaining chunks
  • 22. Development Environment• Sun Java Wireless Toolkit 2.5.2 for CLDC – Formerly known as J2ME Wireless Toolkit• Key features: – Emulation environment designed to run applications on cell phones – Performance optimization and tuning
  • 23. Demo
  • 24. What about a real device??
  • 25. Concluding remarks• A first-of-its kind effort• Establishes that reality is not far• Future focus on using Gossip based protocols for improving performance• Further analysis on intermittent server failure handling• Better load balancing scheme
  • 26. We had a dream… Thank you