Projeto de Infra-Estrutura de Comunicação

Transcrição

1 Universidade Federal de Pernambuco Centro de Informática Projeto de Infra-Estrutura de Comunicação Professor: Paulo André da S. Gonçalves Alunos: André Ricardo (arrr) Daker Fernandes (dfp) Felipe Batista (fbs)

2 Sumário Rafael Lima (ragpl) Thaís Melise (tmlp) Introdução 03 Implementação do CIneVision 04 Especificação do protocolo 05 Formato de streaming 07 Formato de mensagens 08 Versão v.1 09 Mensagens de navegação 10 Mensagens de streaming 12 Comportamento da aplicação cliente 14 Comportamento da aplicação servidor 15 Conclusão 16 Anexos 17 Referências Bibliográficas 19 2

3 Introdução Esse trabalho consiste no desenvolvimento de um protocolo em nível de aplicação para transmissão de streaming de vídeo com confiabilidade na entrega dos dados e com um atraso considerado razoável e de um sistema. O CIneVision, que é um software que permite que seus usuários assistam vídeos em formato digital utilizando-se um protocolo desenvolvido pela equipe para enviar o conteúdo dos vídeos do servidor às máquinas usuárias. [Streaming] (fluxo, ou fluxo de mídia em português) é uma forma de distribuir informação multimídia numa rede através de pacotes. Ela é freqüentemente utilizada para distribuir conteúdo multimídia através da Internet. [1] O streaming de vídeo tornou-se uma tecnologia muito popular com a disseminação do uso de sites como o YouTube, atualmente o mais popular do gênero [2]. O protocolo desenvolvido, não se encarrega do envio do pacote em si, e por especificações advindas dos requisitos do trabalho, ele deve usar um protocolo de transporte com garantia de entrega e ordenação dos dados entregues do servidor de vídeo ao host cliente, assim, o protocolo utiliza o TCP [RFC 793] como protocolo de transporte. O CIneVision é um software de transmissão de streaming de vídeo, onde os usuários podem assistir vídeos no servidor de vídeos do CIneVision. 3

4 Formato de Streaming Vídeo de fluxo contínuo armazenado Nessa classe de aplicações, clientes requisitam, sob demanda, arquivos de vídeo que estão em servidores. Arquivos de vídeo podem conter variadas informações, como palestras, filmes, programas de televisão gravados, documentários, desenhos animados e videoclipes. São características fundamentais dessa classe de aplicação: Mídia armazenada. Como o conteúdo multimídia foi pré-gravado e está armazenado num servidor, o usuário pode fazer pausa, voltar, avançar e alternar entre itens de vídeo. Fluxo contínuo. Normalmente o cliente inicia a reprodução do vídeo segundos após receber o arquivo do servidor. Conseqüentemente, o cliente estará reproduzindo vídeo de uma parte do arquivo enquanto está recebendo do servidor partes mais à frente do arquivo. Essa técnica, conhecida como fluxo contínuo (streaming), evita a necessidade de descarregar o arquivo inteiro para reproduzi-lo. Reprodução contínua. Assim que a reprodução do conteúdo de multimídia é iniciada, ele deve prosseguir de acordo com a temporização original do vídeo, ou seja, os dados devem ser recebidos do servidor a tempo de ser reproduzidos no cliente. Compressão de vídeo A compressão de vídeo se baseia na redundância encontrada em vídeo. No caso do formato MPEG-4, temos uma redundância temporal, isso é, reflete a repetição de imagens subseqüentes, um exemplo seria a ocorrência de duas imagens subseqüentes iguais onde simplesmente há a indicação desse fato, não havendo a necessidade de codificação da imagem repetida. 4

5 Implementação do CIneVision Requisitos Funcionais Listar vídeos O usuário deve poder listar todos os vídeos disponíveis para assistir. Prioridade: Essencial Status: Implementado Reproduzir vídeos Deve ser possível para o usuário de requisitar, a partir da lista de vídeos, um que ele quer assistir. Nesse momento o sistema iniciará o envio do vídeo que começará a ser exibido no player em uma janela específica. Prioridade: Essencial Status: Implementado Controlar reprodução do vídeo Deve ser possível que o usuário pause, avance ou recue o vídeo no momento de sua reprodução, dentro da parte que já foi carregada, assim como saber em que ponto a reprodução está atualmente e o total do vídeo que já foi carregado do servidor. Prioridade: Essencial Status: Parcialmente implementado OBS: O player não reproduz trechos se há outros anteriores a ele que ainda não foram carregados. Realizar busca de vídeos Deve ser possível fazer a busca dos vídeos no servidor através de palavras chave. Prioridade: Desejável Status: Não agendado Fazer upload e informações do vídeo Deve ser possível que haja informações relacionadas aos vídeos cadastrados: duração e título. Prioridade: Desejável Status: Implementado Exibir resumo do vídeo Deve ser possível que o usuário visualize um pequeno resumo de alguns screenshots do vídeo selecionado, sem a necessidade de requisitá-lo para reprodução. Prioridade: Desejável Status: Não agendado Registro de usuário 5

6 Deve ser possível que o usuário se cadastre, tendo um login próprio e tendo relacionados a ele seus vídeos cadastrados. Prioridade: Desejável Status: Não agendado Requisitos Não-Funcionais Transporte confiável de dados O envio de vídeos deve ser realizado por um protocolo confiável de transferência de dados (usando socket TCP). Prioridade: Essencial Status: Implementado Vídeos em formato MPEG-4 O sistema deve dar suporte à reprodução de vídeos em formato MPEG-4. Prioridade: Essencial Status: Implementado Tempo de atraso razoável O sistema deve limitar o atraso na transmissão do streaming para um tempo razoável para o usuário. Prioridade: Essencial Status: Implementado 6

7 Especificação do protocolo O protocolo na camada aplicação foi concebido seguindo a condição existente na especificação do projeto que é usar como serviço de transporte TCP. Isso facilita a implementação já que não há o problema de perca de pacotes e de pacotes fora de seqüência. Para não haver interrupções durante o envio de pacotes de dados e de controle, o nosso protocolo permitirá fazer envio de mensagens que poderão ser transmitidas durante qualquer momento aproveitando a característica full-duplex do TCP. O protocolo foi projetado trabalhar com duas conexões TCP abertas, para não haver interferência entre a navegação dos vídeos disponíveis e a transferência de vídeos. As portas utilizadas são por padrão a 5254 para o contexto de navegação e a 5255 para o streaming (semelhante ao FTP [RFC 959]). A divisão em portas é interessante para dar suporte para alguma implementação que use múltiplos processos de forma facilitada, já que esses dois contextos têm certo grau de independência um do outro e requisições de contextos diferentes podem acontecer simultaneamente. Como temos uma aplicação onde o tempo em que as informações são lidas e transmitidas são importantes para minimizar o atraso, optamos por projetar um formato de mensagem o mais curto possível. Todas as mensagens trocadas vão seguir o padrão de um cabeçalho curto para todas as trocas de mensagens, definindo a versão e o conteúdo da mensagem, onde esse é compatível com a adição de campos adicionais apenas quando for necessária a transmissão de mensagens que requerem informações adicionais. O protocolo ainda está apto a suportar mensagens e dados diferentes em outras versões. Por conta da disponibilidade de tempo, esboçamos uma versão (v.1) foi pensada para apenas conter o necessário para haver um streaming de vídeo o mais básico possível (respeitando as restrições da especificação do projeto). 7

8 Formato de Mensagens Esse formato de cabeçalho é idêntico para os dois contextos da aplicação, mesmo agindo em portas diferentes. Outra vantagem dele é a longa vida do protocolo já que deixa disponível uma parte que sinaliza a versão do protocolo de forma rápida e ainda deixa o protocolo extensível. Vale ressaltar que esse cabeçalho é inerente à versão do protocolo. A única restrição que há quanto ao tamanho das mensagens, é que esta não ultrapasse 30KB. Esse cabeçalho comum está definido a seguir ocupando o espaço de 16 bits: [0..7]* [8..15] BV BM BV Byte de Versão: diz qual é a versão em que a requisição feita pelo BM foi implementado. Com esse byte, é possível expandir o número de possíveis tipos de requisição além de um byte, já que podemos ter 256 tipos de requisições diferentes para cada versão do protocolo. BM Byte de Mensagem: é onde o cliente ou o servidor diz ao outro host o que deve ser feito. Dependendo da mensagem, cada uma pode ter um próprio formato de mensagem que segue o seu próprio contexto. Esses campos serão preenchidos de acordo com cada versão. Estaremos especificando a versão v.1 de (sem funcionalidades avançadas). Tais como buscas de vídeos ou imagens de quadros, descrição do conteúdo do vídeo ou ainda opções como upload de vídeos. *Essa notação será usada deste trecho em diante para informar quais são os bits que eles ocupam na mensagem. Ex.: [0..7] Significa que o campo ocupa 8 bits (ou 1 byte) da mensagem ou ainda de algum trecho em particular da mensagem. 8

9 Versão v.1 Como já explicado anteriormente, essa versão do protocolo é o mais simples possível a seguir a especificação do projeto. Além do básico, esta versão apresenta duas mensagens de erros mostradas abaixo que são extremamente úteis para mandar mensagens de erro causadas por incompatibilidades de versões. Separamos as mensagens da primeira versão em duas faixas de códigos diferentes, as mensagens do canal de navegação e o de streaming. Os bytes de mensagens para navegação (porta 5254) têm valores positivos enquanto as mensagens para streaming (porta 5255) têm valores negativos exceto o número -128 que é usado em uma mensagem para dizer que não suporta a mesma versão do outro host. Os valores 0 e -128 (80) no BM são mensagens que podem circular nos dois canais e tem a seguinte semântica: 0x00 Mensagem não entendida. Significa que a mensagem recebida não foi entendida dentro das versões suportadas pelo processo ou foi recebida fora do formato. Outro erro que pode ocorrer é a requisição estar navegando em um canal de contexto errado. Não são enviados bytes adicionais. Ex.: [0..7] [8..15] 1 (Versão v.1) 0x00 (Mensagem não Entendida) 0x80 Versão não suportada. É enviada quando a versão especificada no BV não é suportada pela aplicação. Não são enviados bytes adicionais. Ex.: [0..7] [8..15] 1 (Versão v.1) 0x80 (Versão não Suportada) 9

10 Mensagens de Navegação Nesta versão, o protocolo está de forma simplificada apenas para ser feito um protótipo de um programa que utiliza o protocolo. Por essas razões apenas requisições básicas devem ser feitas. A seguir temos os bytes de requisição desse canal de requisições disponíveis nessa versão e seu significado semântico respectivamente. 0x01 Requisitando informações de vídeos. O cliente envia essa mensagem ao servidor para que este comece a enviar todos os vídeos em sua lista. Não há nenhuma informação adicional nesse tipo de mensagem.* Ex.: [0..7] [8..15] 1 (Versão v.1) 0x01 (Requisitando informações de vídeos) 0x02 Enviando Informações de vídeos. Essa mensagem serve para o servidor de vídeos enviar o cliente as informações de vídeo. Após o cabeçalho comum temos respectivamente. [0..3] Indica a quantidade de informações de vídeos seguintes na própria mensagem. [4...] Estarão juntos as n informações de Vídeo indicadas no campo anterior As informações de vídeo seguem o seguinte formato**: [0..31] Contém a identificação do vídeo (única para cada vídeo) [32..63] Sua duração em segundos. [64..95] Seu tamanho em bytes. [ ] A quantidade de bytes que o título do vídeo ocupa (k). [128..k+127] O título do vídeo em caracteres com codificação UTF-8 (podem ocupar de 1 a 4 bytes). Onde k é a quantidade especificada no campo anterior de quantos bytes essa string ocupa. Ex.: Mensagem com informações sobre vídeos [0..7] [8..15] [16..47] [48..x]*** [x..y]*** 1 (Versão v.1) 0x02 (Enviando 2 (Contém 2 Informações Informação de vídeo 1. Informação de vídeo 1. 10

11 informações de vídeos) de vídeo na mensagem) Informação de vídeo [0..31] [32..63] [64..95] [ ] [ ] (ID do vídeo) 14 (Duração em Segundos) (Tamanho em bytes) 96 (Quantos bytes o Título ocupa) Hello Motto (Título do vídeo) *Em uma versão posterior esse tipo de requisição pode suportar campos para fazer uma filtragem de vídeos pelo servidor, para o caso de sistemas com mais de centenas de vídeos, cujo transporte de toda informação passe a ficar inviável. 11

12 **Essa informação poderia conter campos adicionais para maior nível de detalhamento para o usuário sobre os vídeos existentes no servidor. Um exemplo disso seria screenshots dos vídeos. ***X e Y têm tamanhos variáveis devido ao comprimento variável dos títulos dos vídeos em UTF-8 sem o caractere de parada. 12

13 Mensagens de Streaming As trocas de mensagens no canal de streaming são as que vão carregar a informação do que deve ser passado (sentido Cliente- Servidor) e o próprio conteúdo (sentido Servidor-Cliente). Seguindo o protocolo, o cliente pode requisitar qualquer trecho do vídeo a qualquer momento com ou mandar o servidor parar. 0xFF Mensagem de Requisição. Usada pelo cliente para requisitar um trecho de vídeo. Quando o cliente faz a requisição de um trecho, o servidor envia automaticamente os trechos seguintes ao último requisitado. O que existe de adicional neste tipo de mensagem é: [0..31] ID do vídeo. Para dizer qual o vídeo a ser transmitido. Caso esse seja diferente do que já estava sendo enviado, isso significa que o servidor deve começar a transmitir outro vídeo. [32..63] Trecho do vídeo. Indica qual a partir de qual trecho o vídeo deve ser transmitido. O servidor ao chegar no final (ou chegar em outro trecho já transmitido) deve transmitir os trecho que ficaram para trás mas não foram transmitidos. Caso a ID do vídeo seja diferente do vídeo que o servidor está fazendo o streaming, o servidor começará a enviar os trechos do novo vídeo e cancelará o vídeo antigo. Ex.: [0..7] [8..15] [16..47] [48..79] 1 (Versão v.1) 0xFF (Mensagem de Requisição) (ID do vídeo) 0 (diz qual o próximo trecho) 0xFE Parar de Enviar. Usada pelo cliente para mandar o servidor parar de enviar trechos dos vídeos. Não necessita informação adicional. Ex.: [0..7] [8..15] 1 (Versão v.1) 0xFE (Parar de enviar vídeos) 13

14 0xFD Trecho de vídeo. Enviado pelo servidor transportando um trecho do vídeo. Temos os seguintes campos: [0..3] ID do vídeo. [4..7] Trecho do vídeo. Indica qual trecho está sendo transmitido. [8..11] Tamanho do trecho transmitido (k). [12..k + 12] Trecho do streaming do vídeo. O k é lido do campo anterior. [0..7] [8..15] [16..47] [48..79] [ ] [ ] 1 (Versão v.1) 0xFD (Enviando informações de vídeos) (ID do vídeo) 0 (diz qual o próximo trecho) (Informa o tamanho do trecho na mensagem) Esse campo contém o trecho de vídeo. 14

15 Comportamento da aplicação Cliente Quando o cliente é inicializado ele fica em um estado offline, 15

16 Comportamento do Servidor de Vídeos Quando o servidor entrar no ar ele vai ficar esperando alguma conexão. Quando algum cliente se conecta, o servidor fica em um estado de espera até o cliente fazer alguma requisição indo para o estado passivo. Essas requisições são feitas nos dois canais e as respostas são em paralelo, no entanto, ver o servidor de vídeos como uma única entidade facilita a sua compreensão. Mensagens de Navegação: A qualquer momento, qualquer que seja o estado do servidor (exceto desconectado), se for uma requisição de informação de vídeo o servidor envia logo em seguida os vídeos requisitados. O servidor também envia informações de vídeo a cada vez que um novo vídeo é adicionado ao servidor*. Mensagens de Streaming: Se o servidor estiver passivo e receber uma mensagem de requisição de vídeo, ele vai entrar em um novo estado de enviando o vídeo. A partir do momento que o servidor entra no estado enviando, ele só sai desse estado se uma das seguintes ações ocorrerem: Se o cliente mandar uma mensagem para o servidor parar de enviar vídeos. Indo para o estado passivo. Se o vídeo for completamente transferido para o cliente**. Se algum erro ocorrer. Obs.: Se algum outro vídeo for requisitado durante o envio, o servidor carrega o outro vídeo para ser enviado mas continua no mesmo estado apesar de ser outro vídeo. Mensagens de Erro: Até três erros de mensagem inválida seguidos são ignorados pela aplicação. Caso se repita três vezes, o servidor encerrará a conexão naquele canal, já que os contextos são diferentes. Já os erros de versão sempre encerram a conexão no canal. 16

17 * Essas atualizações são passadas diretamente ao cliente (envia apenas as novas informações). ** Caso o servidor adiante 17

18 Conclusão Esse trabalho teve como aspecto principal o da compreensão do funcionamento de um protocolo de rede, nesse caso, em nível de aplicação, os conceitos aplicados (confiabilidade, garantia de atraso razoável) e a manipulação de mídias digitais em formato MPEG-4. O desenvolvimento do CIneVision, nesse trabalho, teve como papel o de proporcionar a experiência prática do funcionamento do protocolo desenvolvido, da avaliação desse e da manipulação de mídias MPEG-4 através de bibliotecas. No nosso caso, a linguagem de programação Java foi escolhida para a implementação da aplicação. A biblioteca utilizada para a manipulação de vídeos utilizada foi a Java Media Framework (JMF). Como a JMF pura não dá suporte ao formato de vídeo especificado pelo MPEG-4, utilizamos o plugin FOBS para estender a biblioteca JMF e dar suporte a esse tipo de mídia. 18

19 Anexos: ERRO_DE_CONEXÃO Desconectar() PAUSED Play() && DOWNLOAD_COMPLETE ERRO_DE_CONEXÃO Pause() ERRO_DE_CONEXÃO OFF PLAYING Stop() Conectar-se() Play() &&!DOWNLOAD_COMPLETE Requisitar_vídeo() && Downloaded Pause() ERRO_DE_CONEXÃO DOWNLOAD_COMPLETE CONNECTED ERRO_DE_CONEXÃO PLAYING AND BUFFERING Requisitar_vídeo() bufferatual < buffermínimo BUFFERING bufferatual > buffermínimo &&!Downloaded Anexo1: Máquina de Estados do Cliente 19

20 ERRO Desconectou-se() Atualizar_Lista_Vídeos() OFF Conectar() ON_WAIT ERRO Desconectou-se() Cliente_Desconectou() Desconectou-se() ERRO Cliente_Desconectou() Cliente_Conectou-se() ON_SEND Recebida_requisição_Vídeo() ON_IDLE Atualizar_Lista_Vídeos() ENVIO_VIDEO_CONCLUIDO Cliente_Cancelou_Vídeo() ERRO_NO_ARQUIVO_EM_DISCO Atualizar_Lista_Vídeos() Anexo2: Máquina de Estados do Servidor 20

21 Referências Bibliográficas [1] Streaming, In Wikipedia. Online, acesso em 20/11/2008 na url [2] YouTube, In Wikipedia. Online, acesso em 20/11/2008 na url Bibliografias Página da Sun sobre JMF [ Página do FOBS (plugin do JMF que dá suporte a MPEG-4) [ Request For Comments do o RTP [RFC 3550] [ 21