Proposta de uma Ferramenta de
Monitoramento de Desempenho
em Tempo Real para aplicações
  Live Streaming baseadas no
     ...
UNIVERSIDADE DO VALE DO RIO DOS SINOS




        MAURÍCIO BENTO GHEM




    Proposta de uma Ferramenta de
Monitoramento ...
“O futuro pertence a quem souber libertar-se da idéia tradicional do trabalho
como obrigação ou dever e for capaz de apost...
AGRADECIMENTOS



    Gostaria de agradecer a meus pais que desde pequeno me incentivaram a estudar, e
me apoiaram acredit...
SUMÁRIO




LISTA DE ABREVIATURAS E SIGLAS . . . . . . . . . . . . . . . . . . . .                    8



LISTA DE FIGURA...
2.2.1     Atraso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.2.2     Jitter . . . . . . ...
3.3.3     Atraso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

3.3.4     Jitter . . . . . . ...
REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   89
LISTA DE ABREVIATURAS E SIGLAS



ACK     Acknowledge

ASCII   American Standard Code for Information Interchange

CNAME  ...
RR     Receiver Report

RTCP   RTP Control Protocol

RTP    Real-time Transport Protocol

RTT    Round Trip Time

SDES   S...
LISTA DE FIGURAS



Figura 2.1: Diagrama demonstrando uma transmissão por streaming. . . . 21

Figura 2.2: Diagrama aprese...
Figura 3.5: Diagrama da classe ThreadPcap. . . . . . . . . . . . . . . . . . 63

Figura 3.6: Diagrama da classe classqueri...
LISTA DE TABELAS



Tabela 2.1: Tipos de mensagem e códigos ICMP associados com a des-
            crição. . . . . . . . ....
RESUMO



    A utilização de aplicações em tempo real sobre redes de pacotes (ex: VoIP, videocon-
ferência, live streamin...
A Propose for a Real Time Monitoring Tool for Live Streaming Applications, based
                                  on the ...
15




1    INTRODUÇÃO



    O live streaming é todo conteúdo audiovisual capturado em tempo real e disponi-
bilizado par...
16


iáveis simples e são complexas no tratamento de variáveis mais complexas e que exigem
um histórico de amostras (como ...
17


Ao invés de decodificar os pacotes de controle da transmissão live streaming, o trabalho
propôs a geração de logs por ...
18


     Neste primeiro capítulo, é apresentado o contexto no qual este trabalho está inserido,
o problema que busca solu...
19


é executado o teste-piloto, sendo descrita cada uma das etapas contempladas pelo teste.
Na próxima seção, são apresen...
20




2     REVISÃO BIBLIOGRÁFICA



     Neste capítulo serão abordados os conceitos teóricos que subsidiam o tema desse...
21


streaming.




             Figura 2.1: Diagrama demonstrando uma transmissão por streaming.


         Para ser poss...
22


Internet, por meio de programas de fácil acesso como o Skype 3 . A videoconferência
trouxe uma enorme quebra de parad...
23


lizam o protocolo NTP (Network Time Protocol). Para mais informações sobre o NTP ver
Rybaczyk (2005).

    Este atras...
24


           que estão entre a origem e o destino, e seu poder de processamento, con-
           tribuem diretamente pa...
25


2.2.1.2     Atraso de ida e volta

    O atraso de ida e volta é o tempo que um pacote leva para ser enviado por um e...
26


a reprodução possa ser feita de modo síncrono (LIMA, 2006). A compensação de jitter
pode ser observada na figura 2.2.
...
27


ainda, por causa do buffer de compensação de jitter (LIMA, 2006).

    Como a rede IP, por si só, não garante a entre...
28


        de corrigir eventuais situações ocorridas devido à perda de pacotes. Existem três
        classes de compensa...
29


taxa diferente (adequando-se a largura de banda disponível), ou terá que desistir de enviar
os dados, pois se os dado...
30


2.3         Protocolo de Sinalização: SIP

         O SIP é (Session Initiation Protocol) um protocolo de sinalização...
31


     os dados SIP, contêm dentro dela dados do protocolo SDP (Session Description
     Protocol), definido na RFC 2327...
32


     O ambiente no qual é executado o protocolo SIP é dotado de duas entidades físicas: o
cliente e o servidor. O cli...
33


sição SIP. A resposta aceita, rejeita ou redireciona a requisição. Da mesma maneira que o
UAC, este papel é mantido a...
34


e o registrar. Se um UA se mover na rede e deseja negociar novos parâmetros do registro,
ele pode cancelar um registr...
35


um overhead de informações na rede. Além disso, o TCP não suporta a entrega de pa-
cotes via multicast (entrega de um...
36


(SCHULZRINNE et al., 2003), em 2003, o IETF submeteu a nova especificação RFC
3550.

         O RTP é específico para o...
37


cações. A primeira modificação aconteceu no instante de tempo em que os pacotes RTCP
são enviados. No modelo original,...
38


           tura mínima de uma sessão, como o descobrimento do nome dos participantes, con-
           forme entram e ...
39




         Figura 2.5: O tipo de pacote sender report, do protocolo RTCP.


2.5    Protocolo para Feedback : ICMP

  ...
40




         Figura 2.6: O tipo de pacote receiver report, do protocolo RTCP.

sulte a especificação do protocolo ICMP, ...
41



 Tipo de mensagem ICMP Código                              Descrição
             0                  0              ...
42


sentação e interação do usuário. Com o MVC é possível aliar um desenvolvimento ágil
com um baixo acoplamento, isoland...
43


  1. Model: Representa os dados da corporação e as regras de negócios. Muitas vezes,
     serve como uma aproximação ...
44


2.7    Síntese do capítulo

     Neste capítulo foram abordados os conceitos necessários para o desenvolvimento do
pr...
45




3        METODOLOGIA DE DESENVOLVIMENTO



        Neste capítulo são abordadas as etapas necessárias para o desenv...
46


orientada à objetos. Por meio de duas ferramentas foi possível desenvolver a parte lógica
e a parte gráfica do protóti...
47


executou o gateway server Asterisk e um switch. A topologia de redes utilizada é apre-
sentada na figura 3.1.




Figu...
48


3.1.2.2         Máquina 2

         Esta máquina foi responsável por executar o gateway server para as ligações VoIP,...
49


           (d) Rede: Ethernet 100 Mbps.

   2. Especificações de software:

           (a) Sistema Operacional: Window...
50


     9. REQ09: A topologia da rede não deve ser alterada para que funcione a ferramenta.



3.3      Técnicas

      ...
51


algum atributo específico, ou tenham relação com algum evento de rede. Esta análise bus-
cou pacotes que fossem releva...
52


        live streaming. Portanto, o único dado que foi monitorado é o tamanho dos pacotes
        da transmissão.

  ...
53


   5. Incrementa e/ou armazena o valor do tamanho do pacote. Apenas é armazenado o
        valor na primeira execução...
54


     4. Aplica a equação 3.1, convertendo o dado para base 100.


                                                   ...
55


    Este algoritmo utiliza uma variável a mais, que não seria necessária para este algo-
ritmo, porém ela é utilizada...
56


              ii. Atribui: SomaDeDeltas = SomaDeDeltas + Delta;
             iii. Atribui: Incrementa em 1 unidade Nu...
Tcc Mauricio Bento Ghem 2009 - Proposta de uma Ferramenta de Monitoramento de Desempenho em Tempo Real para aplicações Liv...
Tcc Mauricio Bento Ghem 2009 - Proposta de uma Ferramenta de Monitoramento de Desempenho em Tempo Real para aplicações Liv...
Tcc Mauricio Bento Ghem 2009 - Proposta de uma Ferramenta de Monitoramento de Desempenho em Tempo Real para aplicações Liv...
Tcc Mauricio Bento Ghem 2009 - Proposta de uma Ferramenta de Monitoramento de Desempenho em Tempo Real para aplicações Liv...
Tcc Mauricio Bento Ghem 2009 - Proposta de uma Ferramenta de Monitoramento de Desempenho em Tempo Real para aplicações Liv...
Tcc Mauricio Bento Ghem 2009 - Proposta de uma Ferramenta de Monitoramento de Desempenho em Tempo Real para aplicações Liv...
Tcc Mauricio Bento Ghem 2009 - Proposta de uma Ferramenta de Monitoramento de Desempenho em Tempo Real para aplicações Liv...
Tcc Mauricio Bento Ghem 2009 - Proposta de uma Ferramenta de Monitoramento de Desempenho em Tempo Real para aplicações Liv...
Tcc Mauricio Bento Ghem 2009 - Proposta de uma Ferramenta de Monitoramento de Desempenho em Tempo Real para aplicações Liv...
Tcc Mauricio Bento Ghem 2009 - Proposta de uma Ferramenta de Monitoramento de Desempenho em Tempo Real para aplicações Liv...
Tcc Mauricio Bento Ghem 2009 - Proposta de uma Ferramenta de Monitoramento de Desempenho em Tempo Real para aplicações Liv...
Tcc Mauricio Bento Ghem 2009 - Proposta de uma Ferramenta de Monitoramento de Desempenho em Tempo Real para aplicações Liv...
Tcc Mauricio Bento Ghem 2009 - Proposta de uma Ferramenta de Monitoramento de Desempenho em Tempo Real para aplicações Liv...
Tcc Mauricio Bento Ghem 2009 - Proposta de uma Ferramenta de Monitoramento de Desempenho em Tempo Real para aplicações Liv...
Tcc Mauricio Bento Ghem 2009 - Proposta de uma Ferramenta de Monitoramento de Desempenho em Tempo Real para aplicações Liv...
Tcc Mauricio Bento Ghem 2009 - Proposta de uma Ferramenta de Monitoramento de Desempenho em Tempo Real para aplicações Liv...
Tcc Mauricio Bento Ghem 2009 - Proposta de uma Ferramenta de Monitoramento de Desempenho em Tempo Real para aplicações Liv...
Tcc Mauricio Bento Ghem 2009 - Proposta de uma Ferramenta de Monitoramento de Desempenho em Tempo Real para aplicações Liv...
Tcc Mauricio Bento Ghem 2009 - Proposta de uma Ferramenta de Monitoramento de Desempenho em Tempo Real para aplicações Liv...
Tcc Mauricio Bento Ghem 2009 - Proposta de uma Ferramenta de Monitoramento de Desempenho em Tempo Real para aplicações Liv...
Tcc Mauricio Bento Ghem 2009 - Proposta de uma Ferramenta de Monitoramento de Desempenho em Tempo Real para aplicações Liv...
Tcc Mauricio Bento Ghem 2009 - Proposta de uma Ferramenta de Monitoramento de Desempenho em Tempo Real para aplicações Liv...
Tcc Mauricio Bento Ghem 2009 - Proposta de uma Ferramenta de Monitoramento de Desempenho em Tempo Real para aplicações Liv...
Tcc Mauricio Bento Ghem 2009 - Proposta de uma Ferramenta de Monitoramento de Desempenho em Tempo Real para aplicações Liv...
Tcc Mauricio Bento Ghem 2009 - Proposta de uma Ferramenta de Monitoramento de Desempenho em Tempo Real para aplicações Liv...
Tcc Mauricio Bento Ghem 2009 - Proposta de uma Ferramenta de Monitoramento de Desempenho em Tempo Real para aplicações Liv...
Tcc Mauricio Bento Ghem 2009 - Proposta de uma Ferramenta de Monitoramento de Desempenho em Tempo Real para aplicações Liv...
Tcc Mauricio Bento Ghem 2009 - Proposta de uma Ferramenta de Monitoramento de Desempenho em Tempo Real para aplicações Liv...
Tcc Mauricio Bento Ghem 2009 - Proposta de uma Ferramenta de Monitoramento de Desempenho em Tempo Real para aplicações Liv...
Tcc Mauricio Bento Ghem 2009 - Proposta de uma Ferramenta de Monitoramento de Desempenho em Tempo Real para aplicações Liv...
Tcc Mauricio Bento Ghem 2009 - Proposta de uma Ferramenta de Monitoramento de Desempenho em Tempo Real para aplicações Liv...
Tcc Mauricio Bento Ghem 2009 - Proposta de uma Ferramenta de Monitoramento de Desempenho em Tempo Real para aplicações Liv...
Tcc Mauricio Bento Ghem 2009 - Proposta de uma Ferramenta de Monitoramento de Desempenho em Tempo Real para aplicações Liv...
Tcc Mauricio Bento Ghem 2009 - Proposta de uma Ferramenta de Monitoramento de Desempenho em Tempo Real para aplicações Liv...
Tcc Mauricio Bento Ghem 2009 - Proposta de uma Ferramenta de Monitoramento de Desempenho em Tempo Real para aplicações Liv...
Upcoming SlideShare
Loading in …5
×

Tcc Mauricio Bento Ghem 2009 - Proposta de uma Ferramenta de Monitoramento de Desempenho em Tempo Real para aplicações Live Streaming baseadas no protocolo RTP

3,744 views

Published on

Proposta de uma Ferramenta de Monitoramento de Desempenho em Tempo Real para aplicações Live Streaming baseadas no protocolo RTP

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
3,744
On SlideShare
0
From Embeds
0
Number of Embeds
2,261
Actions
Shares
0
Downloads
57
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Tcc Mauricio Bento Ghem 2009 - Proposta de uma Ferramenta de Monitoramento de Desempenho em Tempo Real para aplicações Live Streaming baseadas no protocolo RTP

  1. 1. Proposta de uma Ferramenta de Monitoramento de Desempenho em Tempo Real para aplicações Live Streaming baseadas no protocolo RTP por Maurício Bento Ghem
  2. 2. UNIVERSIDADE DO VALE DO RIO DOS SINOS MAURÍCIO BENTO GHEM Proposta de uma Ferramenta de Monitoramento de Desempenho em Tempo Real para aplicações Live Streaming baseadas no protocolo RTP Monografia apresentada como requisito parcial para a obtenção do grau de Bacharel em Engenharia da Computação Prof. Msc. Eduardo Leivas Bastos Orientador São Leopoldo, Dezembro de 2009
  3. 3. “O futuro pertence a quem souber libertar-se da idéia tradicional do trabalho como obrigação ou dever e for capaz de apostar numa mistura de atividades, onde o trabalho se confundirá com o tempo livre, com o estudo e com o jogo, enfim, com o ’ócio criativo’.” — D OMÊNICO D E M ASI
  4. 4. AGRADECIMENTOS Gostaria de agradecer a meus pais que desde pequeno me incentivaram a estudar, e me apoiaram acreditando em meu potencial. Também, por me apoiar nas etapas da vida, me dar amor e proporcionar sempre as melhores condições em tudo. Pais, amo vocês. Agradeço a meu irmão por em momentos de total enlouquecimento devido ao tra- balho de conclusão entender minha situação e conversar comigo para relaxar um pouco. Agradeço a minha namorada por tentar compreender minha situação e ficar do meu lado nos muitos finais de semana que dediquei ao estudo. Agradeço aos meus amigos por entenderem a fase da vida que estou passando, por darem apoio e atenção nos momentos que mais precisei, e por estar ao meu lado mesmo eu estando um pouco ausente. Agradeço a meu orientador que me deu motivação, conhecimento, e muitas outras contribuições. Agradeço por acreditar em meu potencial e me dar forças que resultaram numa grande vontade em fazer o mestrado. Por fim, gostaria de fazer uma dedicação especial a todas as pessoas que frequentam meu blog. A troca de experiências para o crescimento pessoal e profissional é recíproca. Agora, é minha vez de agradecer a todos que me deram motivação, ajuda e compreensão nesta etapa. Valeu pessoal.
  5. 5. SUMÁRIO LISTA DE ABREVIATURAS E SIGLAS . . . . . . . . . . . . . . . . . . . . 8 LISTA DE FIGURAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 LISTA DE TABELAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 RESUMO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 ABSTRACT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 1.1 Trabalhos relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 1.2 Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 1.3 Estrutura do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2 REVISÃO BIBLIOGRÁFICA . . . . . . . . . . . . . . . . . . . . . . . . 20 2.1 Live Streaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.2 Fatores que afetam a transmissão Live Streaming . . . . . . . . . . . 22
  6. 6. 2.2.1 Atraso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.2.2 Jitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.2.3 Perda de Pacotes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.2.4 Largura de Banda Disponível . . . . . . . . . . . . . . . . . . . . . . 28 2.3 Protocolo de Sinalização: SIP . . . . . . . . . . . . . . . . . . . . . . . 30 2.3.1 User Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 2.3.2 Proxy Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 2.3.3 Redirect Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 2.3.4 Registrar Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 2.3.5 Gateway Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 2.4 Protocolos de Transporte . . . . . . . . . . . . . . . . . . . . . . . . . . 34 2.4.1 Real-time Transport Protocol (RTP) . . . . . . . . . . . . . . . . . . . 35 2.4.2 RTP Control Protocol (RTCP) . . . . . . . . . . . . . . . . . . . . . . 36 2.5 Protocolo para Feedback : ICMP . . . . . . . . . . . . . . . . . . . . . . 39 2.6 Padrão de Arquitetura: MVC . . . . . . . . . . . . . . . . . . . . . . . . 41 2.7 Síntese do capítulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 3 METODOLOGIA DE DESENVOLVIMENTO . . . . . . . . . . . . . . . 45 3.1 Ambiente de Desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . 45 3.1.1 Ferramentas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 3.1.2 Dispositivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 3.2 Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 3.3 Técnicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 3.3.1 Tráfego RTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 3.3.2 Perda de Pacotes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
  7. 7. 3.3.3 Atraso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 3.3.4 Jitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 3.4 Modelagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 3.5 Implementação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 3.5.1 Lógica - Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 3.5.2 Interface gráfica - View . . . . . . . . . . . . . . . . . . . . . . . . . . 65 3.5.3 Controlador - Controller . . . . . . . . . . . . . . . . . . . . . . . . . 67 3.5.4 Extra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 3.6 Síntese do capítulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 4 EXPERIMENTAÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 4.1 Ambiente de Experimentação . . . . . . . . . . . . . . . . . . . . . . . 71 4.1.1 Máquina Virtual 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 4.1.2 Máquina Virtual 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 4.1.3 Máquina Virtual 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 4.2 Experimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 4.3 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 4.4 Discussão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 4.4.1 Tráfego RTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 4.4.2 Atraso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 4.4.3 Perda de Pacotes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 4.4.4 Buffer de compensação de jitter . . . . . . . . . . . . . . . . . . . . 84 4.5 Síntese do Capítulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 5 CONCLUSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
  8. 8. REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
  9. 9. LISTA DE ABREVIATURAS E SIGLAS ACK Acknowledge ASCII American Standard Code for Information Interchange CNAME Canonical Name DARPA Defense Advanced Research Projects Agency FEC Forward Error Correction GUI Graphical User Interface ICMP Internet Control Message Protocol IDE Integrated Development Environment IETF Internet Engineer Task Force IP Internet Protocol MGCP Media Gateway Control Protocol MVC Model View Controller NTP Network Time Protocol PABX Private Automatic Branch Exchange PSNR Peak Signal Noise Ratio PSTN Public Switched Telephone Network QoS Quality of Service RFC Request for Comments
  10. 10. RR Receiver Report RTCP RTP Control Protocol RTP Real-time Transport Protocol RTT Round Trip Time SDES Source Description SIP Session Initiation Protocol SNMP Simple Network Management Protocol SO Sistema Operacional SR Sender Report SSRC Synchronization Source TCP Transmission Control Protocol TTL Time to live UAC User Agent Client UAS User Agent Server UA User Agent UDP User Datagram Protocol
  11. 11. LISTA DE FIGURAS Figura 2.1: Diagrama demonstrando uma transmissão por streaming. . . . 21 Figura 2.2: Diagrama apresentando o buffer de compensação de jitter em ação (LIMA, 2006). . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Figura 2.3: Funções das entidades numa rede SIP. . . . . . . . . . . . . . . 32 Figura 2.4: O pacote RTP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Figura 2.5: O tipo de pacote sender report, do protocolo RTCP. . . . . . . . 39 Figura 2.6: O tipo de pacote receiver report, do protocolo RTCP. . . . . . . 40 Figura 2.7: Apresentação de diversas visualizações possíveis por causa do MVC, sem alterar a integridade dos dados de negócio (BUSCHMANN et al., 1996). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Figura 2.8: Diagrama contendo os relacionamentos e papéis de cada uma das partes que compõem o padrão MVC (MICROSYSTEMS, 2008). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Figura 3.1: Diagrama da topologia de redes utilizada para o ambiente de pré-teste. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Figura 3.2: Diagrama da organização de pacotes por agrupamento de fun- cionalidades. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 Figura 3.3: Diagrama do modelo de classes do projeto. . . . . . . . . . . . . 60 Figura 3.4: Diagrama de classes completo do protótipo. . . . . . . . . . . . 61
  12. 12. Figura 3.5: Diagrama da classe ThreadPcap. . . . . . . . . . . . . . . . . . 63 Figura 3.6: Diagrama da classe classquerierpcap. . . . . . . . . . . . . . . . 63 Figura 3.7: Diagrama da classe ThreadICMP. . . . . . . . . . . . . . . . . . 64 Figura 3.8: Diagrama da classe QuerierICMP. . . . . . . . . . . . . . . . . . 65 Figura 3.9: Diagrama de classes completo do pacote Model. . . . . . . . . 65 Figura 3.10: Diagrama da classe GuiInicial. . . . . . . . . . . . . . . . . . . . 66 Figura 3.11: Diagrama da classe GuiSmB. . . . . . . . . . . . . . . . . . . . . 67 Figura 3.12: Diagrama da classe Grafico. . . . . . . . . . . . . . . . . . . . . 67 Figura 3.13: Diagrama de classes completo do pacote View. . . . . . . . . . 68 Figura 3.14: Diagrama de classes completo do pacote Controller. . . . . . . 68 Figura 3.15: Diagrama de classes completo do pacote Extra. . . . . . . . . . 69 Figura 4.1: Topologia de redes simulada que foi utilizada no ambiente de testes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 Figura 4.2: Interface gráfica inicial do protótipo. . . . . . . . . . . . . . . . . 74 Figura 4.3: Interfaces de rede disponíveis para execução do protótipo. . . . 74 Figura 4.4: Interface gráfica que representa a tela dos gráficos. . . . . . . . 76
  13. 13. LISTA DE TABELAS Tabela 2.1: Tipos de mensagem e códigos ICMP associados com a des- crição. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Tabela 4.1: Valores medidos para cada um das cinco execuções da apli- cação para o tráfego RTP. . . . . . . . . . . . . . . . . . . . . . . 77 Tabela 4.2: Valores medidos para cada um das cinco execuções da apli- cação para o atraso de ida e volta. . . . . . . . . . . . . . . . . . 78 Tabela 4.3: Valores estimados para cada um das cinco execuções da apli- cação para tamanho do buffer de compensação de jitter. . . . . 79 Tabela 4.4: Média aritmética de todos atributos da transmissão live stream- ing ao longo de cinco iterações. . . . . . . . . . . . . . . . . . . 80
  14. 14. RESUMO A utilização de aplicações em tempo real sobre redes de pacotes (ex: VoIP, videocon- ferência, live streaming) têm crescido muito nos últimos anos, principalmente em virtude da popularização da Internet e do acesso à banda larga. De modo diferente das aplicações que não são fortemente dependentes dos aspectos temporais da transmissão, as aplicações em tempo real exigem uma infra-estrutura de transporte que possa oferecer determinadas garantias de desempenho aos pacotes. Usualmente, tais garantias são expressas por um conjunto de quatro métricas: largura de banda, atraso, perda de pacotes e jitter. Exis- tem diversas soluções disponíveis no mercado para o monitoramento dessas métricas. No entanto, o cálculo dos valores usualmente depende da aplicação de certos algoritmos in- termediários que podem dificultar a tarefa. Esse trabalho teve como objetivo a criação de uma ferramenta em código-aberto e gratuita que fosse capaz de medir diretamente as quatro métricas descritas acima. Após o desenvolvimento da ferramenta, realizada com técnicas de engenharia de software, um experimento foi realizado com o intuito de verificar se os requisitos previamente propostos para a ferramenta foram atingidos. Os resultados demonstraram que houve pouca variação dos valores coletados em diferentes amostras, com exceção do jitter. Apesar de os testes terem sido realizados em ambiente controlado e com técnicas de coleta que podem influenciar as medições, a ferramenta demonstrou ser rápida e eficaz e pode servir para tornar mais clara e objetiva a medição de desempenho em redes de pacotes. Palavras-chave: Live Streaming. Métricas de desempenho de QoS. Ferramenta de mon- itoramento de redes.
  15. 15. A Propose for a Real Time Monitoring Tool for Live Streaming Applications, based on the RTP Protocol. ABSTRACT The use of real-time applications over packet networks (e.g. VoIP, videoconferencing, live streaming) have grown in recent years, mainly due the popularization of Internet and broadband access. Differently from the applications that are not heavily dependent on temporal aspects of transmission, the real-time applications require a transport infrastruc- ture that can provide certain performance guarantees to packets. Usually, such guaranties are expressed by a set of four metrics: bandwidth, delay, packet loss and jitter. There are some solutions available in the market for monitoring these metrics. However, the calcu- lation of the values usually depends on certain intermediary algorithms that may hinder the task. This study had the objective to create a free and open source tool that could di- rectly measure the four metrics described above. After the development of the tool, held by software engineering techniques, an experiment was conducted with the objective of whether the previously proposed requisites for the tool have been met. The results showed that there was almost no variation in the values obtained at different samples, except for jitter. Although the tests have been conducted in a controlled environment and with data collection techniques that could influence the measurements, the tool proved to be rapid and effective and can serve to make clear and objective the performance measurement in packet networks. Keywords: Live Streaming, QoS metrics, Network Monitoring Tool.
  16. 16. 15 1 INTRODUÇÃO O live streaming é todo conteúdo audiovisual capturado em tempo real e disponi- bilizado para inúmeros espectadores através da Internet (VELOS et al., 2002). Diversas aplicações multimídia podem ser caracterizadas por esse conceito, tais como conversações por VoIP (Voice over Internet Protocol), videoconferência e entretenimento, e educação à distância (EaD). De um ponto de vista mais específico, qualquer rede de transporte de da- dos baseada na técnica de comutação de pacotes (a Internet é apenas um caso particular) pode ser utilizada para suportar aplicações live streaming. Apesar de mais eficiente em termos de alocação de recursos do que a técnica de comutação de circuitos, a comutação de pacotes não reserva recursos para as aplicações. Cada pacote é visto como uma unidade de informação independente e tratado de maneira individual. Desta forma, os pacotes de uma aplicação podem sofrer atrasos variáveis quando passam em enlaces congestionados e até mesmo serem descartados em casos mais severos (KUROSE; ROSS, 2006). A literatura define quatro métricas de desempenho de rede que influenciam direta- mente no QoS (Quality of Service) oferecido às aplicações em geral: largura de banda, atraso, jitter e perda de pacotes. Em função de seus caráter instantâneo de transmissão, as aplicações live streaming necessitam de uma rede de transporte que ofereça garantias de desempenho que são expressas por valores adequados para cada uma dessas métricas (DURKIN, 2002). Apesar de haver um crescimento significativo na utilização de apli- cações em tempo real (motivado principalmente pelo barateamento do acesso à banda larga), percebe-se a inexistência de uma ferramenta gratuita e de código-aberto que mon- itore continuamente todas as quatro métricas de desempenho de rede oferecidas para uma aplicação em tempo real. Além disso, certas aplicações de monitoramento (especial- mente aquelas baseadas no protocolo SNMP) são dirigidas ao monitoramento de var-
  17. 17. 16 iáveis simples e são complexas no tratamento de variáveis mais complexas e que exigem um histórico de amostras (como o jitter, por exemplo). Esse trabalho tem como objetivo o desenvolvimento de um protótipo de ferramenta de código-aberto para o monitoramento do desempenho de aplicações live streaming baseadas no protocolo RTP (Real Time Protocol). A concepção desse trabalho teve in- ício dentro do projeto Convergência Digital da UNISINOS, que tinha como objetivo a criação de aplicações interativas para a tecnologia de TV Digital. O objetivo principal do projeto era permitir a maior interatividade possível do usuário com um meio de acesso. Nesse contexto, foi percebida a necessidade da criação de um sistema Web para interação aluno-professor utilizando-se um ambiente baseado em videoconferência. Além do sis- tema, uma ferramenta de monitoramento em tempo real também mostrou-se necessária com o intuito de informar o usuário da qualidade de sua transmissão live streaming. Optou-se pela análise de aplicações em tempo real baseadas no protocolo RTP em vir- tude de sua ampla utilização no transporte de conteúdo multimídia. O protocolo RTP utiliza como protocolo de transporte o UDP (User Datagram Protocol). O UDP é ampla- mente utilizado em transmissões com tempo real por ser bastante simples e não-orientado à conexão (MEGGELEN; SMITH; MADSEN, 2005). Apesar da possibilidade de real- ização de transmissões em tempo real utilizando o protocolo TCP (Transmission Control Protocol), optou-se pela análise de aplicações em tempo real baseadas em RTP. 1.1 Trabalhos relacionados Existem diversos trabalhos teóricos que procuram analisar o impacto das métricas de desempenho nas aplicações em tempo real. No entanto, poucos descrevem o desen- volvimento de ferramentas que podem ser utilizadas para medir tais métricas. Tao, Apos- tolopoulos e Guérin (2008) propôs uma investigação na qualidade de vídeo em redes IP, por meio da métrica PSNR (Peak Signal Noise Ratio). Este trabalho analisou diversos codecs e suas relações com a taxa de transmissão e características de vídeo, entre outros parâmetros. Por outro lado, Lima (2006) propôs a criação de um sistema que permitia a monitoração das ligações VoIP. Este sistema tinha um caráter centralizado, ou seja, toda a informação era obtida nos hosts repassada para um banco de dados que realizava cálculos para obter uma pontuação média de qualidade com relação à qualidade de uma ligação.
  18. 18. 17 Ao invés de decodificar os pacotes de controle da transmissão live streaming, o trabalho propôs a geração de logs por parte da aplicação utilizada na transmissão VoIP, que auxili- ado pelo protocolo SNMP (Simple Network Management Protocol) alimentava a base de dados. Um software pago que possui funcionalidades semelhantes, mas tem uma arquitetura centralizada, é o Cisco Voip Monitor Server 1 . Esta aplicação realiza toda monitoração que esta ferramenta propõe, centraliza todos os dados num servidor e requer a instalação de um agente em cada uma das máquinas que trafegará as ligações VoIP. Uma limitação desta aplicação é que ela possibilita a monitoração apenas de transmissões VoIP, e não qualquer outra que se baseie no live streaming. 1.2 Objetivo O presente trabalho tem como objetivo desenvolver um protótipo de uma ferramenta de monitoramento de desempenho em tempo real de transmissões live streaming baseada no protocolo RTP. Além do objetivo geral, este trabalho tem os objetivos específicos cita- dos a seguir: 1. Estudar as principais métricas de desempenho de QoS que impactam na transmissão live streaming (em tempo real). 2. Estudar e aplicar o padrão de arquitetura MVC no desenvolvimento do protótipo. 3. Propor técnicas de coleta das métricas de desempenho de QoS. 4. Medir os atributos de desempenho de uma transmissão em tempo real por meio do protótipo. 1.3 Estrutura do Trabalho A presente monografia está organizada em 6 capítulos. 1 Disponível em: http://www.cisco.com/en/US/products/sw/custcosw/ps1001/ prod- ucts_tech_note09186a008010e6ba.shtml. Acesso em 7/outubro/2009.
  19. 19. 18 Neste primeiro capítulo, é apresentado o contexto no qual este trabalho está inserido, o problema que busca solucionar, e os objetivos gerais e específicos. Também, são ap- resentados os trabalhos relacionados a obra, e a presente estrutura organizacional do tra- balho. No segundo capítulo, é apresentado cada um dos conceitos necessários para a pro- dução deste trabalho. Primeiro, é apresentado o que é e como funciona o streaming e sua evolução, o live streaming, e uma solução que implemente estas duas tecnologias. Em seguida, são apresentados e explicado a existência de cada fatores que afetam uma trans- missão live streaming, os fatores são: atraso, jitter, perda de pacotes e largura de banda. Na sequência, é explicado o protocolo de sinalização SIP (Session Initiation Protocol), responsável por estabelecer sessões entre os participantes de uma transmissão. Os próxi- mos itens a serem explicados são os protocolo RTP e RTCP, que atuam em conjunto per- mitindo a transmissão e controle dos dados entre integrantes de uma transmissão. Então, é apresentado o protocolo ICMP (Internet Control Message Protocol), parte integrando do Internet Protocol (IP), responsável por fornecer feedback de conectividade da rede. Na próxima seção é descrito o padrão de arquitetura que será utilizado para desenvolver o protótipo, o MVC (Model View Controller). Por fim, é feita uma síntese do que foi visto no capítulo. No terceiro capítulo, é abordada a metodologia empregada para o desenvolvimento deste trabalho. Primeiro, é descrito o ambiente de pré-testes, em termos de responsabi- lidade e especificações de hardware e software. Este ambiente é utilizado para execução das etapas da metodologia. Em seguida, é apresentado a metodologia para coleta, que engloba (1) a identificação dos dados necessário coletar na rede e sua obtenção, e (2) com base na análise dos dados da fase anterior são propostas técnicas de obtenção das métricas desempenho de QoS numa rede. Por fim, é apresentado a etapa de desenvolvi- mento do protótipo, desde o levantamento dos requisitos até a implementação das técnicas propostas na etapa anterior da metodologia. No quarto capítulo, é descrito a experimentação feita com o protótipo. Primeiro, é de- scrito o ambiente de testes utilizado, contemplando a responsabilidade e as especificações de software de cada uma dos dispositivos virtuais. Foram utilizadas máquinas virtuais, pois diferentemente do ambiente de pré-testes, este ambiente deve ser controlado. Então,
  20. 20. 19 é executado o teste-piloto, sendo descrita cada uma das etapas contempladas pelo teste. Na próxima seção, são apresentados os resultados obtidos com o teste e seus significa- dos, por meio de tabelas. Na última seção, é feita uma análise e discussão dos resultados obtidos. No quinto capítulo são feitas as conclusões deste trabalho. É feito um fechamento e apresentado as dificuldades encontradas, as limitações tanto da metodologia quanto do protótipo produzido e os trabalhos futuros que podem ser desenvolvidos com base neste.
  21. 21. 20 2 REVISÃO BIBLIOGRÁFICA Neste capítulo serão abordados os conceitos teóricos que subsidiam o tema desse estudo. Inicialmente o conceito de live streaming é apresentado e os problemas associados a transmissão em tempo real são descritos. Após, cada um dos protocolos que foram utilizados no trabalho são descritos: SIP, RTP, RTCP, e ICMP. Em seguida, o padrão de arquitetura MVC que será utilizado na modelagem do protótipo também é descrito detalhadamente. O último item do capítulo traz um resumo dos conceitos abordados. 2.1 Live Streaming A tecnologia de streaming consiste na quebra de um fluxo de dados em pequenos pedaços para enviá-los um a um sucessivamente, sendo que o receptor decodificará cada parte e a executará sem ter que esperar por todo o fluxo de dados (APOSTOLOPOULOS; TAN; WEE, 2002). Essa tecnologia existe desde que as transmissões por rádio e televisão analógica foram inventadas. O equipamento do espectador, desde aqueles tempos, recebia dados continuamente, sendo que simultaneamente esses dados eram apresentados, seja na tela ou nas caixas de som (TOPIC, 2002). Hoje em dia, esse conceito de streaming foi migrado para a Internet, preservando alguns princípios de antigamente, como o de oferecer conteúdo sob demanda para o usuário. Para que um conteúdo estático seja íntegro, é necessário que este seja disponibilizado em sua totalidade. O streaming, em relação ao conteúdo estático, possui uma grande vantagem: a possibilidade no acesso ao conteúdo sob demanda (TOPIC, 2002). Conforme o conteúdo é executado, as partes seguintes estão sendo recebidas e executadas, e desta forma segue, sucessivamente. A figura 2.1 apresenta um modelo de aplicação baseada no
  22. 22. 21 streaming. Figura 2.1: Diagrama demonstrando uma transmissão por streaming. Para ser possível a exibição do streaming são necessários três etapas. Primeiro, é necessário ter a mídia estática, como por exemplo um arquivo de vídeo codificado em MPEG-2. Então, precisa-se passar esta mídia para um servidor de streaming, que dividirá a mídia em pequenos pedaços, para serem enviados sequencialmente para o receptor. Por último, é necessário o receptor ter um player compatível (TOPIC, 2002). Uma solução de streaming disponível na Internet é o VideoLAN Streaming Solution 1 , que engloba o servidor de streaming e o player para ser executado no receptor. Esta aplicação suporta os mais diversos protocolos de transporte para aplicações streaming, tais como: RTP/RTCP, RTSP e HTTP. Também, suporta uma vasta gama de codecs 2 , citados a seguir: Mpeg-1, Mpeg-2, Mpeg-4, WMV, DivX e H.264. Esta solução possibilita a utilização não só de arquivos estáticos, mas também de mídias capturadas em tempo real, caracterizando o live streaming, que será explicado a seguir. A evolução do streaming é a chamada live streaming, que possibilita a transmissão ao vivo de uma mídia. Com esta tecnologia é possível enviar, diretamente, para a Internet um vídeo capturado por uma câmera sem ter que armazená-lo. Esta evolução permite que as emissoras transmitam via Internet eventos, programas e rádios em tempo real, permitindo o aumento no número de espectadores que assistem ou escutam seus programas. No entanto, a áudio e videoconferência foram as aplicações que foram mais difundidas pela 1 O VideoLAN Streaming Solution está disponível no seguinte endereço web: http://www.videolan.org/vlc/streaming.html. Acesso em: 09/10/2009. 2 Um codec é um conjunto de algoritmos de codificação (e decodificação) de sinais que tem como obje- tivo a compressão de um sinal buscando a menor perda de qualidade possível. Para mais informações sobre codecs, consultar Lima (2006).
  23. 23. 22 Internet, por meio de programas de fácil acesso como o Skype 3 . A videoconferência trouxe uma enorme quebra de paradigma, possibilitando que pessoas conversem frente a frente estando em qualquer lugar do mundo. Tanto o streaming quanto o live streaming podem ser implementados de muitas maneiras e com muitas ferramentas. Por ter menos overhead que o TCP, e por não ter confirmação de cada pacote recebido, o protocolo UDP se torna um atrativo. Em cima do protocolo UDP, é utilizado o RTP aliado ao RTCP (Real-time Control Protocol), que permite con- trole e geração de estatísticas da transmissão. Existem implementações que utilizam o TCP (Transmission Control Protocol) como protocolo de transporte, como a do Skype, mas o UDP é muito mais utilizado (TOPIC, 2002). 2.2 Fatores que afetam a transmissão Live Streaming As transmissões em tempo real são sensíveis a quatro parâmetros em uma rede co- mutada de pacotes: largura de banda, perda de pacotes, atraso e jitter (KUROSE; ROSS, 2006). Este parâmetros podem acarretar na degradação da qualidade da transmissão, se certos limiares forem ultrapassados. Nas seções seguintes, serão apresentados cada um dos parâmetros que podem acarretar na perda de qualidade na transmissão. 2.2.1 Atraso O atraso entre emissor e receptor é subdividido em duas classificações: atraso fim a fim e atraso de ida e volta. Estes dois tipos de atrasos serão apresentados a seguir, conforme Lima (2006). 2.2.1.1 Atraso fim a fim O atraso fim a fim é o tempo que um pacote leva para ir de um emissor para um recep- tor. Esta métrica é bastante problemática para ser estimada, pois podem existir diferenças nos relógios do emissor e do receptor. Para solucionar este problema, pode-se utilizar na rede equipamentos especializados ou serviços de sincronização de relógios que uti- 3 Skype é um programa que permite áudio e videoconferência gratuitamente. Ele está disponível em http://www.skype.com. Acesso em 09/10/2009.
  24. 24. 23 lizam o protocolo NTP (Network Time Protocol). Para mais informações sobre o NTP ver Rybaczyk (2005). Este atraso é composto por um somatório dos seguintes atrasos: percurso elétrico do pacote pela rede IP, formação e reprodução dos pacotes, processamento do sistema operacional e atraso nas redes IP. Estas origens de atraso serão discutidas nas seções a seguir, conforme Carvalho (2004) e Lima (2006). 1. Percurso Elétrico: Este atraso corresponde ao tempo em que é capturado um dado do meio físico, passado por um conversor A/D (Analógico/Digital), transformado-o numa linguagem que possa ser entendida e armazenada pelo computador. Um ex- emplo com voz, seria quando a voz do locutor passa pelo transdutor eletroacústico, para depois atingir o conversor A/D. No lado do receptor, o dado digital sai do con- versor D/A (Digital/Analógico) e vai para o transdutor eletroacústico. Este atraso é constante, porém mínimo, pois os elétrons percorrem os circuitos elétricos a uma velocidade próxima à da luz. 2. Formação e Reprodução dos Pacotes: Representa o tempo utilizado para o preenchi- mento com dados de voz e/ou vídeo os pacotes live streaming para serem enviados e reproduzidos no destino como um sinal audiovisual. Estes atrasos estão na faixa de 20 ms a 30 ms, na sua formação, e de 50 ms na sua reprodução. 3. Sistema Operacional: Este atraso é variável e depende do sistema operacional utilizado. O atraso está relacionado à fatia de tempo que o kernel do sistema opera- cional aloca para o processo responsável pela transmissão live streaming, à capaci- dade de processamento do sistema, à memória do equipamento e da quantidade de processos que estão em execução em paralelo. 4. Atraso nas Redes IP: Este é o atraso que é o gargalo na transmissão. Devido a este atraso, a interatividade da conversa pode sofrer um efeito desconfortável, e, segundo a recomendação G.114 (ITU, 2003) esse tempo não deve ultrapassar 150 ms, pois a degradação de qualidade é perceptível. Este atraso é composto por uma parte fixa e outra variável. (a) Atraso Variável: O atraso variável corresponde ao tempo em que o pacote passa pelas filas de transmissão. O número de roteadores e comutadores
  25. 25. 24 que estão entre a origem e o destino, e seu poder de processamento, con- tribuem diretamente para a formação do atraso variável. Uma maneira eficaz de minimizar este atraso é a implementação de QoS, permitindo que os pa- cotes live streaming tenham uma prioridade maior que os pacotes de dados convencionais. (b) Atraso Fixo: É composto por três tipo de atraso: tempo de empacotamento, tempo de serialização e atraso de propagação no meio físico. i. Tempo de empacotamento: Corresponde ao tempo necessário para se codificar ou decodificar os dados com os codecs necessários. Este tempo depende unicamente do tipo de codificação e codec utilizado. Caso o codec possua um algoritmo de alta complexidade, o tempo pode ser ex- tendido. Para maiores informações sobre codecs de áudio e vídeo consul- tar Lima (2006). ii. Tempo de serialização de bits: É o tempo necessário para se colocar os bits lógicos dos pacotes no meio físico de transmissão, sendo que este depende da velocidade do meio físico e do tamanho do pacote que está sendo transmitido. É possível obter este valor por meio da razão do tamanho do pacote já contendo o cabeçalho da camada de enlace e a taxa de transmissão do meio (ambos em kbps). iii. Atraso de propagação: Corresponde ao tempo em que os bits levarão para se propagar até o próximo nó da rede. Este tempo depende do meio físico que conecta um nó ao outro. Concluindo esta seção, o somatório dos tempos de fila, serialização e propagação compõem o tempo de rede. O primeiro é considerado um tempo estocástico, pois pacotes distintos de um mesmo fluxo de dados podem sofrer atrasos de filas diferentes, a depen- der do caminho percorrido pela rede IP. Já os tempos de serialização e propagação são considerados tempos determinísticos, pois são tempos fixos a depender da velocidade de transmissão do meio físico.
  26. 26. 25 2.2.1.2 Atraso de ida e volta O atraso de ida e volta é o tempo que um pacote leva para ser enviado por um emissor, recebido pelo receptor, e devolvido para o emissor. Outro nome o qual é referido este atraso é o round trip time, ou RTT. Diferente ao outro tipo de atraso, o atraso de ida volta não depende da sincronicidade dos relógios, porém, algumas considerações devem ser feitas, como por exemplo, a precisão mínima de leitura do relógio no sistema operacional. Mas, os mesmo princípios apresentados na seção 2.2.1.1, de composição do atraso se aplicam para este também. Este atraso não corresponde ao valor do atraso fim a fim multiplicado por dois, pois a rede IP é assimétrica, portanto, o tempo que o pacote leva para chegar ao seu destino não corresponde, necessariamente, ao mesmo tempo que levaria para voltar à sua origem. Isto depende da maneira na qual os pacotes são roteados e comutados ao longo da rede. 2.2.2 Jitter O jitter se refere à variação na latência entre dois pacotes, ou seja, é a diferença entre as latências de dois pacotes, medida em dois instantes de tempos diferentes. Quando um fluxo live streaming é enviado para um dispositivo, ele é enviado à uma taxa constante com uma pequena variação na latência. No entanto, conforme os pacotes atravessam a rede, a latência dos pacotes pode variar, e chegar no destino em tempos diferentes, e pos- sivelmente, fora de ordem. O buffer de compensação de jitter é uma área de memória em que os pacotes são reordenados e entregados em streams constantes e reguladas (MEGGE- LEN; SMITH; MADSEN, 2005). Os pacotes necessitam de um tempo para se propagar da origem até o destino na rede IP. A diferença entre o tempo de chegada e o de partida é composta por uma parte fixa e outra variável (jitter). Esta parte variável se deve ao comportamento das filas de roteamento, como visto na seção 2.2.1.1. Caso os pacotes recebidos fossem executados sem nenhum tratamento para jitter, a qualidade da transmissão seria comprometida. Para isso, os receptores da transmissão implementam um buffer para compensar os efeitos do jitter. Este buffer tem como função segurar os pacotes por um tempo máximo até que os seus adjacentes possam chegar, e
  27. 27. 26 a reprodução possa ser feita de modo síncrono (LIMA, 2006). A compensação de jitter pode ser observada na figura 2.2. Figura 2.2: Diagrama apresentando o buffer de compensação de jitter em ação (LIMA, 2006). O tamanho deste buffer é o período de tempo máximo em que este pacote aguardará até ser reproduzido pelo cliente. Este valor deve ser bem especificado, pois se o tamanho for muito pequeno, os pacotes correm o risco de não chegarem a tempo e serem descarta- dos, em contrapartida, se o tamanho do buffer de compensação for muito grande o atraso fim a fim será aumentado, degradando a qualidade da transmissão. Segundo Meggelen, Smith e Madsen (2005), este valor não deve exceder 30 ms para uma transmissão com streaming. Para se determinar corretamente o valor do buffer, duas variáveis devem ser anal- isadas: a perda de pacotes e o atraso fim a fim. Também, é levado em consideração que estes valores devem respeitar os limiares de segurança, para que não se tenha uma degradação na qualidade da transmissão. Para a perda de pacotes o valor é 5% e para o atraso fim a fim é de 150 ms, conforme ITU (2003). 2.2.3 Perda de Pacotes Uma perda de pacote, sob o ponto de vida da transmissão pela rede IP, ocorre quando o mesmo não consegue chegar ao seu destinatário. A perda de pacotes é impactante no contexto de uma aplicação live streaming. Os três principais motivos pelos quais podem ocorrer perdas de pacotes são: erros na transmissão, descarte pelos roteadores de rede, ou
  28. 28. 27 ainda, por causa do buffer de compensação de jitter (LIMA, 2006). Como a rede IP, por si só, não garante a entrega dos pacotes, no momento que ela se encontra sobrecarregada, ocorrem congestionamentos. Quando o roteador está com seus buffers cheios, a solução empregada por eles é o descarte dos pacotes. Se o protocolo de transporte empregado for o TCP, este cuidará para que os pacotes sejam retransmitidos. Ao passo que se for utilizado o UDP, como é um protocolo simples e não-orientado à conexão, os pacote não são recuperados. O problema de perdas de pacotes pode ser amenizado, utilizando técnicas ou mecan- ismos de reparação de pacotes perdidos, tais como: FEC (Forward Error Correction), in- terleaving, retransmissão e compensação. Cada uma destas técnicas e mecanismos serão apresentadas nos itens a seguir, conforme Balbinot et al. (2003). 1. FEC: Este mecanismo é um dos mais utilizados na atualidade, para manutenção na qualidade de sistemas VoIP. Com o FEC é adicionado uma redundância nos dados, permitindo a correção de dados perdidos ao longo da transmissão. A cada quadro ou pacote de voz, é adicionada informação relacionada às amostras de voz mais adiantadas ou mais atrasadas. Deve-se pesar bastante a necessidade de utilizar este mecanismo, pois como é adicionado uma redundância de dados na rede, pode-se causar congestionamento desnecessário. Se a perda já é decorrente de um conges- tionamento, o aumento neste fluxo pode agravar a situação. 2. Interleaving: Esta técnica reordena os quadros de mídia de múltiplos pacotes se- quencias, interpolando-os antes de efetuar o envio deste fluxo de dados. Quando o receptor receber este fluxo, este é reordenado em sua ordem original. Caso ocorra alguma perda de pacotes ao longo da transmissão, terá sido perdido poucos quadros, possibilitando uma reconstrução da mídia com perdas não significativas. Combi- nada com técnicas de compensação, pode-se obter um nível aceitável de qualidade para taxas não muito elevadas de perda. 3. Retransmissão: Esta técnica reenvia o pacote perdido. Para esta técnica ter sucesso é necessário que o pacote retransmitido chegue ao receptor a tempo para ser repro- duzido. Normalmente, esta técnica é utilizada em redes com alta disponibilidade. 4. Compensação: Este mecanismo é aplicado no lado do receptor, com o objetivo
  29. 29. 28 de corrigir eventuais situações ocorridas devido à perda de pacotes. Existem três classes de compensação que podem ser utilizadas: técnicas de inserção, interpo- lação e regeneração. (a) Técnica de inserção: Prevê a substituição do pacote perdido por ruído, silên- cio ou a repetição do último pacote recebido com sucesso; (b) Interpolação: Procura recriar uma versão similar do pacote perdido através da interpolação entre pacotes adjacentes, armazenados num buffer de amostras; (c) Regeneração: Amplia o conceito da interpolação utilizando além dos pacotes adjacentes, informações à respeito do codec utilizado na codificação dos da- dos. Pacotes que chegam demasiadamente atrasados em relação ao instante de tempo que deveriam ser reproduzidos no receptor tornam-se inúteis, e consequentemente, são descar- tados. Do ponto de vista do receptor, estes pacotes foram perdidos. Portanto, para se calcular o número de pacotes perdidos num enlace, deve-se levar em conta as perdas dos pacotes na camada de rede e também na camada de aplicação. Para as transmissões live streaming, a perda de pacotes deve ser inferior a 5% (ITU, 2003). Caso este valor seja excedido, a perda da qualidade na transmissão é perceptível pelo usuário final. Numa transmissão VoIP, a qualidade da conversação será afetada. 2.2.4 Largura de Banda Disponível Numa rede de computadores, sempre é buscado que os dados fluam pelo melhor cam- inho por meio dos roteadores, partindo da origem para o destino. A quantidade de infor- mação por segundo que um meio de transmissão permite fluir é denominada largura de banda disponível. Este dado é expresso em bytes/segundo ou bits/segundo (RANJBAR, 2007). A demanda de utilização da largura de banda disponível é controlada pela aplicação. Algumas aplicações necessitam enviar dados a uma certa taxa mínima para funcionar com êxito, é o exemplo de aplicações live streaming. Esta aplicações, além de serem sensíveis à perda de pacotes, atraso e jitter, também são sensíveis à largura de banda. Se uma certa largura de banda não estiver disponível, a aplicação terá que codificar os dados a uma
  30. 30. 29 taxa diferente (adequando-se a largura de banda disponível), ou terá que desistir de enviar os dados, pois se os dados chegarem depois do que o esperado eles serão descartados de qualquer maneira (KUROSE; ROSS, 2006). Também, existem aplicações nas quais não necessitam uma largura de banda mínima. As chamadas aplicações elásticas tem a capacidade de fazer o uso de qualquer largura de banda mínima ou máxima disponível. Navegação web, correio eletrônico e transferência de arquivo são exemplos de aplicações elásticas (KUROSE; ROSS, 2006). A largura de banda disponível muitas vezes acaba por ser um dos grandes proble- mas numa rede. Isto ocorre, pois a solução direta para este problema é o aumento da largura de banda disponível. Mas, para isso ser possível são necessários investimentos na infra-estrutura, muitas vezes inviabilizando num primeiro momento este upgrade. Este é apenas um dos métodos para se poder trafegar mais dados numa rede. Todos os métodos disponíveis seguem a seguir, conforme Ranjbar (2007). 1. Aumentar a capacidade do link: Como foi mencionado no parágrafo a seguir, esta é a maneira mais efetiva, porém a com mais custo direto. Para que seja aumentada a capacidade do link de dados, é necessário um investimento, o que é uma certa limitação para a resolução deste problema. 2. Marcar e classificar tráfego e implantar técnicas de filas: Com este método é possível que os dados com maior prioridade sejam encaminhados primeiro ao longo da rede. Para que este método funcione, é necessário que os dados sejam demarcados na camada de acesso da rede, para que ao longo dela sejam aplicadas as técnicas de filas de prioridade. Para mais informações sobre filas de prioridades, consultar Ranjbar (2007). 3. Utilizar técnicas de compressão: Existem técnicas que realizam a compressão de dados de alguns protocolos. Devem ser utilizadas com muito planejamento, pois os equipamentos que realizarem esta compressão estarão realizando um processa- mento a mais do que em sua operação convencional. Algumas das técnicas exis- tentes são: compressão de TCP, de camada 2 e de RTP. Neste último, o roteador desempenha um papel crucial, pois este compressão mapeia os cabeçalhos IP, UDP e RTP, compactando esta soma de cabeçalhos dos 40 bytes originais, para 2 bytes.
  31. 31. 30 2.3 Protocolo de Sinalização: SIP O SIP é (Session Initiation Protocol) um protocolo de sinalização que roda na ca- mada de aplicação, que engloba a criação, modificação e finalização de uma sessão entre um e/ou mais participantes. Estas sessões incluem ligações via Internet, conferências e distribuição de conteúdo multimídia. Como o SIP é um protocolo que engloba apenas a sinalização, é necessário um protocolo que possibilite o transporte da informação fim-a- fim, neste contexto, o RTP é empregado. Idealizado por Henning Schulzrinne em 1990, no Departamento de Ciência da Com- putação da Universidade de Columbia, este protocolo teve sua primeira especificação formal submetida pelo IETF (Internet Engineering Task Force) em 1999, descrita na RFC (Request for Comments) 2543. O IETF continuou o trabalho de especificação e otimiza- ção do protocolo SIP, e em 2001 liberou outra especificação, a RFC 3261. Devido a sua simplicidade, extensibilidade e escalabilidade, ainda em 2001, diver- sas empresas começaram a adotar este protocolo em seus produtos, mesmo com outros protocolos já firmados no mercado como o H.323 e o MGCP (Media Gateway Control Protocol). Para mais informações sobre estes protocolos ver a referência Durkin (2002). Mesmo não sendo o protocolo de sinalização adotado por grande parte das empresas para conferências, este trabalho optou por utilizar o SIP, pois as soluções de código-aberto adotaram o SIP como padrão. O Asterisk é a principal aplicação de código-aberto para aplicações VoIP e conferência, conforme cita Meggelen, Smith e Madsen (2005). Um exemplo de solução que utiliza o Asterisk como base é a TrixBox 4 , que agrupa uma co- letânea de softwares que atuam em sinergia para ter como resultado um PABX que pode interligar redes IP com redes PSTN (rede telefônica pública comutada). O protocolo SIP foi criado para ser simples, deste modo a codificação das mensagens é feita toda em caracteres ASCII (ROSENBERG et al., 2002). Desta maneira, é possível ver todas as mensagens em formato de texto. Todas os tipos de mensagens trocadas pelo protocolo SIP são apresentadas nos itens a seguir, conforme Lima (2006) e Rosenberg et al. (2002). 1. INVITE: utilizada para se iniciar uma chamada. Esta mensagem, além de possuir 4 A solução IP-PABX TrixBox está disponível em http://www.trixbox.org/. Acesso em 11/10/2009.
  32. 32. 31 os dados SIP, contêm dentro dela dados do protocolo SDP (Session Description Protocol), definido na RFC 2327. Por meio dos dados incluídos no SDP, é pos- sível identificar todos os dados da sessão, tais como: número de porta de origem e destino para a transmissão RTP, codec utilizado, tipo de sessão (voz ou vídeo), e informações de cada um dos componentes da sessão. 2. ACK: enviada pelo cliente para confirmar que ele recebeu uma resposta final do servidor, como por exemplo: 200 OK; 3. OPTIONS: é enviada de um cliente para o servidor para verificar suas capacidades. O servidor, por sua vez, envia de volta uma lista com os métodos que ele suporta; 4. BYE: enviada por algum dos clientes para para interromper ou encerrar uma chamada; 5. CANCEL: enviada para interromper uma mensagem enviada anteriormente en- quanto o servidor ainda não tiver enviado uma resposta final; 6. REGISTER: clientes podem registrar sua localização atual com esse pedido. Um servidor SIP que aceita esta mensagem é denominado Registrar. Com esta men- sagem é possível adicionar, remover e pesquisar associações de clientes, com suas respectivas localizações (ROSENBERG et al., 2002). Ao trocar mensagens, as respostas são identificadas por números, que identificam a classe da resposta. As respostas estão divididas em 6 categorias (para mais informações consultar Douskalis (2000)): 1. Classe 1xx: mensagens informativas; 2. Classe 2xx: sucesso; 3. Classe 3xx: redirecionamento; 4. Classe 4xx: erros do cliente; 5. Classe 5xx: erros do servidor; 6. Classe 6xx: falhas globais.
  33. 33. 32 O ambiente no qual é executado o protocolo SIP é dotado de duas entidades físicas: o cliente e o servidor. O cliente é conhecido como User Agent, e o servidor possui diversas funções distintas: Proxy, Redirect, Registrar e Gateway server. Na figura 2.3 é possível observar cada uma destas funções numa rede. Estas funções são explicadas nas próximas seções, conforme Rosenberg et al. (2002) e Lima (2006). Figura 2.3: Funções das entidades numa rede SIP. 2.3.1 User Agent O UA (User Agent) é o ponto final da comunicação, o usuário final. Existem ainda duas subdivisões: o UA Client (UAC) e UA Server (UAS). O UAC é a entidade lógica que cria uma nova requisição de comunicação. Este papel é mantido apenas enquanto durar a transação. O papel não é mantido ao longo de toda a sessão, pois se uma aplicação inicia uma requisição ela é mantida como UAC desta transação. Se, durante a sessão receber uma requisição, a outra parte será o UAC desta transação. Em contrapartida, o UAS é a entidade lógica que gera uma resposta para uma requi-
  34. 34. 33 sição SIP. A resposta aceita, rejeita ou redireciona a requisição. Da mesma maneira que o UAC, este papel é mantido apenas enquanto durar a transação. 2.3.2 Proxy Server Tem como função redirecionar requisições e respostas SIP. Ele age como uma enti- dade intermediária que atua como ambos cliente e servidor no âmbito de realizar requi- sições como se fosse outros clientes. Ele atua como se fosse um roteador, recebendo uma requisição de sessão de um UA, e consultando o registrar server para descobrir infor- mações do UA de destino. Se o UA de destino estiver no mesmo domínio, a requisição de sessão é enviada diretamente para o UA, caso contrário é enviado para o proxy server do domínio em questão. O proxy server interpreta, e se julgar ser necessário, reescreve a mensagem de requi- sição antes de encaminhá-la. É utilizado muitas vezes para aplicar políticas de restrição sob os UAs. 2.3.3 Redirect Server O redirect server é um UAS que ao receber mensagens do tipo INVITE gera respostas de classe 3xx, com um novo endereço SIP. Este servidor responde as requisições com um novo endereço, mas não faz o papel de continuar a chamada, como no caso do proxy server. Pode ser usado em conjunto com um registrar server, redirecionando chamadas para a localização atual do originador da chamada (RIBEIRO; RODRIGUES; MARCON- DES, 2001). 2.3.4 Registrar Server Este servidor aceita as requisições do tipo REGISTER e coloca as informações rece- bidas do usuário em algum servidor de localização. Os registrar servers são necessários para manter a informação de localização atual de um usuário. O endereço IP de um usuário pode ser alterado por alguma circunstância, como por exemplo, uma conexão de acesso à Internet que forneça ao cliente um endereço IP dinâmico. Para se manter este registro, estas mensagens são trocadas periodicamente entre o UA
  35. 35. 34 e o registrar. Se um UA se mover na rede e deseja negociar novos parâmetros do registro, ele pode cancelar um registro existente e enviar um novo, conforme Douskalis (2000). 2.3.5 Gateway Server O gateway faz a interconexão entre redes SIP e redes que não utilizam este protocolo, como por exemplo, uma rede VoIP com outro protocolo de sinalização, ou uma rede de telefonia comutada (PSTN). Este dispositivo realiza funções de tradução da sinalização utilizada para o estabelec- imento e término de chamadas e a conversão do formato da mídia de uma rede para outra. As chamadas podem ser destinada a telefones tradicionais ou a dispositivos SIP, mas o gateway deve saber como encaminhá-las. A aplicação Asterisk é um exemplo de um gateway server. 2.4 Protocolos de Transporte Para se transmitir dados de uma rede para outra, seja ela qual for, é necessário que estes dados sejam encapsulados com diversos cabeçalhos, partindo da camada física até a camada de aplicação. A quarta camada do modelo TCP/IP, a camada de transporte, prevê a comunicação lógica entre processos de aplicação que rodam em hospedeiros diferentes, conforme Kurose e Ross (2006). Neste contexto, como este trabalho está lidando com aplicações live streaming, que são sensíveis principalmente ao atraso e às perdas de pa- cotes, surge a necessidade de utilizar o protocolo RTP, que tem como principal função agir como uma interface entre aplicações em tempo real e os protocolos da camada de transporte. Os dois protocolos que estão disponíveis na camada de transporte são o TCP, definido na RFC 793 e o UDP, definido na RFC 768. O protocolo TCP é o protocolo mais utilizado na Internet (LIMA, 2006). Este proto- colo foi criado com o objetivo de garantir a entrega dos pacotes, por isso cada pacote tran- sitado pelo TCP deve receber a confirmação do recebimento, na terminologia, o acknowl- edge (ACK) (mais detalhes em Agency (1981b)). Como numa transmissão em tempo real, se um pacote é perdido ou corrompido, a sua retransmissão não seria necessária (o pacote seria relevante apenas no instante de tempo que passou), o protocolo TCP causaria
  36. 36. 35 um overhead de informações na rede. Além disso, o TCP não suporta a entrega de pa- cotes via multicast (entrega de um para muitos). Para maiores informações a respeito de multicast, consultar Stewart e Gough (2008). Por fim, o TCP não fornece informações, nem estatísticas da transmissão que possam ser analisadas para verificar a qualidade da transmissão. O protocolo UDP também é bastante utilizado na Internet, e foi criado com o objetivo de ser simples. Este protocolo não é orientado à conexão, logo os pacotes perdidos ou corrompidos no meio do caminho não são reenviados. Outra característica do UDP é que os pacotes (segmentos no contexto da camada de transporte) não possuem qualquer informação temporal nem número de sequência. Diferentemente do TCP, o UDP não causa nenhum atraso pré-transmissão, pois como é não orientado à conexão não utiliza a técnica de apresentação de três mensagens que possui o TCP (three way handshake). A grande maioria das aplicações live streaming utiliza os protocolos RTP/RTCP/UDP, pois o UDP gera menos overhead na comunicação (LIMA, 2006). Os protocolos RTP e RTCP serão abordados nas próximas seções. 2.4.1 Real-time Transport Protocol (RTP) O protocolo RTP permite o transporte fim-a-fim de aplicações que transmitam dados em tempo real, como áudio e vídeo, por meio de multicast ou unicast. Este protocolo não garante a qualidade do serviço (QoS) para transmissões em tempo real, por isso funciona em conjunto com o RTCP que permite monitorar a entrega, gerar estatísticas dos dados, e identificar os usuários que os recebem - numa rede multicast - proporcionando dados para o administrador analisar e realizar uma melhora no serviço. Uma maneira para se garantir a QoS é: (1) aplicar a marcação expedite forwarding no byte ToS (type of service), contido no pacote IP e (2) permitir que este tráfego flua dentro de uma fila de prioridade nos roteadores que estiverem intermediando esta transmissão. Para mais informações sobre QoS e filas de prioridades ver Ranjbar (2007). Este protocolo foi idealizado por Henning Schulzrinne e teve sua especificação inicial submetida pela IETF em 1996, como a RFC 1889. Após diversas modificações, princi- palmente na maneira que era calculado o jitter e o tempo de envio dos pacotes RTCP
  37. 37. 36 (SCHULZRINNE et al., 2003), em 2003, o IETF submeteu a nova especificação RFC 3550. O RTP é específico para o tráfego de dados, deixando a cargo do RTCP estatísticas das informações. Mas, o RTP possui informações atreladas ao pacote, tais como: timestamp, número de sequência, descrição dos dados e identificação global. O pacote RTP pode ser visto na figura 2.4 5 . Como o RTP roda sob o UDP, não é possível garantir a entrega das informações sem erro. Portanto, os protocolos das camadas inferiores devem prover este serviço, os quais, encapsulam os dados RTP (DOUSKALIS, 2000). A negociação das portas associadas ao RTP é feita dinamicamente pelo protocolo de sinalização, mas, tradicionalmente, à porta RTP é atribuído um número par e, a porta RTCP recebe o próximo valor (SCHULZRINNE et al., 2003). Se a porta RTP fosse de número 8000, a RTCP seria 8001. Figura 2.4: O pacote RTP. 2.4.2 RTP Control Protocol (RTCP) O RTCP, também especificado na RFC 3550, é responsável pelo controle da transmis- são de dados em tempo real por meio do protocolo RTP. Este protocolo complementa o RTP nas suas funcionalidades, permitindo aos hosts participantes da transmissão receber relatórios de como os dados estão sendo recebidos em termos quantitativos. Desde a sua idealização na RFC 1889, este protocolo sofreu duas principais modifi- 5 Figura extraida de: http://java.sun.com/javase/technologies/desktop/media /jmf/2.1.1/guide/images/RTPRealTime2.gif. Acesso em 12/10/2009.
  38. 38. 37 cações. A primeira modificação aconteceu no instante de tempo em que os pacotes RTCP são enviados. No modelo original, o tempo de envio não era otimizado, causando um overhead de pacotes RTCP quando existiam mais integrantes na transmissão. A segunda modificação aconteceu na fórmula que calcula o jitter dos pacotes. Como o jitter é um dado complexo de ser calculado, a equação foi aperfeiçoada possibilitando uma melhor exatidão no resultado. Este protocolo é baseado no envio periódico de pacotes de controle para todos os participantes da sessão, utilizando o mesmo mecanismo de comunicação dos dados. O protocolo da camada inferior (UDP) é responsável por fornecer a multiplexação dos dados e dos pacotes de controle, utilizando números de portas diferentes (LIMA, 2006). As quatro principais funções do protocolo de controle RTCP, conforme Schulzrinne et al. (2003) são: 1. Obter feedback da qualidade da transmissão de dados. Como o protocolo RTP é comumente utilizado para transmissões live streaming, que são sensíveis a muitas variáveis, esta função é vital para obter um nível mínimo de qualidade na trans- missão. Esta função de feedback é proporcionada pelos sender e receiver reports, discutidos nas próximas seções. O presente trabalho analisa estas mensagens e re- aliza cálculos para se obter um feedback visual. 2. Portar identificação persistente. Os pacotes RTCP carregam uma identificação persistente ao nível de tranporte chamada de CNAME (canonical name). Enquanto que o identificador de fonte de sincronização (SSRC) pode mudar, devido à falhas de software ou de conexão, o CNAME deverá ser o mesmo ao longo de toda uma sessão. 3. Enviar pacotes RTCP. Para que as duas funções anteriores possam funcionar, é necessário que cada um dos participantes da sessão enviem pacotes RTCP. Mas, para que o sistema possa acomodar crescimento em grandes escalas, é necessário que esta taxa seja controlada. Como cada um dos participantes envia seus pacotes RTCP, eles também recebem e podem saber o número de participantes na sessão. Este valor é utilizado para se calcular o tempo de envio de cada pacote RTCP. 4. (Opcional) Controle dos participantes da sessão. A RFC 3550 ainda cita a cober-
  39. 39. 38 tura mínima de uma sessão, como o descobrimento do nome dos participantes, con- forme entram e saem. Esta função seria interessante numa audioconferência na qual não se tem controle da entrada dos participantes. Este passo é opcional, pois é necessário ter um protocolo na camada superior a esta. A especificação (SCHULZRINNE et al., 2003) define cinco tipos de pacotes RTCP: 1. SR (Sender report): responsável pelo envio e recebimento de estatísticas rela- cionadas à transmissão de cada um dos participantes são emissores ativos. Este pacote é analisado pelo presente trabalho para coletar as estatísticas, e é possível visualizá-lo na figura 2.5 6 . Neste pacote, é apresentado uma das informações cru- ciais para a análise da aplicação, o campo fraction lost. Este campo apresenta o valor de perda de pacotes relativo com base de 256, ao invés de 100. Isto ocorre, pois é dedicado um byte para o armazenamento desta informação. 2. RR (Receiver report): responsável pela recepção de estatísticas relacionadas à transmissão de cada um dos participantes que não são emissores ativos. É possível visualizar este pacote na figura 2.6 7 . 3. SDES (Source Description): pacotes compostos de zero ou mais blocos, sendo que cada bloco é preenchido pelos itens que o definem. Estes itens incluem o identifi- cador SSRC, e itens de descrição, incluindo o CNAME. 4. BYE: indica o fim da sessão. 5. APP: realiza funções específicas de alguma aplicação que o implemente. O fluxo de pacotes RTCP, não deve exceder 5% da largura de banda dedicada para as transmissões live streaming. Para isso, é aplicado um algoritmo determinístico para cal- cular o tempo de envio dos pacotes RTCP. Para maiores informações sobre como calcular o tempo de envio, consultar Schulzrinne et al. (2003). 6 Figura extraida de: https://prof.hti.bfh.ch/myf1/www/projects/polyphem/www /docu- ments/images/rtcp_sr_header.jpg. Acesso em 13/10/2009. 7 Figura extraida de: https://prof.hti.bfh.ch/myf1/www/projects/polyphem/www /docu- ments/images/rtcp_rr_header.jpg. Acesso em 13/10/2009.
  40. 40. 39 Figura 2.5: O tipo de pacote sender report, do protocolo RTCP. 2.5 Protocolo para Feedback : ICMP O ICMP, especificado na RFC 792, é um protocolo criado para ser rodado em todos os hosts e roteadores para comunicar informações da camada de rede. Este protocolo é considerado parte integrando do protocolo IP, mas ao analisar sua arquitetura, é possível verificar que este é encapsulado pelo IP, conforme Kurose e Ross (2006). Em 1981, este protocolo foi especificado pelo DARPA (AGENCY, 1981a) como parte integrante do IP, pois permitia o fornecimento de feedback da conectividade IP. Ele ape- nas existe, pois uma rede IP não é considerada confiável. Por ser um protocolo de fun- cionamento bastante simplificado, evoluiu apenas com extensões, mas sua especificação original se manteve intacta ao longo de quase 30 anos. Este protocolo atua enviando mensagens de um emissor para um receptor, sendo que este receptor deve enviar uma resposta, se for tiver conectividade. No cabeçalho desta mensagem além dos dados do protocolo IP, estão disponíveis o tipo e o código da men- sagem. Existe uma grande combinação de tipos e códigos de mensagem para ser utilizado, portanto na tabela 2.1 é apresentado os tipos mais comuns. Para ver todos os tipos, con-
  41. 41. 40 Figura 2.6: O tipo de pacote receiver report, do protocolo RTCP. sulte a especificação do protocolo ICMP, Agency (1981a). Existem duas aplicações bastante difundidas que utilizam o ICMP como base, o Ping e o Traceroute. O Ping é uma aplicação em que é possível se verificar a conectividade da rede. Além disso, é possível mensurar o tempo em que o pacote demora para ir e voltar ao host de destino, desprezando-se perdas decorrentes de processamento do host e atraso da propa- gação elétrica. Esta aplicação funciona enviando para um receptor um pacote contendo um tipo de mensagem 8 (solicitação de eco) e código 0. O pacote trafega ao longo da rede, e ao chegar no host de destino, ele desencapsula o pacote, verifica a mensagem e envia uma outra mensagem contendo ambos tipos e códigos da mensagem com o valor 0 para o emissor original. Se fosse contado o tempo que o pacote levou para ir e voltar para o host que enviou a solicitação de eco, seria possível mensurar o atraso de ida e volta dos pacotes, ou o round-trip delay. Da mesma forma que o Ping utiliza o ICMP, o Traceroute também o utiliza para de- scobrir o caminho que um pacote percorre para se atingir um destino e o tempo decorrente. Para descobrir estes dados, um roteador de origem envia para o primeiro roteador um pa- cote ICMP com TTL (time to live) 1, para o segundo roteador um pacote ICMP com TTL 2, e assim sucessivamente até o enésimo roteador. Além disso, é executado tem- porizadores para cada um destes pacotes. Quando o enésimo pacote chega ao enésimo
  42. 42. 41 Tipo de mensagem ICMP Código Descrição 0 0 resposta de eco 3 0 rede de destino inalcançável 3 1 host de dedestino inalcançável 3 2 protocolo de destino inalcançável 3 3 porta de destino inalcançável 3 6 rede de destino desconhecida 3 7 host de destino desconhecido 4 0 redução da fonte (controle de congestionamento) 8 0 solicitação de eco 9 0 anúncio do roteador 10 0 descoberta do roteador 11 0 TTL expirado 12 0 cabeçalho IP inválido Tabela 2.1: Tipos de mensagem e códigos ICMP associados com a descrição. roteador, este roteador verifica que o TTL expirou, e seguindo as regras do protocolo IP, o roteador descarta o pacote e responde a mensagem com uma mensagem ICMP de TTL expirado, ou tipo de mensagem 11, código 0. Esta mensagem inclui o nome do roteador e seu endereço IP. Quando esta mensagem chegar ao emissor ele poderá parar o tempo- rizador, obter o tempo que levou para cada um destes pacotes ir e voltar até os enésimos roteadores, e obter o nome de cada um deles (KUROSE; ROSS, 2006). Os protocolos de rede apresentados até esta seção foram utilizados na definição das técnicas de medição das métricas de desempenho de QoS. No entanto, para conceber o protótipo são necessárias técnicas de engenharia de software. Neste contexto, surge a necessidade de se utilizar o padrão de arquitetura MVC, que será apresentado na próxima seção. 2.6 Padrão de Arquitetura: MVC O padrão Model View Controller, mais conhecido como MVC, é um padrão de ar- quitetura utilizado para se desassociar a lógica do negócio, o acesso aos dados, e a apre-
  43. 43. 42 sentação e interação do usuário. Com o MVC é possível aliar um desenvolvimento ágil com um baixo acoplamento, isolando a lógica do modelo visual, e realizando a interco- municação por meio do controlador. (MICROSYSTEMS, 2008). Originalmente, este padrão surgiu para a linguagem de programação SmallTalk, que é uma linguagem de programação puramente orientada à objetos. Para mais informações sobre o SmallTalk e orientação à objetos ver LaLonde (2008). O autor pioneiro que realizou a implementação no SmallTalk foi Trygve Reenskaug. Devido a aprovação que teve este padrão, hoje em dia é um dos mais conhecidos para organização de arquitetura para sistemas interativos (BUSCHMANN et al., 1996). Atualmente, este padrão para a engenharia de software é utilizado em linguagens baseadas no paradigma orientado à objetos, pois aplicações que contém os códigos de acesso à dados, códigos da lógica do negócio e códigos de apresentação misturados, são difíceis de manter. O problema existe, pois a interdependência entre os componentes causa um forte efeito ripple, portanto uma pequena mudança no código pode afetar toda a aplicação. O alto acoplamento torna quase impossível a reutilização dos componentes, pois eles dependem uns dos outros (MICROSYSTEMS, 2008). Ao utilizar este padrão, é possível criar diferentes visualizações sem afetar a integridade dos dados, como é possível visualizar na figura 2.7. Figura 2.7: Apresentação de diversas visualizações possíveis por causa do MVC, sem alterar a integridade dos dados de negócio (BUSCHMANN et al., 1996). O papel de cada uma das partes da modelagem é apresentado nos itens a seguir, con- forme MicroSystems (2008):
  44. 44. 43 1. Model: Representa os dados da corporação e as regras de negócios. Muitas vezes, serve como uma aproximação do software com o processo do mundo real. 2. View: Renderiza o conteúdo de um modelo (Model). Esta parte acessa os dados por meio de um modelo e especifica como estes dados deverão ser apresentados. Também, é responsabilidade do View manter a consistência na apresentação quando os dados forem alterados. 3. Controller: Traduz as interações do View em ações para ser efetuadas no Model. Numa interface gráfica, interações poderiam ser clicks e numa aplicação Web pode- riam ser requisições. Com base nas interações do usuário e no resultado das ações é responsabilidade do Controller apresentar a View correta. A figura 2.8 apresenta visualmente o papel das partes e seus relacionamentos. Figura 2.8: Diagrama contendo os relacionamentos e papéis de cada uma das partes que compõem o padrão MVC (MICROSYSTEMS, 2008). O protótipo da aplicação utilizará como base este padrão de arquitetura para a mode- lagem do sistema.
  45. 45. 44 2.7 Síntese do capítulo Neste capítulo foram abordados os conceitos necessários para o desenvolvimento do protótipo. Primeiro, foi apresentado que streaming e live streaming são conceitos de transmissão de dados. Então, foi apresentado os fatores que influenciam nas transmissões live streaming (atraso, jitter, perda de pacotes e largura de banda), e constatado que as transmissões em tempo real possuem limiares que não podem ser ultrapassados para não terem perdas perceptíveis em sua qualidade: 150 ms para atraso unidirecional, 30 ms para jitter, 5 % para perda de pacotes e largura de banda para comportar as informações da transmissão que trafegam no enlace. Na próxima seção, foi abordado o protocolo SIP, seu funcionamento, as mensagens importantes no estabelecimento da sessão relevantes para este trabalho (SIP INVITE e SIP BYE) e as funções dos dispositivos SIP numa rede. Em seguida, foi apresentado os protocolos de transporte RTP e RTCP, que realizam a transmissão e seu controle. Com relação ao protocolo RTCP, destaca-se a mensagem sender report que consta o campo fraction lost, utilizado para se obter a perda de pacotes. Na seção seguinte, foi apresentado o protocolo ICMP que foi utilizado para se descobrir o atraso de ida e volta. Por fim, foi abordado o padrão de arquitetura MVC, que permitiu isolar a lógica da visualização, permitindo um baixo acoplamento no desenvolvimento. No próximo capítulo será abordada a metodologia que foi seguida para a conclusão deste trabalho.
  46. 46. 45 3 METODOLOGIA DE DESENVOLVIMENTO Neste capítulo são abordadas as etapas necessárias para o desenvolvimento do pro- tótipo. A metodologia deste trabalho foi constituída em 5 (cinco) etapas: ambiente de de- senvolvimento, requisitos, técnicas, modelagem e implementação. Foi organizada desta maneira, pois permite isolar cada um dos passos metodológicos por áreas de criação. Na primeira seção é descrito o ambiente no qual foi utilizado em todo decorrer da metodologia. Em seguida, alinhado aos objetivos e a idealização do protótipo são de- scritos os requisitos. Na próxima seção, são propostas as técnicas de obtenção das métri- cas de desempenho de QoS. Então, é feita a modelagem do protótipo com base no padrão MVC. Por fim, com base nos pacotes e classes criados na modelagem, o protótipo é im- plementado e codificado. 3.1 Ambiente de Desenvolvimento Para suportar todas as etapas da metodologia, foi necessário estabelecer um ambiente de desenvolvimento. Nesta seção é descrito as partes que compõem este ambiente: as ferramentas para desenvolvimento e os dispositivos físicos numa rede. 3.1.1 Ferramentas A utilização do padrão de arquitetura MVC na concepção do protótipo, e a utilização 1 da linguagem de programação Java permitiu o uso de ferramentas para programação 1 O Java é uma inguagem de programação orientada à objetos criada pela Sun Microsystems. Mais informações: http://java.sun.com/. Acesso em 26/11/2009.
  47. 47. 46 orientada à objetos. Por meio de duas ferramentas foi possível desenvolver a parte lógica e a parte gráfica do protótipo. A lógica do protótipo foi criada com a ferramenta Eclipse 2 , enquanto que a parte gráfica foi concebida com a NetBeans 3 . A utilização da ferramenta NetBeans facilitou na criação das interfaces gráficas, pois é possível conceber a interface visualmente. Após sua criação, o código fonte gerado era copiado para a ferramenta Eclipse permitindo a integração com a lógica do protótipo. Esse desenvolvimento segmentado foi possível pela utilização do padrão MVC, isolando a parte lógica da gráfica. Além das ferramentas Eclipse e NetBeans, foram utilizadas duas bibliotecas de pro- 4 gramação para Java: JpCap e JFreeChart 5 . A JpCap é uma biblioteca que permite a captura e o envio de quadros e pacotes de rede, enquanto que a JFreeChart, é uma bib- lioteca, que permite a criação, geração e atualização de diferentes tipos de gráfico em tempo real. 3.1.2 Dispositivos Para se desenvolver o protótipo, além das ferramentas, foram utilizados dispositi- vos de rede. O propósito destes dispositivos foi simular a execução de uma aplicação live streaming. Uma aplicação VoIP foi escolhida em função de sua crescente utilização por parte de usuários domésticos e corporativos. Além disso, a existência de farta doc- umentação e aplicativos VoIP gratuitos também contribuiu para a escolha desse tipo de aplicação (transporte de voz digital). Neste ambiente foram utilizados 03 (três) hosts físicos interconectados por um switch. Foram utilizadas duas estações de trabalho, que executaram softphones, um servidor que 2 O Eclipse além de uma ferramenta é toda uma comunidade que visa a criação de plataformas de código- aberto para todo ciclo de vida do software. Ela esta disponível em http://www.eclipse.org. Acesso em 26/11/2009. 3 Criada pela Sun MicroSystems, o NetBeans é uma plataforma para desenvolvimento em Java que pos- sui bastante funcionalidade para criação de aplicações gráficas. Disponível em: http://www.netbeans.org. Acesso em 26/11/2009. 4 A biblioteca JpCap, para captura e envio de pacotes, é disponibilizada gratuitamente em: http://netresearch.ics.uci.edu/kfujii/ jpcap/doc/index.html. Acesso em 23/10/2009. 5 A biblioteca JFreeChart, para criação de gráficos, pode ser obtida gratuitamente em: http://www.jfree.org/jfreechart/. Acesso em 23/10/2009.
  48. 48. 47 executou o gateway server Asterisk e um switch. A topologia de redes utilizada é apre- sentada na figura 3.1. Figura 3.1: Diagrama da topologia de redes utilizada para o ambiente de pré- teste. Na figura 3.1, é possível verificar que cada máquina recebeu um identificador numérico. Orientado por estes identificadores, nas próximas seções é apresentado as especificações de hardware e software de cada uma das máquinas. 3.1.2.1 Máquina 1 Esta máquina atuou como uma estação de trabalho comum, atendendo às ligações feitas pela máquina 3. Nela foi instalado um softphone convencional que permitisse, unicamente, receber chamadas VoIP. 1. Especificações de hardware: (a) Processador: Intel Pentium 4 HT, 3.0 Ghz; (b) Memória RAM: 512 MB; (c) Armazenamento: 160 Gb; (d) Rede: Ethernet 100 Mbps. 2. Especificações de software: (a) Sistema Operacional: Windows XP SP2 32 bits; (b) Softphone instalado: SJPhone 1.60 6 . 6 A aplicação SJPhone possui uma versão grátis para Windows, disponível no endereço: http://www.sjlabs.com/sjp.html. Acesso em 08/10/2009.
  49. 49. 48 3.1.2.2 Máquina 2 Esta máquina foi responsável por executar o gateway server para as ligações VoIP, por meio da aplicação Asterisk. Este dispositivo fez a sinalização via protocolo SIP para as outras duas estações. Foi utilizado uma solução que instala um servidor PBX-IP com- pleto, simplificando a tarefa de instalação e configuração. 1. Especificações de hardware: (a) Processador: Intel Pentium 3, 1.1 Ghz; (b) Memória RAM: 512 MB; (c) Armazenamento: 20 Gb; (d) Rede: Ethernet 100 Mbps. 2. Especificações de software: (a) Sistema Operacional: CentOS 5.3 Final 32 bits; (b) Aplicação instalada: Solução TrixBox 2.6.18 que roda Asterisk 1.4.17. 3.1.2.3 Máquina 3 Essa máquina foi responsável por originar as ligações VoIP para a máquina 1. Além disso, ela foi utilizada para coletar os pacotes transmitidos através do uso de uma fer- ramenta específica para esse fim. A fim de tornar possível essa operação, a interface Ethernet dessa máquina teve que ser colocada em modo promíscuo 7 . 1. Especificações de hardware: (a) Processador: Intel Core 2 Duo, 1.8 Ghz; (b) Memória RAM: 2 GB; (c) Armazenamento: 100 Gb; 7 O modo promíscuo é um tipo de configuração de recepção na qual todos os pacotes que trafeguem pelo segmente de rede que a estação está conectada são capturados. Em funcionamento normal, ela receberia apenas os pacotes endereçados a ela, mas em ambiente onde são utilizados repetidores e hubs é possível utilizar o modo promíscuo para capturar dados (KUROSE; ROSS, 2006)
  50. 50. 49 (d) Rede: Ethernet 100 Mbps. 2. Especificações de software: (a) Sistema Operacional: Windows Vista Ultimate 32 bits; (b) Softphone instalado: SJPhone 1.60. (c) Ferramenta de captura e análise de dados instalada: WireShark 1.2.2 8 . 3.2 Requisitos Para conceber o protótipo, foi necessário mapear as funcionalidades que deveriam estar presentes. Tanto as funcionalidades funcionais quanto as não-funcionais deveriam ser pontuadas, não deixando nada em aberto, ou implícito. Após a seção da proposta de técnicas para medição das métricas de desempenho, é feita uma análise dos requisitos, modelando-os de forma a constituir o protótipo. Os requisitos foram mapeados por meio dos objetivos do trabalho. Foram acompan- hados de identificadores permitindo o apontamento à eles nas futuras seções do trabalho. Eles são apresentados a seguir. 1. REQ01: Permitir a escolha de uma interface de rede a ser monitorada. 2. REQ02: Detectar automaticamente o início e o fim do tráfego live streaming RTP. 3. REQ03: Suportar pelo menos o protocolo de sinalização SIP. 4. REQ04: Monitorar os fatores que afetam as transmissões live streaming: largura de banda, atraso, perda de pacotes e jitter. 5. REQ05: Monitorar cada stream em uma tela. 6. REQ06: Monitorar em tempo real o tráfego. 7. REQ07: Apresentar os dados monitorados por meio de gráficos. 8. REQ08: Persistir os dados em disco em forma de log. 8 A ferramenta WireShark é livre, e ela pode ser obtida no endereço: http://www.wireshark.org/. Acesso em 20/10/2009.
  51. 51. 50 9. REQ09: A topologia da rede não deve ser alterada para que funcione a ferramenta. 3.3 Técnicas Para se desenvolver técnicas de medição para as métricas de desempenho de QoS, foi necessário: (1) realizar uma captura de pacotes no ambiente de desenvolvimento, (2) analisar os dados capturados identificando certos eventos ou atributos e (3) propor as técnicas. A simulação feita, para que fosse capturado os pacotes necessários, foi proposta da seguinte maneira. 1. Foi iniciada a ferramenta de captura de pacotes; 2. Foi feita uma tentativa de ligação VoIP partindo do dispositivo 3 para o 1; 3. O dispositivo 2 fez o intermédio desta tentativa, por meio da aplicação Asterisk. Nesta etapa o softphone do dispositivo 1 começa a tocar; 4. No momento em que o dispositivo 1 atendeu a ligação, foi enviada uma mensagem SIP para que uma sessão fosse estabelecida; 5. A transmissão live streaming RTP foi iniciada; 6. Foram capturados pacotes SIP, RTP, RTCP ao longo de 30 segundos, por meio da ferramenta WireShark; 7. Após 30 segundos, o dispositivo 3 finalizou a comunicação. Consequentemente, o dispositivo 3 enviou uma mensagem SIP que corresponde ao término da sessão; 8. O dispositivo 1 ao receber mensagem, enviou um acknowledge e a transmissão finalizou; 9. A ferramenta WireShark foi parada; 10. Os dados gerados por esta ferramenta foram analisados. Nestes 30 segundos capturados, a ferramenta capturou mais de 3.000 (três mil) pa- cotes. Seria inviável analisar um a um, portanto foi buscado analisar pacotes que possuam
  52. 52. 51 algum atributo específico, ou tenham relação com algum evento de rede. Esta análise bus- cou pacotes que fossem relevantes para a criação das técnicas de medição e para a lógica do protótipo. Cada um dos eventos e atributos buscado analisar são apresentados a seguir. 1. Protocolo SIP: Por meio deste protocolo, foi possível obter dados relacionados à sessão estabelecida entre as partes da transmissão. Foram buscadas as mensagens e parâmetros que contivessem o início, término e identificação das sessões. (a) Início da transmissão: Quando um pacote com o tipo de mensagem INVITE era enviado, verificou-se o fluxo de informações que precede o início de uma transmissão live streaming. A mensagem que identifica o início da transmis- são, além de ser do tipo SIP INVITE, possui ainda dados do protocolo SDP, que identifica o início de uma sessão. Esta mensagem identifica o início da sessão, possibilitando a obtenção de dados de porta em que é iniciada a trans- missão live streaming, via protocolo RTP; e do identificador da sessão. (b) Identificação de sessões: No item anterior, foi mencionada a mensagem na qual deve ser monitorada, de modo a obter o identificador da sessão. Toda sessão possui um identificador único gerado com base num identificador randômico de criptografia (ROSENBERG et al., 2002). Este campo é o mesmo em todos os pacotes de manutenção de uma sessão SIP. O nome deste campo no pacote SIP é Call-ID. (c) Fim da transmissão: Da mesma forma que o protótipo precisa saber o início e o identificador da sessão, também é necessário descobrir quando uma trans- missão é finalizada. Desta forma, o tipo de mensagem SIP BYE foi analisado. 2. Protocolo RTCP: Este protocolo apresenta dados de controle da transmissão, porém foi analisado apenas um relatório contido nesta mensagem, o sender report. O campo analisado foi o da taxa de perdas de pacotes. (a) Taxa de perdas de pacotes: Valor que expressa a taxa na qual pacotes estão sendo perdidos na rede. Este valor é expresso em porcentagem, mas não como base 100, e sim base 256. Para obtenção, foi analisado o campo fraction loss. 3. Protocolo RTP: O protocolo RTP realiza o transporte dos dados da transmissão
  53. 53. 52 live streaming. Portanto, o único dado que foi monitorado é o tamanho dos pacotes da transmissão. (a) Tamanho de cada pacote para contabilização: Como no pacote RTP trafegam dados de transmissão, a única análise feita neste protocolo foi da quantidade de banda que cada fluxo em tempo real está ocupando do enlace em termos bytes/segundo. As transmissões são isoladas umas das outras, pois são multi- plexadas em portas UDP distintas. Na seção 2.2, foram analisados os quatro fatores que influenciam as transmissões em tempo real (largura de banda disponível, perda de pacotes, atraso, e buffer de com- pensação de jitter). Como um dos objetivos deste trabalho é medir os atributos de de- sempenho de uma transmissão em tempo real, com base nas variáveis identificadas nos itens anterior, foram propostas técnicas para que sejam coletadas métricas de desempenho de QoS. No contexto deste trabalho, cada um destes fatores recebeu, respectivamente, o nome: tráfego RTP, perda de pacotes, atraso e jitter. O método utilizado para a medição de cada uma das métricas de desempenho é apre- sentado apresentado nas seções seguintes. 3.3.1 Tráfego RTP O objetivo da monitoração do tráfego RTP foi obter a largura de banda utilizada pela transmissão live streaming RTP por segundo. Para isso, foram contabilizados os pacotes RTP e RTCP. A unidade desta medida é bytes/segundo. A técnica proposta é apresentado a seguir. 1. Captura pacote da rede. 2. Verifica se o pacote é RTP ou RTCP. 3. Se sim, identifica qual transmissão está trafegando o pacote. Isto é feito identifi- cando a porta UDP. Quando é trafegado o pacote SIP INVITE, é obtida a porta na qual é trafegada a transmissão, conforme seção 2.3. 4. Obtém o tamanho do pacote.
  54. 54. 53 5. Incrementa e/ou armazena o valor do tamanho do pacote. Apenas é armazenado o valor na primeira execução. Nas execuções subsequentes, é incrementado o valor da execução anterior com o valor atual. 6. Quando for o instante de tempo de obtenção da medida, aplica o seguinte algoritmo: (a) Atribui: ContagemNova = ContadorDePacotes; (b) Atribui: Resultado = (ContagemNova - ContagemAntiga) / tempoDeAtualiza- ção; (c) Atribui: ContagemAntiga = ContagemNova. 7. Conclui a operação. Por meio deste algoritmo, a largura de banda utilizada por segundo por uma transmis- são live streaming é obtida na variável Resultado. Além disso, este algoritmo é indepen- dente do tempo de obtenção dos dados para serem apresentados (tempoDeAtualização), portanto ao alterar o tempo de amostragem dos gráficos não será alterado o fluxo de exe- cução nem os valores obtidos por esta técnica. 3.3.2 Perda de Pacotes Ao monitorar a perda de pacotes, busca-se obter a taxa na qual os pacotes não con- seguem chegar ao seu destino, relativa ao número total de pacotes passados pela interface. Como esta é uma unidade relativa, ela é medida em porcentagem. Foi monitorada a perda de pacotes apenas nas transmissões live streaming RTP, e não em todo enlace. Este valor foi obtido ao monitorar os pacotes RTCP e verificar o campo fraction lost. Como este campo é composto de 1 byte, pode possuir 256 valores. Portanto, foi realizado uma con- versão para apresentar este valor como múltiplo de 100. O algoritmo que obtém a taxa de perda de pacotes é apresentado a seguir. 1. Captura pacote da rede. 2. Verifica se o pacote é RTCP. 3. Se sim, busca pelo byte 32 que contém o dado de perdas de pacotes e o atribui à variável PktLoss.
  55. 55. 54 4. Aplica a equação 3.1, convertendo o dado para base 100. 100 P erdaDeP acotes = (3.1) 256 ∗ P ktLoss 5. Conclui a operação. A variável PerdaDePacotes apresenta o valor da perda de pacotes em porcentagem. 3.3.3 Atraso Para se calcular o atraso na entrega, foi necessário utilizar o protocolo ICMP. Este método envia uma requisição e contabiliza o tempo desde que ela sai do emissor até o recebimento de um retorno do receptor. O atraso obtido por meio desta técnica é o de ida e volta, ou round trip time. A unidade do atraso é milissegundos. 1. Inicia a contabilização de tempo. 2. Envia um pacote ICMP com tipo de mensagem 8 e código 0, a requisição de eco. O receptor deve responder com um pacote ICMP contendo um tipo de mensagem e código, ambos 0, indicando uma resposta de eco. 3. Para a contabilização de tempo. 4. Calcula a diferença entre o início da contabilização de tempo e o término. Esta diferença é o tempo em milissegundos que um pacote ICMP levou para ir e voltar do dispositivo emissor até o receptor. Este resultado é atribuído à variável PingResult. 5. Aplica o seguinte algoritmo: (a) Atribui: IcmpAntigo = PingResultAntigo. (b) Atribui: PingResultAntigo = PingResult. (c) Atribui: ResultadoFinal = (PingResultAntigo + ResultadoFinal) / 2 6. Conclui a operação.
  56. 56. 55 Este algoritmo utiliza uma variável a mais, que não seria necessária para este algo- ritmo, porém ela é utilizada para o cálculo do jitter. A variável é IcmpAntigo. Além disso, como este algoritmo foi executado com maior frequência do que a taxa de amostragem dos dados nos gráficos, para se obter o atraso médio e não perder a exatidão na medição foi feita uma média da medição anterior com a atual, o que explica a divisão por 2 (dois) no algoritmo. 3.3.4 Jitter O valor do buffer de compensação de jitter foi obtido por amostragem. Para o cálculo desta métrica de desempenho, foram obtidas 30 amostras. A variação no atraso entre elas, o delta, foi calculado e incrementado. Após as 30 amostras terem sido obtidas, foi feito uma média destes deltas, obtendo o valor de jitter. As amostras utilizadas são as mesmas utilizadas na seção 3.3.3, para o cálculo do atraso na entrega. A unidade desta medição é em milissegundos. O algoritmo completo é apresentado a seguir. 1. Obtém amostra; 2. Incrementa o contador no número de amostras; 3. Verifica a contagem das amostras. Se for equivalente a 30, segue fluxo 3a do algo- ritmo. Caso contrário, segue fluxo 3b. (a) NúmeroDeAmostras = 30; i. Atribui: Delta = | PingResultAntigo - IcmpAntigo |; ii. Atribui: SomaDeDeltas = SomaDeDeltas + Delta; iii. Atribui: Jitter = SomaDeDeltas / NúmeroDeAmostras; iv. Atribui: NumeroDeAmostras = 0; v. Atribui: SomaDeDeltas = 0; vi. Atribui: PingResultAntigo = 0; (b) NúmeroDeAmostras != 30; i. Atribui: Delta = | PingResultAntigo - IcmpAntigo |;
  57. 57. 56 ii. Atribui: SomaDeDeltas = SomaDeDeltas + Delta; iii. Atribui: Incrementa em 1 unidade NumeroDeAmostras; 4. Conclui a operação. A variável Delta possui a diferença entre o RTT dos pacotes ICMP. Mas é na variável Jitter, que é apresentado o resultado do tamanho do buffer de compensação de jitter. 3.4 Modelagem Esta etapa teve como objetivo produzir um modelo de classes que, somado às técnicas produzidas na seção anterior, foi possível realizar a codificação do protótipo na etapa seguinte. Neste trabalho foi modelado e desenvolvido o protótipo seguindo somente o padrão MVC, agilizando todo processo da concepção do protótipo. Como o foco deste trabalho não foi a engenharia de software, e sim a implementação das técnicas propostas medindo os atributos de desempenho de QoS numa rede, a modelagem foi simplificada. Para ver mais sobre modelagem e engenharia de software, consultar Larman (2007). Por utilizar o padrão de arquitetura MVC, a modelagem teve agilidade, facilidade e modularidade. Também por utilizar este padrão, a modelagem foi orientada à objetos, uti- lizando classes. Estas classes possuem lógicas associadas às funcionalidades do protótipo. As classes, suas associações e interconexões resultaram no protótipo. Ao analisar os requisitos, as técnicas criadas para obtenção de métricas de desem- penho, e as bibliotecas utilizadas para a linguagem de programação Java, verificou-se a necessidade de englobar os requisitos em agrupamentos de funcionalidades. Os agrupa- mentos e os requisitos atendidos por cada um deles são apresentados a seguir - foram adicionados identificadores para referenciar os agrupamentos ao longo do trabalho. 1. AF01 - Captura de Pacotes RTP/RTCP e SIP: Neste agrupamento foram incluí- dos todos os protocolos nos quais são capturados pacotes. Como os protocolos RTP e RTCP foram utilizados por duas das técnicas de medição, optou-se por isolá-los como um agrupamento de funcionalidade. Além disso, foi necessário capturar da- dos do protocolo SIP, portanto ele também está incluído neste agrupamento. Os requisitos englobados por este agrupamento são:

×