Programando em NCL 3.0.pdf - Telemidia - PUC-Rio

Programando em NCL 3.0.pdf - Telemidia - PUC-Rio Programando em NCL 3.0.pdf - Telemidia - PUC-Rio

telemidia.puc.rio.br
from telemidia.puc.rio.br More from this publisher
11.07.2015 Views

pode ser sintonizado em qualquer instante de tempo de um programa de TV.O escalonador deve também permitir que uma aplicação sofra operações depausa e retomada, que exigem que ela prossiga, mesmo em um instantetemporal posterior ao da pausa. Esse tipo de operação é comum quando ousuário troca e, em seguida, retorna ao mesmo canal (ou serviço) de TV.Para enfrentar o segundo problema, o gerenciamento das transmissões,devemos definir procedimentos, tanto nos provedores de conteúdo quanto nosclientes receptores. Esses procedimentos dependem de os dados seremrecebidos sem solicitação (pushed data) ou sob demanda (pulled data).No caso de dados recebidos sem solicitação, eles são geralmenteenviados ciclicamente (em carrossel), como discutido em detalhes noApêndice F. A colocação e a retirada dos dados no carrossel e em qualposição do carrossel são fundamentais para diminuir a banda necessária paratransmissão dos dados e para garantir que eles estarão presentes no receptorquando necessário. O “escalonador de carrossel” é o responsável por essastarefas nos provedores de conteúdo.Do lado do cliente receptor, um “escalonador de pré-busca” é necessáriopara retirar, nos momentos precisos, dados dos carrosséis e carregá-los namemória do receptor. Esse escalonador é também responsável por requisitardados sob demanda, de forma a garantir sua presença no dispositivo receptorquando necessário. Devemos notar, mais uma vez, que devido à usuallimitação de memória dos dispositivos receptores é importante manter omínimo de conteúdos de mídia na memória principal. Para busca dessesdados, pode ser necessária a negociação de QoS (Quality of Service) na rede.Nesse caso, um “escalonador de negociação de QoS” é responsável pelatarefa, garantindo a reserva de recursos na rede quando o escalonador de prébuscarequisitar os dados.Para dar suporte à realização das tarefas executadas pelos diversosescalonadores mencionados, várias estruturas de dados são computadas apartir da especificação da aplicação NCL. Na implementação de referência domiddleware Ginga, elas são baseadas e derivadas de uma estrutura de dadosúnica, denominada Hypermedia Temporal Graph ou HTG.G.2 Hypermedia Temporal Graph (HTG)Para controlar o comportamento temporal das aplicações durante a suaexecução, o Ginga-NCL adota uma estrutura formada por grafosdirecionados (dígrafos). Essa estrutura, conhecida como HypermediaTemporal Graph ou HTG[Costa et al., 2008; Moreno et al., 2008], oferecesuporte ao início ou à retomada síncrona da apresentação a partir de uminstante de tempo qualquer.520

No HTG, cada vértice representa uma transição de estado de um evento.Os eventos representados nessa estrutura são os mesmos definidos na NCL,ou seja, os eventos de apresentação, seleção e atribuição, cada um controladopor uma máquina de estados, repetida por comodidade de leitura na FiguraG.1.stop | abortpausedpausesleepingstartstop | natural endabortresumeoccurringFigura G.1 Máquina de estado de um evento.O grafo temporal obtido através da modelagem de uma aplicação devepreservar todos os relacionamentos entre os eventos, sejam eles previsíveis ouimprevisíveis, bem como o estado atual de cada máquina de estados associadaa um evento.No HTG, as arestas entre os vértices representam os “relacionamentosentre as transições de estados dos eventos”. Cada aresta possui uma condiçãoassociada que deve ser satisfeita para que a transição, representada pelo seuvértice de destino, seja disparada. Em resumo, os grafos nessa estrutura sãodefinidos por um conjunto de vértices, arestas e condições de caminhamento(V, A, C), onde: V = (v0, v1, v2, v3, ..., vn – 1) é um conjunto finito de vértices, em quecada vértice representa uma transição na máquina de estados associada aum evento. Cada vértice é representado por uma tripla: o nome da açãoque dispara a transição, o tipo de evento correspondente e o identificadorda âncora que identifica o objeto ou parte de seu conteúdo (se o evento édo tipo apresentação ou seleção) ou o identificador único da propriedade eseu valor (se for um evento de atribuição); A = (a0, a1, a2, a3, ..., am – 1) é um conjunto finito de arestas querepresentam, individualmente, um relacionamento entre transições. Paracada aresta “a”, v e w são os vértices de origem e destino, respectivamente((v, w) V x V); C = {cij} é um conjunto finito de condições associadas às arestas. Umacondição “cij” é associada com a aresta (vi, vj) A e deve ser satisfeitapara que o disparo do vértice (disparo da transição) destino da arestaconsiderada seja realizado.521

pode ser sintonizado <strong>em</strong> qualquer instante de t<strong>em</strong>po de um programa de TV.O escalonador deve também permitir que uma aplicação sofra operações depausa e retomada, que exig<strong>em</strong> que ela prossiga, mesmo <strong>em</strong> um instantet<strong>em</strong>poral posterior ao da pausa. Esse tipo de operação é comum quando ousuário troca e, <strong>em</strong> seguida, retorna ao mesmo canal (ou serviço) de TV.Para enfrentar o segundo probl<strong>em</strong>a, o gerenciamento das transmissões,dev<strong>em</strong>os definir procedimentos, tanto nos provedores de conteúdo quanto nosclientes receptores. Esses procedimentos depend<strong>em</strong> de os dados ser<strong>em</strong>recebidos s<strong>em</strong> solicitação (pushed data) ou sob d<strong>em</strong>anda (pulled data).No caso de dados recebidos s<strong>em</strong> solicitação, eles são geralmenteenviados ciclicamente (<strong>em</strong> carrossel), como discutido <strong>em</strong> detalhes noApêndice F. A colocação e a retirada dos dados no carrossel e <strong>em</strong> qualposição do carrossel são fundamentais para diminuir a banda necessária paratransmissão dos dados e para garantir que eles estarão presentes no receptorquando necessário. O “escalonador de carrossel” é o responsável por essastarefas nos provedores de conteúdo.Do lado do cliente receptor, um “escalonador de pré-busca” é necessáriopara retirar, nos momentos precisos, dados dos carrosséis e carregá-los nam<strong>em</strong>ória do receptor. Esse escalonador é também responsável por requisitardados sob d<strong>em</strong>anda, de forma a garantir sua presença no dispositivo receptorquando necessário. Dev<strong>em</strong>os notar, mais uma vez, que devido à usuallimitação de m<strong>em</strong>ória dos dispositivos receptores é importante manter omínimo de conteúdos de mídia na m<strong>em</strong>ória principal. Para busca dessesdados, pode ser necessária a negociação de QoS (Quality of Service) na rede.Nesse caso, um “escalonador de negociação de QoS” é responsável pelatarefa, garantindo a reserva de recursos na rede quando o escalonador de prébuscarequisitar os dados.Para dar suporte à realização das tarefas executadas pelos diversosescalonadores mencionados, várias estruturas de dados são computadas apartir da especificação da aplicação <strong>NCL</strong>. Na impl<strong>em</strong>entação de referência domiddleware Ginga, elas são baseadas e derivadas de uma estrutura de dadosúnica, denominada Hypermedia T<strong>em</strong>poral Graph ou HTG.G.2 Hypermedia T<strong>em</strong>poral Graph (HTG)Para controlar o comportamento t<strong>em</strong>poral das aplicações durante a suaexecução, o Ginga-<strong>NCL</strong> adota uma estrutura formada por grafosdirecionados (dígrafos). Essa estrutura, conhecida como HypermediaT<strong>em</strong>poral Graph ou HTG[Costa et al., 2008; Moreno et al., 2008], oferecesuporte ao início ou à retomada síncrona da apresentação a partir de uminstante de t<strong>em</strong>po qualquer.520

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!