Archive for gennaio, 2007
Peercast, ovvero come aggirare il problema banda
gennaio 31, 2007 8:01 pm
Diciassettesimo articolo dedicato alle web radio.
Si è già parlato teoricamente di P2P e radio, ma adesso vediamo come potere affrontare concretamente il problema.
Creare dei relay con shoutcast è possibile, ma non sempre semplice e fattibile, in quanto anche ripetendo il segnale, si incorre in un cambiamento di indirizzo.
Il problema è (parzialmente) risolto da Peercast, un programma disponibile per tutti i sistemi operativi, che permette lapolitica monorelayed radio SENZA cambiamento di indirizzi.
Esaminiamo la pagina dedicata a Peercast sulla Wiki Inglese che dice:
PeerCast is an open source streaming media multicast tool. PeerCast uses peer to peer technology to minimize the necessary upload bandwidth for the original multicastor.
Ovvero: “Peercast è uno strumento per lo streaming audio/video open source. Peercast usa la tecnologia Peer to peer per minimizzare la necessaria banda in upload del trasmettitore originale”.
Peercast can be used to multicast streaming audio (Ogg Vorbis, MP3, WMA) and/or video (Ogg Theora, Nullsoft Streaming Video, or WMV), or any other stream of data, over the internet. Peercast uses a distributed bandwidth technique to lighten the load of the broadcaster’s upstream bandwidth where each listener/viewer will relay the stream they download to one or more additional listeners. Users may choose how many relays to allow, and if a listener sets their relays to ‘0′, then they will essentially not contribute back to the stream at all.
In sintesi, Peercast implementa il metodo Mono Relayed Radio, ovvero ogni ascoltatore può decidere se e quanti altri ascoltatori contribuire a servire. In pratica Peercast vi permette di trasformarvi da nodi rossi a nodi verdi.
When a relay is lost, all peers underneath it (might) lose their connection to the stream and must reconnect to another relay, also when reconnecting to another relay, a peer (might) have to accept the point in the stream the new relay is at, potentially causing a skip or repeat in the stream.
Quando un ripetitore si disconnette, si disconnettono tutti gli utenti ( e anche gli altri relay ) a lui correlati (in pratica non funzionano più tutti i suoi sottoalberi) e gli utenti devono connetersi ad un altro relay. Se questo ha un ritardo differente dal relay che li ha disconnessi, potrebbero ipoteticamente sentire di nuovo una parte dello streaming gia sentita.. o perdersene una parte.
Corporate environments and their security policies might not appreciate the fact that it uses peer-to-peer technology and essentially turns listeners by default into servers.
Since it turns all of the network in a server, distributing content for which you might not have a license could cause legal concerns, depending on the jurisdiction and local legislation the node falls under.
Tradotto in una riga: “SIAE e SCF lo proibiscono”
Lasciamo adesso la pagina Wiki dedicata a Peercast e buttiamoci direttamente alla sorgente. In questa pagina si trova un elenco di risorse su Peercast, dalla FAQ (che vorrei tradurre) alla wiki dedicata a Peercast.
Insomma, cominciamo a conoscere anche questo mondo.. e vediamo che cosa ci può offrire di bello.
Servizi di Hosting – MediaStreaming.it
gennaio 28, 2007 1:06 pm
Sedicesimo articolo dedicato alle web radio.
Riprendiamo a parlare di servizi di hosting.
Dopo avere introdotto la tematica parlando di Live365.com in questo articolo, continuiamo parlando di un sito che offre un servizio affine, ovvero MediaStreaming.it.
Piccolo Disclaimer: Nessuno dei siti che recensiono mi ha pagato, ne sono condizionato da accordi o contratti con nessuno, un giudizio positivo o negativo su qualsiasi programma e/o sito web e/o servizio dipende esclusivamente dai miei parametri di valutazione. Il mio obiettivo è quello di spiegare l’utilizzo e valutare le offerte per permettere a chi visita questo sito di avere chiaro il panorama radiofonico del web.
Posti i paletti, continuiamo.
La home del sito è molto chiara, ci mostra subito che cosa offre il sito e le sue suddivisioni.
Per prima cosa notiamo che ci sono due possibilità di supporto allo streaming:
- Shoutcast DNAS Server
- Windows Media Server
Partiamo dalla prima, esaminando successivamente anche la seconda, per poi passare al resto.
Il link della pagina dedicata a Shoutcast è questo. Una volta entrati nella pagina si vedrà una spiegazione della conformazione dei loro server, e di come avverrà lo streaming. Sotto, ci sono le tabelle di pagamento, inutile ricopiarle, sono molto chiare e facilmente consultabili. C’è anche l’opzione per la trasmissione di video, ma a noi questo non interessa.
Sotto ancora, ci sono le modalità di pagamento:
- Tramite Paypal
- Tramite Bonifico Bancario
Inoltre, Mediastreaming permette una cosa molto comoda, offerta del resto anche da live365.com
MediaStreaming ti dà la possibilita’ di testare i propri server prima dell’acquisto. Contattaci e richiedi, senza alcun impegno, un’account di test in cui potrai verificare di persona la qualità del nostro servizio.
Che è una cosa ottima.
Già, ma come si fa ad utilizzare concretamente il server che mette a disposizione mediastreaming?
All’atto del pagamento, viene inviato via mail:
- Indirizzo del server, andrà inserito nel campo ADDRESS del plug-in
- Porta da utilizzare, andrà inserto nel campo PORT
- Password, che andrà settata nel plug-in nel campo PASSWORD.
Per il resto, configurate tutto come se la trasmissione avvenisse dal vostro PC, come spiegato nella guida basilare. Adesso avrete un MAXI RELAY che si prenderà carico di ritrasmettere la vostra radio. (per ulteriori info sui relay applicati alla web radiofonia, andate qui.
Il metodo di interazione con il server di mediastreaming assegnatovi, potete anche andare qui.
Semplice no? 
Esiste anche la possibilità di streammare in WMA (non ne vedo il motivo, ma comunque la libertà prima di tutto) e per poterlo fare, mediastreaming offre la possibilità di utilizzare il windows media server.
In questa pagina trovate un elenco di guide alla corretta configurazione dei programmi più comuni con i due encoder.
Il sito offre un ottima assistenza tecnica coadiuvata dalle molteplici modalità di utilizzo della stessa: dai vari indirizzi mail, a numeri di telefono e ad indirizzi per il contatto diretto da MSN! Grandioso…
Da provare…
Come creare ponti di ripetizione del vostro Streaming. Radio & P2P
gennaio 27, 2007 1:31 pm
Quindicesimo articolo dedicato alle web radio.
Che ultimamente per farsi pubblicitá regalano numerosi biglietti per concerti in tutta Italia…marketing spicciolo, ma funziona! Vi ricordate quando dicevo che le web radio sono come delle torte? Bene, approfondiamo questo argomento.
Per potere comprendere questa guida è necessario avere una minima concezione di teoria dei grafi.
In realtà la vostra radio, o meglio, il vostro pc e la vostra banda, non sono una grande torta, ma più precisamente sono la radice di un grafo aciclico connesso, ovvero di un albero N-ario di altezza 1.
Ovvero si ha una situazione simile a questa immagine:
(la grafica non è delle migliori, ma di meglio non so fare)
Il nodo BLU è il Computer che trasmette, detto server, mentre i nodi ROSSI sono i computer o gli apparecchi che ricevono il flusso, chiamati client.
Il server è la radice dell’albero, mentre i client sono le foglie.
L’altezza dell’albero è 1, come precedentemente detto.
Il numero massimo di figli della radice, ovvero di client che possono ascoltare la radio è dato (teoricamente) da:
Ad esempio se ho una banda in upload di 1MBPS, e imposto un bitrate di 64 kbps, mi potranno teoricamente sentire al massimo 16 client.
Questo è il modo con cui abbiamo conosciuto la radio, e a parte le guide tecniche, ci siamo sempre occupati di poter aumentare la banda, in modo che sia possibile aumentare il numero di client. Giusto no?
Be, sappiate che non è l’unica politica possibile. Non è per forza detto che la mia radio si debba sentire da un unica fonte, è possibile creare i cosidetti Ripetitori (in inglese relay).
Da questo momento in poi, considereremo altre politiche, che sfruttano i ripetitori, e le suddivideremo in mono e pluri relayed radio.
Cominciamo considerando il grafo della MRR e commentandolo.
(la grafica non è delle migliori, ma di meglio non so fare)
Intanto identifichiamo i vari nodi:
- Il nodo blu è il server, il computer principale
- I nodi verdi sono dei client, ma sono anche dei Relay, ovvero sono dei ripetitori di segnale, ai quali si appoggiano altri client.
- I nodi rossi sono client, che non fungono da ripetitori.
C’è da dire che ogni client Rosso, è promuovibile a Relay, e che una foglia è generalmente ROSSA, ma può anche essere VERDE. (ovvero è un relay a cui non si è appoggiato nessuno).
Questi alberi hanno altezza pari al massimo numero di relay che devi attraversare prima di arrivare alla fonte del segnale, più uno.
C’è da dire che questa configurazione, se da un lato abbassa la domanda di banda imposta al server, distibuendola anche ai relay, d’altra parte aumenta logaritmicamente il ritardo di propagazione.
Vediamo come:
Se il computer A trasmette al computer B che ripete a sua volta al computer C che ripete a sua volta al computer D, ovvero:
Quanto vale il ritardo di propagazione? Ovviamente 4 volte il ritardo di propagazione di una trasmissione diretta, quindi potreste sentire musica con molto ritardo!!!
D’altronde, il buon senso ci ricorda che la situazione lineare di cui sopra, non ha nessuna utilità pratica.
Se Invece ipotizziamo che ogni la radice e tutti i sottorelay abbiano AL MASSIMO due ascoltatori, che possono a loro volta fare da relay, allora si crea un simpatico albero binario, e il ritardo di propagazione stavolta è dato da:
Con x che rappresenta il numero di ascoltatori contemporaneamente connessi e Il 2 che fa da base al logaritmo dipende dal numero di ascoltatori che può servire ciascun rela. Se questo numero aumenta, aumenterà la base del logaritmo e di conseguenza diminuirà il numero di relay che deve attraversare un client per sentire il flusso audio.
In generale possiamo quindi dire che: Se si riesce a distribuire bene il numero di computer che fungono da relay con il numero di pc che richiedono il flusso, allora il ritardo di propagazione cresce in funzione del logaritmo del numero dei CLIENT contemporaneamente connessi alla radio.
Cosi si che possiamo davvero ragionare in grande!
Cominciamo sempre commentando il grafo della PRR:
(la grafica non è delle migliori, ma di meglio non so fare)
Questo è un esempio di Radio Pluri Relayed, ovvero radio in cui i client sono serviti da più relay, in vero stile P2P.
Può sembrare un grafo ciclico connesso, ma in realtà non è affatto ciclico, in quanto è orientato come tutti gli altri. I client non rimandano nulla ai Relay, quindi non è possibile che un relay invii qualcosa ad un altro relay tramite un client! (e questo mi sembra ovvio…)
Questa situazione è la migliore in tutti i campi, ed è di fatto lo schema del P2P, ovvero quando scaricate qualcosa da Emule o da qualsiasi programma di File sharing, e condividite, sotto sotto voi siete dei relay, ovvero acquisite qualcosa e ricambiate dando qualcos’altro, e siete in grado di ricevere qualcosa da più relay in contemporanea (da qui la denominazione PLURI relayed radio).
Se invece vi limitate a scaricare senza condividere, siete solo dei client (oltre che lurkatori infami )
Questo schema multi-connesso è la soluzione a tutti i problemi, in quanto si partiziona il carico di banda nel maggior numero di computer possibili.
Che bello! Già, fantastico, peccato che sia impossibile da implementare in pratica.
Per quale motivo?
Semplice, supponiamo di essere un semplice client, che vuole sentire Radio Mammamiachesballo.
Radio Mammamiachesballo mi permette l’ascolto passando da 4 relay, perchè sono tutti occupati ai livelli superiori.
Quindi ho un ritardo pari a 4.
Ad un certo punto, si libera uno “spazio” su un relay al livello 2, me ne posso appropiare.
Si, ma a questo punto cosa succede? Succede che mi arrivano parti dello stesso flusso, sfasati di una certa quantità che è data dalla differenza dei ritardi, questo manda tutto a put***…
Anche qualora fosse possibile davvero segmentare il flusso (e non so se si possa fare davvero), non si potrebbe non essere vincolati dai diversi ritardi. (Queste sono considerazioni semi-personali, se qualcuno può provare che la cosa non è come dico, non solo lo pubblicherò, lo ringrazierò e se è di Palermo gli offrirò qualcosa, ma addirittura sarò pronto ad ammettere di avere detto cazzate pubblicamente)
Purtroppo, non è nemmeno possibile usufruire di più relay sullo stesso livello, perchè i ritardi di propagazione non dipendono solo dal livello, ma a quanto ho potuto provare, anche da molti altri fattori.
Considerazione finale sul modello plury relayed radio: Se si riesce a rendere prossimi a 0 i ritardi di propagazione dei flussi in streaming, allora questo modello può avere un senso, per ora accontentiamoci della possibilità concreta di avere una mono relayed radio.
P.S Questa è pura teoria… Sapete perchè? be, mi autocito da un altro post, quando ho commentato l’articolo 7 comma 1 lettera E del maledetto modulo awr:
Nel primo comma, di importante c’è soltanto la lettera E (le altre sono quisquilie…) che con un giro di parole VIETA IL REDIRECT ovvero dice che non è possibile utilizzare nel proprio canale flussi di qualsivoglia tipo appartenenti ad un altra radio. Scordatevi quindi di creare ponti di web radio e di ritrasmettere le principali radio in streaming del web. In teoria non sarebbe fattibile utilizzare PeerCast, o fare dei relay. Io sono pronto a muovere guerra.
