FabrizioMondo.com

Quindicesimo articolo dedicato alle web radio.
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.