Di questi tempi, almeno secondo fiere di settore e spot pubblicitari, ogni angolo delle nostre case dovrebbe un Media Center. Qualsiasi film, foto, brano musicale o gioco digitale accessibile da un qualunque dispositivo elettronico in casa dovrebbe essere ugualmente disponibile, o controllabile, da qualsiasi altro prodotto dello stesso genere, nella stessa casa.
A prima vista tutto ciò potrebbe sembrare solo l’ennesimo modello di condivisione di file P2P, ovvero da pari a pari senza un server centrale. In realtà, le differenze fra quanto potrebbe avvenire oggi in qualsiasi “salotto 2.0” e la condivisione di file fra computer, tecnicamente possibile a costi molto contenuti da almeno vent’anni non sono proprio trascurabili.
Se l’Internet delle Cose è ancora di là da venire, oggi il mercato, e soprattutto le abitudini delle persone, sono già cambiati a tal punto che non è affatto improbabile trovarsi in casa più dispositivi assai diversi ma capaci di collaborare direttamente, senza che nemmeno uno di loro sia un computer tradizionale. Scenari del genere sono l’obiettivo e la ragione di vita della Digital Living Network Alliance
(Dlna, www.dlna.org): un consorzio di fornitori e distributori di contenuti e periferiche per home entertainment, creato da Sony e Intel una dozzina d’anni fa.
L’Alleanza promuove sviluppo e uso di reti domestiche di computer, console per giochi, terminali mobili e altri dispositivi consumer capaci di scambiarsi audio, video e fotografie con la massima facilità possibile. Questo da un lato crea nuove possibilità di intrattenimento (ma anche di studio
o lavoro da casa), dall’altro nuovi rischi. La conoscenza di certi standard aperti e l’uso di software Open Source
possono aumentare le prime e ridurre i secondi, ed è proprio di questo che parleremo questo mese. Protocolli e problemi generali sono descritti nei paragrafi che seguono, mentre l’altro articolo della rubrica presenta alcuni programmi Open Source capaci di lavorare come abbiamo accennato.
UPNP, 0 iL SALOTTO CHE DIVENTA COME iL WEB
Fin dai suoi inizi, Dlna ha pubblicato linee guida e gruppi di standard su come garantire l’effettiva interope-rabilità di computer, Smart TV, console e simili. Quello più rilevante, o almeno il più rilevante in questa occasione, si chiama Universal Plug and Play (UPnP, http://upnp.org). Nel mondo UPnP la prima distinzione fra dispositivi hardware, l’unica che conta davvero in quel contesto, è in base alla loro funzione. Gli oggetti (o i portali su Internet) che conservano fisicamente i vari contenuti multimediali, per trasmetterli a richiesta a chiunque lo chieda, sono media server. I media rende-rer sono altoparlanti, proiettori, Smart Tv, console e loro periferiche: in altre parole, qualsiasi prodotto che effettivamente riproduce per i suoi utenti i vari contenuti, o parte di essi, ricevuti dai media server. I controllori o control point UPnP, infine, sono i telecomandi di tutto l’ambiente. L’esempio più comune di questa categoria potrebbero essere gli smartphone e tablet con cui i vari membri della famiglia visualizzano su un loro televisore foto o video conservati nel computer che sta in un’altra stanza. Nulla impedisce a uno stesso prodotto hardware di svolgere contemporaneamente più di una di queste funzioni, anzi. Qualsiasi Smart Tv, ad esempio, le offre sempre tutte e tre: dal punto di vista UPnP il suo schermo è un media renderer, il sintonizzatore o decoder interno un media server e il telecomando un control point. Come fa UPnP a far accadere tutto questo? Una risposta potrebbe essere che un oggetto UPnP può comportarsi come un normale sito Web, con in più la capacità di spiegare tutte le operazioni di cui è capace e come richiederle, a qualunque altro oggetto dello stesso tipo che sia disposto ad ascoltare. Senza richiedere alcuna competenza o procedura di configurazione specifica all’utente finale. Non c’è nemmeno bisogno che almeno uno dei dispositivi coinvolti sia un personal computer vero e proprio. È grazie
I plugin del progetto Grilo possono aggiungere supporto UPnP a player Open Source di qualsiasi tipo, sia per video locali sia, come nell’esempio, per YouTube e altri archivi online.
a queste caratteristiche che UPnP semplifica moltissimo la creazione di reti domestiche, o aziendali, il cui scopo primario è la condivisione locale di contenuti multimediali.
Il bello di UPnP è che tutto questo avviene combinando vari standard aperti, in larga parte già esistenti, e tutti basati su Internet. Librerie e altre parti software del sistema possono essere scritte in qualsiasi linguaggio di programmazione, per qualsiasi sistema operativo e senza alcun componente obbligatorio. Qualsiasi combinazione di normali pagine Web, script da riga di comando o interfacce a finestre native può funzionare come interfaccia, se utilizza i protocolli giusti.
La stessa flessibilità c’è a livello fisico: condivisione e controllo via UPnP possono avvenire su qualsiasi rete cablata o wireless, quindi non servono driver hardware. Le comunicazioni avvengono comunque scambiando gli stessi pacchetti Ip (Internet Protocol) di cui è già costituito il traffico di Internet.
Oltre a questo ogni dispositivo compatibile UPnP, qualunque origine o funzione abbia, può entrare e uscire da una rete locale automaticamente, senza causare alcun problema a sé stesso o agli altri, e senza mai lasciare in sospeso le comunicazioni di controllo. Tutto questo avviene grazie a procedure ben definite di autoconfigurazione, scoperta e annuncio.
Per cominciare, ogni periferica UPnP deve contenere software che si comporti come fanno i normali computer, tablet e smartphone appena si connettono a una rete locale: richiedere ai router, tramite il protocollo Dhcp, un indirizzo numerico Ip, e se disponibile anche un nome di dominio (per esempio “proiettore.sala-riunioni.ufficio”), per usarli come identificatori su quella stessa rete. La differenza fra gli oggetti UPnP e i computer tradizionali è che i primi, se non ricevono istruzioni del genere, si assegneranno sempre un indirizzo Ip da soli, ovviamente diverso da quelli che rilevano analizzando il traffico in rete, e inizieranno ad annunciare la propria presenza e capacità.
Grazie a queste procedure di “autopromozione” server e renderer UPnP comunicano la propria disponibilità a tutti i control point che potrebbero essere sulla stessa rete. Simmetricamente i controllori si mettono a disposizione, in ascolto, per scoprire quali client potrebbero controllare, e per far cosa. In entrambi i casi si usano messaggi semplicissimi, che contengono solo alcune caratteristiche essenziali del dispositivo trasmittente, come un codice di identificazione e un puntatore a informazioni più dettagliate, in un formato chiamato Ssdp (Simple Service Discovery Protocol).
Oltre a trovarsi l’un l’altro, senza aiuti da terze parti, i componenti UPnP devono conoscere esattamente tutte le proprie capacità. I control point, in particolare, devono saper imparare da soli tutte le caratteristiche dei server o renderer che vogliono controllare, altrimenti come potrebbero farlo senza coinvolgere pesantemente l’utente? Questo apprendimento avviene con lo stesso meccanismo con cui un utente di Internet, umano o motore di ricerca, scoprirebbe di cosa parla un sito Web: un control point deve infatti visitare la “home page” dell’oggetto da controllare.
Il puntatore menzionato nei paragrafi precedenti, che deve essere presente in ogni messaggio di annuncio UPnP, non è altro infatti che un normale Url, leggibile anche con qualsiasi browser connesso alla stessa rete locale. Caricando quell’ Url si otterrà, direttamente dal dispositivo che interessa, un file di testo nell’immancabile formato Xml. Il suo contenuto è un manuale di istruzioni completo del dispositivo stesso, ma formattato in modo che qualsiasi software con le librerie giuste possa capirlo. Al suo interno si trovano innanzitutto dati banali, ma utilissimi, come nome e numero di serie della periferica corrispondente, e link al servizio cliente o a manuali online. La parte più importante di quel documento è però la sua lista di comandi e
servizi. Tutte le azioni di cui il dispositivo è capace sono elencate, divise appunto per servizio. A ogni azione è allegato un elenco completo di tutte le opzioni possibili. Se necessario, la “home page” contiene anche una descrizione di tutte le variabili di stato che sarebbe possibile leggere o impostare nel dispositivo. Da quel momento in poi, ogni richiesta di esecuzione comandi da un control point a un server o renderer riceverà in risposta il risultato di quei comandi e il nuovo stato del dispositivo, se necessario. Riassumendo, ogni prodotto degno dell’etichetta UPnP è in grado di insegnare a qualsiasi altro oggetto che parli quel linguaggio, chiunque ne sia il fabbricante, come controllarlo direttamente.
Per fare in modo che una rete UPnP funzioni davvero manca però ancora una tessera del puzzle, ovvero la notifica degli eventi (“eventing” nella documentazione UpnP). I control point su una stessa rete possono essere anche parecchi (per esempio, tutti gli smartphone di una famiglia o gruppo di amici in grado di “vedere” la stessa TV in salotto). In condizioni del genere, se tutti i controllori verificassero continuamente lo stato di ogni dispositivo genererebbero parecchio traffico inutile che potrebbe addirittura causare problemi nella trasmissione audio o video.
Per evitare queste eventualità il protocollo UPnP prevede che ogni server 0 renderer invii una notifica, a tutti e soli i controllori che ne hanno fatto richiesta, ogni volta che ha terminato l’esecuzione di un comando, o che una delle sue variabili di stato cambia per qualunque motivo. In questo modo i singoli control point dovranno soltanto preoccuparsi di “abbonarsi” ai dispositivi che gli interessano, o meglio a quelli che i loro utenti vorranno gestire in ogni momento.
1 tipi di oggetti gestibili, i servizi possibili con ognuno di loro e il modo di gestirli sono specificati in appositi protocolli di controllo chiamati Dcp (“Device Control Protocol”). A titolo di esempio, in ambito audio/video esistono le due categorie di oggetti già citati (media renderer e media server), che sono capaci di offrire in totale quattro servizi: gestione delle connessioni, controllo del rendering, elenco dei contenuti disponibili e quello chiamato “AVTransport”. Quest’ultimo e opzionale servizio permette di controllare in maniera molto più fine quali contenuti vengono inviati a chi, e come: un esempio potrebbe essere l’ordine di inviare a uno e uno solo degli schermi disponibili una specifica scena di un video registrato in precedenza e salvato su un disco di rete.
Altri componenti e servizi che aumentano la flessibilità di UPnP sono, citandone solo due fra tanti per ragioni di spazio, quelli chiamati Web4CE e QoS. Il primo è un metodo, basato sulla variante del linguaggio Html chiamata Ce-Html (http://en.wikipedia. org/wiki/CE-HTML), per controllare periferiche UPnP direttamente da un browser, anziché da software o telecomandi hardware dedicati.
La Qualità di Servizio (QoS) è invece un concetto molto più generale, fondamentale in molti campi delle telecomunicazioni. Sulle reti digitali, incluse quelle UPnP, viaggiano flussi di traffico con caratteristiche ed esigenze diverse fra loro. Un comando di cambiare canale, per esempio, potrebbe anche arrivare con ritardi “enormi” come mezzo secondo, senza causare alcun problema agli utenti, purché arrivi perfettamente integro. Nella visione di un film, invece, la perdita di un fotogramma causerebbe molto meno fastidio di un ritardo fra fotogramma e fotogramma continuamente variabile di più di pochi millisecondi. I comandi QoS servono proprio a prevenire questi problemi, specificando quali flussi dati devono avere priorità sugli altri, e qual è il massimo ritardo con cui devono attraversare la rete.
UPNP SU MiSURA? Sì, CON SOFTWARE e hardware open source
I Media Center Open Source descritti in queste pagine consentono già da anni di usufruire con poca fatica dei servizi UPnP da Linux. Come sempre però, il bello e il valore maggiore del software Open Source rimane il fatto che, avendo le competenze giuste, ci si può costruire una soluzione perfettamente su misura. Questi tipi di progetti, oltre ad avere un interesse innegabile per gli hobbysti “digitali”, possono avere anche un valore notevole come strumenti didattici, per avvicinare alla programmazione anche studenti altrimenti difficili da raggiungere.
II primo strumento per attività del genere su Linux è probabilmente Mi-niUPnP (http://miniUPnP.free.fr), che è composto da due parti principali: la prima è una libreria per control point, che una volta compilata occupa meno di 50 KByte di spazio in memoria.
Il codice sorgente è Ansi C, quindi portabile. L’altro componente base di MiniUPnP è il server, chiamato miniUPnPd. Come la sua controparte ha un ingombro di memoria ridotto, ed è quindi utile anche per applicazioni embedded. È utilizzando codice come questo che alcuni hacker riescono, già da anni, a costruirsi Media Center miniaturizzati come quelli basati su Raspberry Pi, il popolare microcomputer (vedi
il box Risorse). A un livello diverso da MiniUPnP e meno impegnativo, c’è la libreria chiamata Grilo (https://wiki.gnome.org/Projects/Grilo): grazie ad essa si possono scrivere facilmente plugin per collegare a server UPnP anche player per desktop Linux come Totem o RythmBox. Dopo aver installato e configurato Grilo, qualsiasi applicazione con i relativi plugin, che giri sullo stesso computer, potrà accedere a i server UPnP della rete locale, qualsiasi sia la loro natura. Particolarmente interessante è il fatto che
i plugin di Grilo possono connettersi anche a “servizi” che non sono affatto lettori Dvd e altre periferiche, ma tradizionali portali Web come YouTube, Jamendo, Last.FM o Flickr.
