IPTVProbe da NetUP

Código fonte - iptvprobe_v0.4.tbz2

As questões relativas ao IPTVProbe podem ser debatidas no Fórum de IPTV da NetUP

Changelog

Versão 0.4
• Limpeza periódica da base de dados.
• Monitorização de vários fluxos multicast por sonda.
• Fuga de memória corrigida em iptvprobe_server.
Nota! A base de dados deve ser completamente recreada ao actualizar a partir de versões anteriores.

Versão 0.3
• Processamento e exibição de pedidos IGMP dos parâmetros de IGMP adicionados.
• Limpeza do código, correcção de pequenos erros.
• Protocolo de troca de dados com as sondas actualizado para a nova versão.

Versão 0.2
• Adicionado suporte Aminet 110 (ppc).

Versão 0.1
• Primeira publicação.
• Adicionado controlo de pacotes perdidos.
• Adicionada a apresentação da velocidade de recepção de pacotes UDP.

Esquema de rede

Disposição do funcionamento da sonda (iptvprobe) e do colector

Criação e instalação do software

O software é composto pelos seguintes elementos:

• Colector - recolhe estatísticas a partir das sondas. As estatísticas recolhidas são armazenadas na base de dados (mysql).
• Sonda - é uma aplicação que funciona remotamente. As estatísticas sobre os pacotes IP recebidos são recolhidas pela sonda e enviadas para o colector. A sonda é composta por um módulo de kernel Linux (netup_netprobe.ko) e um software ao nível do utilizador (iptvprobe).
• Sistema secundário de relatórios - é um conjunto de scripts Web para visualização das estatísticas recolhidas.

Criação e execução do colector

Criação do colector:

cd iptvprobe/userver/
cmake --debug-output . -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON
make

Criação da base de dados:

mysqladmin create iptvprobe
mysql iptvprobe < db.sql

Execução do colector:

./iptvprobe_server -l root -s 127.0.0.1

neste exemplo o colector regista as estatísticas na base de dados 'iptvprobe' no anfitrião local (127.0.0.1)

Criação da iptvprobe

Criação da aplicação para a plataforma x86:

cd iptvprobe/udaemon/
cmake --debug-output . -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON
make

Criação do módulo de kernel Linux para a plataforma x86:

cd iptvprobe/kmodule/
make

Criação do módulo de kernel Linux para a plataforma sh4 (IP STB AmiNET 130):

cd iptvprobe/kmodule/
export CROSS_COMPILE=sh4-unknown-linux-gnu-
make ARCH=sh amino130

O directório aminet130_bin/ contém um módulo de kernel Linux já integrado e uma aplicação ao nível do utilizador para AmiNET 130 IP STB.

Execução da sonda

Carregar o módulo de kernel Linux:

cd iptvprobe/kmodule/
insmod netup_netprobe.ko hook_position=0

O parâmetro hook_position especifica a posição de retenção dos pacotes IP do filtro de rede:

0 - processar todos os pacotes IP recebidos (política PREROUTING) 1 - processar todos os pacotes IP transmitidos (política POSTROUTING)

O valor "0" deve ser definido ao executar o módulo no dispositivo de um cliente (por exemplo, IP STB AmiNET 130). No caso de execução do módulo num servidor que envia tráfego multicast, é necessário definir o valor "1".

É necessário para criar um nó no sistema de ficheiros /dev e para executar a aplicação iptvpobe quando o módulo netup_netprobe.ko for carregado com sucesso:

mknod /dev/iptvprobe c 61 0
cd iptvprobe/udaemon/
./iptvprobe -i 224.117.117.10 -s 10.1.4.242 -r 5 -p 7700

Opções da linha de comandos:

-i Define o endereço multicast para monitorização
-s Especifica o endereço IP do colector
-p Especifica a porta do colector para aceitar ligações das sondas
-r Especifica um identificador de execução

É possível encontra um comando totalmente programado no sistema secundário de relatórios.

Sistema secundário de relatórios

De modo a executar o sistema secundário de relatórios, é necessário copiar todos os scripts Web da pasta iptvprobe/report_sys/ para cgi-bin do seu servidor Web:

cd iptvprobe/report_sys/
cp *.pl /var/www/localhost/cgi-bin/

perl e GD devem estar instalados no sistema para um funcionamento correcto.

Escreva o seguinte endereço URL no browser da Web:

http://address/cgi-bin/iptvprobe_runs.pl

Em que "address" é um endereço do seu servidor Web.

A página inicial contém a lista de execuções da sonda:

A coluna "Comando a executar na sonda" contém um comando totalmente programado que deve ser executado na sonda.

A representação gráfica do fluxo multicast pode ser visualizado através das hiperligações "diagrama cronológico UDP" ou "Intervalo de chegada PCR". No diagrama são apresentados aproximadamente os últimos 30 segundos.

Foram efectuadas duas execuções exemplificativas. A primeira execução foi efectuada no AmiNET 130 IP STB ligado através de um switch SOHO simples sem suporte de recepção IGMP. A segunda execução foi efectuada no AmiNET 130 IP STB ligado através de um switch Cisco Catalyst com recepção IGMP. No primeiro caso existem muitas perdas de pacotes IP. O seguinte diagrama ilustra estes dois casos:

Explicação do diagrama

No diagrama são apresentados aproximadamente os últimos 15-30 segundos no eixo x.

Os seguintes parâmetros são apresentados no eixo y:

• Contagem dos pacotes IP agrupados em 100 mseg.
• Número de bytes agrupados em 100 mseg.
• A linha vermelha indica os pacotes IP perdidos. É apresentado um pico no diagrama ser for detectada descontinuidade na "ID do pacote IP". O valor 0 significa que não foi detectada qualquer perda de pacotes.

Descrição da base de dados

Monitorização de IGMP

A partir do iptvprobe v0.3, os pedidos IGMP enviados e recebidos por um STB IP podem ser acompanhados pela sonda. Também são registados os carimbos da hora do último pacote do grupo antes de sair de um grupo e o primeiro pacote após aderir a um grupo. Estes dados podem ser utilizados para avaliar o desempenho do equipamento de rede que processa os pedidos de IGMP e a recepção de IGMP.

Abaixo é apresentado um exemplo desta funcionalidade com o Aminet 130 IP STB para a sonda e o Middleware da NetUP para o colector. Foi utilizado o Cisco Catalyst 3560 como comutador com suporte de recepção IGMP e o Cisco Catalyst C3550-12T funcionou como consultor de IGMP.

Os canais televisivos foram activados no STB IP. De momento, o STB envia um pedido IGMP para sair do grupo de multicast 224.121.0.4 e, em seguida, outro para aderir ao grupo em 224.121.0.3. Estes pedidos são registados pela sonda e apresentados na interface Web juntamente com os carimbos da hora:

Os itens do nosso interesse encontram-se dentro da moldura azul. Torna-se claro que após o pedido de saída do IGMP para o grupo de multicast em 224.121.0.4, o STB continuou a receber pacotes enviados para o mencionado grupo durante outros 4996,2 ms. A atraso de tempo entre o pedido de adesão IGMP ao grupo 224.121.0.3 e o primeiro pacote recebido de um grupo perfez 80 ms. O atraso entre os pedidos de IGMP (principalmente determinado pelo software STB) foi de 12,0 ms.

Em conjunto, o tempo total de activação de canais televisivos ao nível de pedidos de IGMP perfaz um total de 92 milissegundos. A atraso actual entre o novo canal seleccionado apresentado no ecrã da televisão depende de muitos parâmetros, incluindo a memória intermédia MPEG, a sincronização entre áudio/vídeo, etc., e pode chegar a 1 segundo ou até mais.

Além disso, o STB recebeu os pacotes de ambos os grupos multicast durante aproximadamente 5 segundos, desperdiçando largura de banda adicional. Para evitar essa perda, o comutador deve ser configurado para um abandono imediato. Isso é feito da seguinte forma:

c3560(config)#ip igmp snooping vlan 1 immediate-leave

Quando configurado desta forma, o comutador irá desactivar imediatamente o fluxo de dados do grupo abandonado. Os resultados são apresentados na moldura a vermelho. Pode ser visualizados que após o pedido de abandono "IGMPv2: Leave Group 224.121.0.11", o STB não recebeu pacotes do grupo 224.121.0.11. Como tal, a qualquer momento o STB recebe pacotes de apenas um canal.

Para uma gravação correcta dos parâmetros de tempo dos pedidos de IGMP, a interface de rede deve ser definida de acordo com o regime promisc antes de iniciar a senda no STB:

# ifconfig eth0 promisc

Lista TODO

• Melhorias no diagrama (escala, comutação, etc.)
• Diagrama de "interferência PCR", outros diagramas
• Compilações de binário da sonda para vários tipos de STB IP
• Monitor de disponibilidade da sonda para a gestão da rede