Unibo Streaming Project

Presentazione sul tema: "Unibo Streaming Project"— Transcript della presentazione:

1 Unibo Streaming Project
Un applicazione Client/Server per la gestione di streaming audio/video multicast e on-demand Progetto per il corso di Reti di Calcolatori L-S realizzato da Loris Cancellieri matr

2 Agenda In questa presentazione parleremo di: Streaming RTSP RTP / RTCP
Unibo Streaming System Applicazione Protocolli Politiche di Load Balancing e Disaster Recovery Demo dell’applicazione

3 Introduzione allo streaming
Cos’è lo streaming? metodo di trasferimento dei file che permette di riprodurre il file mentre lo si sta scaricando Vantaggi?: fruizione istantanea dei contenuti risparmio spazio su disco Applicazioni?: Audio e Video On-Demand VideoConferenze Web TV Internet Radio

4 Distribuzione dei contenuti
Nell’Unibo Streaming Server si usa sia la distribuzione multicast dei contenuti che quella unicast. MULTICAST Server Server 99 copie Switch 1 copia Switch UNICAST Router Router 1 copia 33 copie Router Router Router Router Router Router Switch Switch Switch Switch Switch Switch 33 clients 33 clients 33 clients 33 clients 33 clients 33 clients

5 Protocolli per lo streaming
RTSP Controllo Stream Informazione RTP SDP v=0 o=StreamingServer s=TrasmissioneFile i=Descrizione della sezione u= p= c=IN IP b=AS:2048 t=0 0 a=charset:ISO m=audio 2000 RTP/AVP 14 a=rtpmap:14 MPA/44100 a=control:rtsp:// /audio a=mimetype: audio/MPA a=range:npt=0-264 SERVER Audio CLIENT Video Si parla dei protocolli di streaming e durante la trattazione sottolineare come per la trasmissione dell’informazione il server e il client usano il protocollo SDP (Session Description Protocol) per la descrizione del file multimediale e della sessione. RTCP Monitoraggio Monitoraggio

6 Protocolli di Streaming
RTCP Application UDP perchè: Minore Overhead Reazione più veloce alle congestioni della rete Traffico nella rete più gestibile Traffico realtime senza ritrasmissione Transport Network La slide mostra la collocazione dei vari protocolli di streaming all’interno della classificazione OSI Controllo Dati

7 Real Time Streaming Protocol
Simile ad HTTP: Protocollo testuale Messaggi con struttura predeterminata Differisce da HTTP perchè Contiene informazioni di stato (CSeq) Bidirezionale (Cioè sia il client che il server possono lanciare una richiesta RTSP) Comandi Obbligatori Describe Setup Play Options Teardown Per analizzarne il funzionamento faccio riferimento al modo in cui esso lavora all’interno della mia applicazione Comandi Facoltativi: Pause (auspicabile) Record Announce Set Parameter Get Parameter (dal server) Redirect (dal server)

8 Real Time Streaming Protocol
DESCRIBE rtsp:// /L4.mp2 RTSP/1.0 CSeq: 631 Accept: application/sdp User-Agent: JMF RTSP Player Version 2.1.1e RTSP/ OK CSeq: 631 Content-type: application/sdp Content-Length: 394 Real Time Streaming Protocol Describe + OK_Describe + SDP_Length SDP Info SERVER MAIN Client v=0 o=StreamingServer (creator) s=TrasmissioneFile (name) i=Sessione di trasmissione del file richiesto u= (Loris Cancellieri) p= c=IN IP b=AS:2048 t=0 0 a=charset:ISO m=audio 2000 RTP/AVP 14 a=rtpmap:14 MPA/44100 a=control:rtsp:// /audio a=mimetype: audio/MPA a=range:npt=0-264 Messaggi C -> S Messaggi S -> C Info Addizionali Messaggi RTSP

9 Real Time Streaming Protocol
SETUP rtsp:// /audio RTSP/1.0 CSeq: 632 Transport: RTP/AVP;unicast;client_port= User-Agent: JMF RTSP Player Version 2.1.1e RTSP/ OK CSeq: 632 Session: Transport: RTP/AVP; unicast; client_port= ; server_port= ; Bandwidth:128000 Real Time Streaming Protocol Describe + OK_Describe + SDP_Length SDP Info Setup + client_ports SERVER MAIN Client OK_Setup + Server_ports + Session_ID Messaggi C -> S Messaggi S -> C Info Addizionali Messaggi RTSP

10 Real Time Streaming Protocol
PLAY rtsp:// /L4.mp2 RTSP/1.0 CSeq: 633 Range: npt=0.0- Session: User-Agent: JMF RTSP Player Version 2.1.1e RTSP/ OK CSeq: 633 Session: Real Time Streaming Protocol Describe + OK_Describe + SDP_Length SDP Info Setup + client_ports SERVER MAIN Client OK_Setup + Server_ports + Session_ID Play + Session_ID + Range OK to Play + SessionID Dati RTP RTCP Messaggi C -> S Messaggi S -> C Info Addizionali Messaggi RTSP

11 Real Time Streaming Protocol
PAUSE rtsp:// /L4.mp2 RTSP/1.0 CSeq: 634 Session: User-Agent: JMF RTSP Player Version 2.1.1e RTSP/ OK CSeq: 634 Session: Real Time Streaming Protocol Describe + OK_Describe + SDP_Length SDP Info Setup + client_ports SERVER MAIN Client OK_Setup + Server_ports + Session_ID Play + Session_ID + Range OK to Play + SessionID Dati RTP RTCP Pause + Session_ID Messaggi C -> S OK_Pause + Session_ID Messaggi S -> C Info Addizionali Messaggi RTSP

12 Real Time Streaming Protocol
TEARDOWN rtsp:// /L4.mp2 RTSP/1.0 CSeq: 638 Session: User-Agent: JMF RTSP Player Version 2.1.1e RTSP/ OK CSeq: 638 Session: Real Time Streaming Protocol Describe + OK_Describe + SDP_Length SDP Info Setup + client_ports SERVER MAIN Client OK_Setup + Server_ports + Session_ID Play + Session_ID + Range OK to Play + SessionID Dati RTP RTCP TearDown + Session_ID Messaggi C -> S OK_TearDown + Session_ID Messaggi S -> C Info Addizionali Messaggi RTSP

13 Real Time Streaming Protocol (descrizione come Automa a Stati Finiti)

14 Session Description Protocol
v= (versione del protocollo) o= (creatore del file e identificatore di sessione) s= (nome della sessione) i=* (informazioni sulla sessione) u=* (descrizione del URI ) e=* (indirizzo ) p=* (numero di telefono) c=* (informazioni sulla connessione) b=* (informazioni sulla banda) Protocollo usato per la descrizione di una sessione multimediale a scopo di annuncio (SAP), invito (SIP) o per altre forme di inizio sessione (RTSP) Non incorpora un protocollo di trasporto Non supporta la negoziazione dei contenuti e/o della codifica dei media La descrizione SDP consiste di linee di testo <tipo> = valore In una descrizione in formato SDP si possono individuare tre parti principali: Descrizione della sessione (una e una sola) Informazioni temporali (una o più) Descrizione del media file (una o più) m= (formato multimediale e indirizzo di trasporto) i=* (titolo del media) c=* (informazioni di connessione, opzionali se incluse a livello di sessione) b=* (informazioni sulla banda) k=* (chiave di codifica) a=* (zero o più linee di attributi) t= (tempo in cui la sessione è attiva) r=* (ripetizioni temporali: settimanali, ecc.) z=* (cambio di fuso orario) k=* (chiave di codifica) a=* (zero o più linee di attributi)

15 Real-time Transport Protocol
Presentato per la prima volta nel 1996 (RFC1889) è stato poi revisionato nel 2003 (RFC 3550) Trasmissione dati aventi riferimenti temporali Indipendente dai protocolli sottostanti (tipicamente viaggia su UDP) No resource reservation Sicurezza: supporto per la cifratura con algoritmi a blocchi Separazione tra dati e controllo (RTP & RTCP) Sessione formata da due indirizzi di trasporto uno per RTP e uno per RTCP. Es: :2600 RTP e :2601 RTCP Audio e Video viaggiano separati in due sessioni RTP distinte e la sincronizzazione avviene tramite una o più Syncronization Source (SSRC) su RTCP Semplificazione - RTP Header Payload type Sequence Number TimeStamp Synchronization Source Identifier Header Extensions 7 bits 128 tipi differenti di codifica 16 bits usato per scoprire eventuali perdite di pacchetti 32 bits istante di sampling del primo byte nel payload del pacchetto 32 bits ID della sorgente dello stream Vedi Pacchetto

16 Real-time Transport Protocol
v (2-bit) version numbers P (1-bit) padding X (1-bit) header extensions CC (4-bit) CSRC count M (1-bit) marker PT (7 bits) payload type Back

17 Real-time Control Transport Protocol
Protocollo usato per il feedback e il controllo della sessione RTP Pacchetti RTCP vengono inviati periodicamente da tutti i partecipanti alla sessione, sia sender che receiver Bisogna trovare il giusto compromesso fra pacchetti RTP e pacchetti RTCP per problemi di occupazione di banda. Il rapporto RTCP / RTP non dovrebbe essere superiore al 5% I tipi principali di pacchetti RTCP sono: Sender Report (SR) associazione tra timestamp e tempo reale Bitrate Receiver Report (RR) Packet Loss Rate Jitter Round-trip delay Source Description (SDES) Canonical Name (CNAME) (Es: usato per l’associazione tra sessioni audio e video della stessa sorgente Nome, , location Terminazione (BYE) Specifici dell’applicazione (APP)

18 Politiche di Load-Balancing
Per limitare il carico su un singolo nodo di streaming, è possibile limitare il numero massimo di client serviti contemporaneamente. Quando questo limite viene raggiunto, il server risponde ad altre richieste dei client mandando loro un messaggio di REDIRECT verso un’altra location Describe rtsp:// /L4.mp2 CSeq: 231 Nodo RTSP/ Moved CSeq: 230 Location: rtsp:// /L4.mp2 Describe rtsp:// /L4.mp2 CSeq: 230 Nodo

19 Politiche di Fault Tolerance (funzionamento del sistema a regime)
Soluzione con Control Server e Slave Server (copia fredda) RTSP RTP / RTCP SlaveServer File_Request medialist xml STAND-BY Per cercare di individuare e mantenere le funzionalità anche in caso di guasto è stata implementata una politica con un server di controllo che «pinga» periodicamente il MainServer per rilevare eventuali cadute, registre i client connessi per avvisarli in caso di malfunzionamento e attiva uno slave server per il recupero della funzionalità del sistema. MainServer Nodo ping ControlServer Nodo Reply_ping Nodo

20 Politiche di Fault Tolerance (crash del sistema)
RTSP RTP / RTCP SlaveServer medialist xml File_Request STAND-BY Per cercare di individuare e mantenere le funzionalità anche in caso di guasto è stata implementata una politica con un server di controllo che «pinga» periodicamente il MainServer per rilevare eventuali cadute, registre i client connessi per avvisarli in caso di malfunzionamento e attiva uno slave server per il recupero della funzionalità del sistema. MainServer Nodo ping ControlServer Nodo Reply_ping Nodo

21 Politiche di Fault Tolerance (reazione al crash)
REDIRECT rtsp:// /file.ext RTSP/1.0 CSeq: 1 Location: rtsp:// SlaveServer MainServer Per cercare di individuare e mantenere le funzionalità anche in caso di guasto è stata implementata una politica con un server di controllo che «pinga» periodicamente il MainServer per rilevare eventuali cadute, registre i client connessi per avvisarli in caso di malfunzionamento e attiva uno slave server per il recupero della funzionalità del sistema. Nodo START_SLAVE Nodo ControlServer Initializing CRASHED Nodo

22 Politiche di Fault Tolerance (nuova situazione di funzionamento)
RTP / RTCP RTSP File_Request medialist xml SlaveServer MainServer Per cercare di individuare e mantenere le funzionalità anche in caso di guasto è stata implementata una politica con un server di controllo che «pinga» periodicamente il MainServer per rilevare eventuali cadute, registre i client connessi per avvisarli in caso di malfunzionamento e attiva uno slave server per il recupero della funzionalità del sistema. Nodo ControlServer ACTIVE Nodo CRASHED Nodo

23 Demo dell’applicazione
It's ShowTime

24 (c) 2005 Loris Cancellieri