Diese Präsentation wurde erfolgreich gemeldet.
Die SlideShare-Präsentation wird heruntergeladen. ×

Bluetube

Weitere Verwandte Inhalte

Ähnliche Bücher

Kostenlos mit einer 30-tägigen Testversion von Scribd

Alle anzeigen

Ähnliche Hörbücher

Kostenlos mit einer 30-tägigen Testversion von Scribd

Alle anzeigen

Bluetube

  1. 1. “The most profound technologies are those that disappear” - Mark Weiser
  2. 2. Outline  Goal  Motivation  Challenges of video streaming over Bluetooth PAN  Our approach  Evaluation of approach  Implementation  Demo  Conclusion The University of Texas at Austin 2
  3. 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. 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. 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. 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. 7. Logical Topology of the System
  8. 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. 9. The Notion of Generations
  10. 10. Join Algorithm
  11. 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. 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. 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. 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. 15. SAR [Theoretical]
  16. 16. Average Jitter [Theoretical]
  17. 17. Workload distribution [Simulated]
  18. 18. Bluetube Implementation
  19. 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. 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. 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. 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. 23. Demo
  24. 24. What about a real device??
  25. 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. 26. We had a dream… Thank you

×