1 / 42

Stable Interactive Broadcast System Final Presentation

SiBS. Stable Interactive Broadcast System Final Presentation. Created By : Dani Shaket Ran Zeller. Supervisor : Alexander Shraer. SiBS. Presentation outlines General Project goals System description Design and implementation Summary and conclusions

violet-best
Download Presentation

Stable Interactive Broadcast System Final Presentation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. SiBS Stable Interactive Broadcast SystemFinal Presentation Created By : Dani Shaket Ran Zeller Supervisor : Alexander Shraer

  2. SiBS Presentation outlines • General • Project goals • System description • Design and implementation • Summary and conclusions • Example

  3. General • Online applications today, often suffer from low stability and performances. • These problems can be moderate using smart resource sharing. • Our solution, is a system where each service provider (server) “knows” all the other servers and together they can provide a better solution for online applications. • In this project we apply this solution to create a virtual class-room, which provides three multi-user applications :Text Chat, Drawing Pad and Media Streaming.

  4. General – cont. • The SiBS is composed out of two main programs, the Server and the Client. • The Client application provides the user with easy-to-use Graphic Interface that enables the user to Create, join and participate sessions. • The Server application provides multi-session management, extremely high stability and survivability , ensuring continuity , disaster recovery and maximizing Quality/Cost Ratio by joining resources. • The Server can run in stand-alone mode , or as a servers-group member.

  5. Project Goals • implement a multi-threaded application in the java. • Learn and use the ensemble group-communication package. • Learn and use the JMF (Java Media Framework) package. • Learn and use the SIP (Session Initiation Protocol) and the Jain-Sip Package. • Design a system using the OOP methodology. • implement User Graphic Interface. • explore some characteristics of performance & Quality measures and timing issues.

  6. System Description Servers Group Server Server Server Server Server Session 1 Session 2 Session 4 Session 3 Manager Manager Client Client Client Manager Client Client Manager Client Client Client Client

  7. System Description - Algorithms • Servers Start-up • Client Log-in • Session creation • User Join • Session Action – Stream • Auction • Session resumption / recovery • Session Management delegation • Drawing Pad algorithm

  8. System Description - StartUp Server First server start-up - Sync: View synchronization. - Heal: Partitions healing. - Migrate: process migration. - Frag: Message fragmentation re-assembly. - Switch: allow on-the-fly protocol switching - Suspect: failure detection - Flow: flow control - Total: Total order messaging

  9. System Description - StartUp • The Server Reads configuration files and apply setup :Server ID, Known clients, available media list etc… • Try to connect to the group – no one available yet Server*Israel

  10. System Description – Group ServerUSA • China and USA servers starts and form a group • A leader is chosen ( arbitrary ) *ServerIsrael ServerChina

  11. System Description-Login ServerUSA *ServerIsrael ServerChina • A Client, Sends Login request to Israel Server LogIn ClientAvi

  12. System Description-Login ServerUSA *ServerIsrael ServerChina • The Israeli server respond with Login success and empty known sessions list Login Success Session List Empty ClientAvi

  13. System Description - Session Creation ServerUSA *ServerIsrael ServerAustralia • Avi requests session creation called SiBS tutorial, with some otherparameters Create Session ClientAvi

  14. System Description- Session Creation Session Created Session Created ServerUSA *ServerIsrael ServerChina • The Server creates a session called SiBS tutorial, that sends Invite message to Avi as Session Master. • The Server broadcast Session creation message to the the other servers, and the session start to sending Session State message periodically. Session state Session state SibS Invite ClientAvi

  15. System Description - Join ServerUSA *ServerIsrael ServerChina • Client John, request login from USA server. • The server respond with Login Success, and Sessions List, including SiBS tutorial session Login SibS Success ClientJohn ClientAvi

  16. System Description - Join Join From User ServerUSA *ServerIsrael ServerAustralia ServerChina • Client John, request to Join SiBS tutorial Sesssion. • The server notice that the SiBS session is not hosted by him, so he broadcast Join From User Message SibS Join SiBS ClientJohn ClientAvi

  17. System Description - Join ServerUSA *ServerIsrael ServerAustralia ServerChina • Israeli Server recognized that the session is hosted by him, and handle the join Request. • The China Server Disregard the message SibS Invite ClientJohn ClientAvi

  18. John’s View

  19. System Description - Stream ServerUSA *ServerIsrael ServerAustralia ServerChina • Client Avi request Start Streaming Media from SiBS tutorial room • The SiBS tutorial room start broadcasting the requested media to Avi And John SibS StartStream ClientJohn ClientAvi

  20. System Description - Auction ServerUSA *ServerIsrael ServerAustralia ServerChina • four enthusiastic Chinese investors , Ying , Young, Hu and Fu, Login and join The SiBS tutorial session. SibS ClientYing ClientYoung ClientJohn ClientAvi ClientHu ClientFu

  21. System Description - Auction Auction On SiBS Auction On SiBS ServerUSA *ServerIsrael ServerAustralia ServerChina • SiBS tutorial Session, recognize that his Quality & Cost is getting lower. • The Server, decide to start an Auction Process. SibS ClientYing ClientYoung ClientJohn ClientAvi ClientHu ClientFu

  22. System Description - Auction ServerUSA *ServerIsrael ServerAustralia ServerChina • Each one of the server checks Ping-Pong Time for each one of the users, in addition to static Cost calculation. • The servers respond calculate the “what if” Quality and Cost value. SibS ClientYing ClientYoung ClientJohn ClientAvi ClientHu ClientFu

  23. Quality and Cost calculation • Min Quality = 0 , Max Quality = 1000. • Ping-Pong time (echo time) is measured in miliSec. • Each client has a specific Cost ( from 1-1000) on a each server. • Example: user Fu from china will have cost = 300 on Israel server and cost = 50 on china server • The calculation is : QoS = 1000 – AveragePingPongTime – Average Cost( if QoS < 0, Qos = 0 ) • Session Quality level for auction process is const = 500

  24. System Description - Auction I Bid 400 I Bid 800 ServerUSA *ServerIsrael ServerAustralia ServerChina • Since Israel Server is also the leader, he manages the Auction • The winner of the Auction will be the China Server SibS ClientYing ClientYoung ClientJohn ClientAvi ClientHu ClientFu

  25. System Description - Auction Winner ServerUSA *ServerIsrael ServerAustralia ServerChina • China Server creates a new session called SiBS$1 ( which means transfer number 1) and Invites all users to that session • The clients join the new SibS$1 session and leave the old session SibS $1 SibS ClientYing ClientYoung ClientJohn ClientAvi ClientHu ClientFu

  26. System Description – Recovery ServerUSA *ServerIsrael ServerAustralia ServerChina • The China server crashes SibS $1 ClientYing ClientYoung ClientJohn ClientAvi ClientHu ClientFu

  27. System Description – Recovery Take OverSiBS$1 session ServerUSA *ServerIsrael • The Israeli server ( and the USA server ) recognize a That the Chinese server is down. • The Israeli server , as the leader, select The USA server to resume the orphan session SibS $1 ClientYing ClientYoung ClientJohn ClientAvi ClientHu ClientFu

  28. System Description – Recovery Take OverSiBS$1 session ServerUSA *ServerIsrael • The USA server creates a new Session called SiBS$2, and invites all users to join ( same as in auction process). SibS $1 SibS $2 ClientYing ClientYoung ClientJohn ClientAvi ClientHu ClientFu

  29. System Description – Recovery ServerUSA *ServerIsrael • The session Resumed SibS $2 ClientYing ClientYoung ClientJohn ClientAvi ClientHu ClientFu

  30. System Description – Management Delegation ServerUSA *ServerIsrael SibS $2 ClientYing ClientYoung ClientJohn ClientAvi ClientHu ClientFu • Client Avi is currently the Master of the session. • The Management delegation can be configured as • Exclusive • Random Privilged • Chain of command

  31. System Description – Management Delegation ServerUSA *ServerIsrael SibS $2 Become-Master ClientYing ClientYoung ClientJohn ClientHu ClientFu • The Session recognized that Client Avi does not respond to Ping messages and decides that Client Avihave left. • The session sends a BECOME_MASTER message to the selected client ( according to setup). • The session can become Master-less, meaning no master action can occur.

  32. System Description – Drawing Pad • The Drawing pad panel, composed out of two panels : • Control Panel – Select color / tool / width , clear • Graphics panel – Java Graphic 2D object with the ability to present shapes. • When the user want to paint an object, he select a tool ( only pen is implemented) color and a width. • When the user left-click on the graphics panel, the application records 2 to 20 points until the mouse is released. • When the recording is finished, a Drawing message is sent to the server , and the server forwards it to the members of the session. example :From sip:Deleg$0@132.68.60.75:5075 : DRAW;PEN;3;13;29 335 28 335 30 335 38 336 50 337 62 337 77 337 92 340 108 342 120 343 131 343 145 343 156 344 168 344 181 344 189 344 197 344 204 344 213 342 226 337 235 335 244 333 254 329 264 327 272 326 277 326 279 326 284 326 293 326 301 326 ; • The Client who receive this message, paint the shape on its Graphics panel. • If two or more clients are drawing together, the shape which sent earlier will be in the back.

  33. Drawing Pad

  34. Design and implementation - Server

  35. Design and implementation - Server • infraStructure Package • SubManager – Messaging service, Timers • Ensemble Communication channel • Sip Communication channel / Sip Multiplexer • JMF’s AV-Transmitter • Server Package • Server Manager • Login Manager • Session Manager • QoS Manager

  36. Server System Recovery Manager Servers Server * Ensemble QoS Manager * Login Manager Session Manager • The Server • Each Square represents a Subsystem • The application will be build over an infrastructure that provides Messaging between subsystems and Multithreading support. Sip Multiplexer * Clients

  37. Design and implementation - Client • Client Manager • Client State • Communication ( SIP ) • Client GUI • Main Frame • Login Tab • Streaming Tab • Chat Tab • Drawing Pad Tab

  38. Client System Client GUI Media Player • The Client • Each Square represents a Subsystem • The application will be build over an infrastructure that provides Messaging between subsystems and Multithreading support. Sip Layer JMF Data Source Server

  39. Summary • In this project we have designed and implemented the Stable interactive Broadcasting System (SiBS) which provides three multi-user online applications: Text Chat, Drawing Pad and Media Streaming, that runsin a context of a Session. • The SiBS provides extremely high stability and survivability , ensuring continuity , disaster recovery and maximizing Quality/Cost Ratio by joining resources, in order to give the Users the best possible solution. • During the design and implementation we have learned to use : Java under eclipse, multithreading , Ensemble, JMF, SIP, GUI design, OOP and more.

  40. Conclusions • During the implementation we have encountered problems related to JMF and timing. Internet oriented /online applications should be as timing-independent as possible. • Scalability/Stability tradeoff – enable user to select. • Servers system is not scalable , but stable. • Session management is scalable for users. • Ensemble provides easy interface and good performances in addition to reliable communication • JMF is bad ( bad design, bad API, bad compatibility, bad performances, bad documentation, bad stability )

  41. Options for the future • The SiBS can have a place in the “real world”, where stability is needed. • The project is build using the OOP methodology , enable to easily change parameters, add features and applications, changing communication protocols etc.. it can be used as a base for future realistic applications. • The algorithm for Auction decision can be improved in many ways – a possible subject for research : • Dynamic auction limit/Panic limit • Compare “what if” QoS with the real one / use statistics • Geographic distance vs. Ping-Pong time – is there really a correlation ? Change metrics ? • Implement group-communication ourselves – can be very interesting.

  42. Questions ???

More Related