NetUP IPTVProbe

소스 코드 - iptvprobe_v0.4.tbz2

IPTVProbe와 관련된 질문을 NetUP's IPTV Forum에서 토의할 수 있습니다

변경 로그

Version 0.4
• 주기적인 데이터베이스 정리.
• 프로브 단위로 다중 멀티캐스트 스트림 모니터링.
• iptvprobe_server에서 메모리 누출 수정.
참고! 이전 버전에서 업그레이드할 때 데이터베이스는 전체적으로 재생성됩니다.

Version 0.3
• IGMP 요청 처리 및 추가된 임시 IGMP 변수의 표시.
• 코드 정리, 사소한 버그 수정
• 프로브에서 데이터 교환 프로토콜이 새로운 버전으로 업데이트.

Version 0.2
• Aminet 110 (ppc) 지원 추가.

Version 0.1
• 원본 출시.
• 분실 패킷 제어 추가
• UDP 패킷 수신 스피드의 표시 추가.

네트워크 구성도

Probe (iptvprobe) 및 콜렉터 작동 레이아웃

소프트웨어 구축 및 설치

소프트웨어는 다음 부분으로 구성되어 있습니다:

• 콜렉터 - 프로브에서 통계를 수집합니다. 수집된 통계는 데이터베이스(mysql)에 저장됩니다.
• 프로브 - 원격으로 작동하는 애플리케이션입니다. 수신된 IP 패킷 상의 통계는 프로브를 통해 수집되어 콜렉터로 전달됩니다. 프로브는 리눅스 커널 모듈(netup_netprobe.ko) 및 사용자 레벨 소프트웨어(iptvprobe)로 구성되어 있습니다.
• 리포트 서브시스템 - 수집된 통계를 가시화하는 웹 스크립트 세트입니다.

콜렉터 구축 및 시작

콜렉터 구축:

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

데이터베이스 만들기:

mysqladmin create iptvprobe
mysql iptvprobe < db.sql

콜렉터 시작:

./iptvprobe_server -l root -s 127.0.0.1

이 예에서 콜렉터는 통계를 로컬호스트(127.0.0.1) 상의 'iptvprobe' 내에 기록합니다.

iptvprobe 구축

x86 플랫폼을 위한 애플리케이션 구축:

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

x86 플랫폼을 위한 리눅스 커널 모듈 구축:

cd iptvprobe/kmodule/
make

sh4 플랫폼(IP STB AmiNET 130)을 위한 리눅수 커널 모듈 구축:

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

aminet130_bin/ 디렉토리는 이미 구축된 리눅스 커널 모듈과 AmiNET 130 IP STB를 위한 사용자 레벨 애플리케이션을 담고 있습니다.

프로브 시작

리눅스 커널 모듈 로딩:

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

후크 포지션 변수가 넷필터의 IP 패킷 후크 포지션을 상세 지정합니다:

0 - 모든 들어오는 IP 패킷 처리(PREROUTING policy) 1 - 모든 나가는 IP 패킷 처리(POSTROUTING policy)

클라이언트 기기(예: IP STB AmiNET 130)에서 모듈을 가동할 때 "0"값을 설정해야 합니다. 멀티캐스트 트래픽을 전송하는 서버에서 모듈을 가동할 경우에 "1"값을 설정해야 합니다.

/dev 파일시스템에서 노드를 만드는 것이 필요하며 netup_netprobe.ko 모듈이 성공적으로 로드되면 iptvprobe 애플리케이션을 시작해야 합니다:

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

명령줄 옵션:

-i Sets the multicast address for monitoring
-s Specifies the IP address of the collector
-p Specifies the port for the collector to accept connections from probes
-r Specifies a run identifier

완전히 조합된 명령을 리포트 서브시스템에서 찾을 수 있습니다.

리포트 서브시스템

리포트 서브시스템을 운영하려면 모든 웹 스크립트를 iptvprobe/report_sys/에서 복사하여 본인의 웹 서버 cgi-bin 폴더에 저장해야 합니다:

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

원할한 가동을 위해 시스템에 펄 및 GD를 설치해야 합니다.

웹 브라우저를 다음 URL로 지정합니다:

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

"address"가 본인의 웹 서버 주소가 있는 곳입니다.

시작 페이지에는 실행중인 프로브 목록이 들어 있습니다:

"Command to run on probe" 컬럼에는 프로브에서 실행되는 완전히 조합된 명령어가 들어 있습니다.

"UDP timeline diagram" 또는 "PCR Arrival Interval" 링크를 사용하여 멀티캐스트 흐름의 그래픽 표시를 볼 수 있습니다. 대략 지난 30초 간의 기록이 다이어그램에 보여집니다.

가동중인 두 개의 예가 실행되었습니다. 첫번째 것은 IGMP 스누핑 지원없이 단순한 SOHO 스위치를 통해 연결된 AmiNET 130 IP STB 상에서 실행되었습니다. 두번째 것은 IGMP 스누핑을 가지고 Cisco 카탈리스트 스위치를 통해 연결된 AmiNET 130 IP STB 상에서 실행되었습니다. 첫번째 경우에 많은 IP 패킷 손실이 있습니다. 다음 다이어그램은 이 두 경우를 보여줍니다:

다이어그램 설명

대략 지난 15-30초 간의 기록이 x축 상에 보여집니다.

다음 변수가 y축 상에 보여집니다:

• 100 msec 내에 형성된 IP 패킷 수.
• 100 msec 내에 형성된 바이트 수.
• 빨간 선은 손실된 IP 패킷을 나타냅니다. "IP packet ID"에서 불연속성이 감지되면 다이어그램 상에 피크가 나타납니다. 0 값은 손실된 패킷이 감지되지 않았다는 의미입니다.

데이터베이스 설명

IGMP 모니터링

iptvprobe v0.3 이후 버전에서 IP STB에 의해 송수신된 IGMP 요청은 프로브에 의해 추적될 수 있습니다. 그룹을 떠나기 전의 마지막 그룹 패킷과 그룹에 참여한 후의 처음 패킷의 타임스탬프가 또한 기록됩니다. IGMP 요청 및 IGMP 스누핑을 처리하는 네트워크 장비의 성능을 평가하는데 이 데이터를 사용할 수 있습니다.

아래의 것은 프로브를 위한 Aminet 130 IP STB와 콜렉터를 위한 NetUP Middleware가 가지는 기능의 예입니다. Cisco Catalyst 3560는 IGMP 스누핑 지원을 받는 전환기로 사용되었고 Cisco Catalyst C3550-12T는 IGMP 쿼리기 역할을 합니다.

TV 채널은 IP STB에서 전환되었습니다. STB가 멀티캐스트 그룹 224.121.0.4를 떠나라는 IGMP 요청과 그룹 224.121.0.3에 들어가라는 또다른 요청을 보냅니다. 이 요청은 프로브에 의해 기록되고 타임스탬프와 함께 웹 인터페이스에 같이 표시됩니다:

관심 항목은 파란 프레임으로 둘러싸여 있습니다. IGMP가 멀티캐스트 그룹 224.121.0.4에서 떠나라는 요청을 한 후에, STB가 추가 4996.2ms 동안 앞서 언급된 그룹으로 보내어진 패킷을 계속 수신했다는 것이 명확합니다. IGMP의 그룹 224.121.0.3으로의 참여 요청과 이전 그룹의 첫번째 수신된 패킷 사이의 시간 지연이 80ms에 해당합니다. IGMP 요청(주로 STB 소프트웨어가 결정) 사이의 시간 지연은 12.0ms입니다.

전체적으로 IGMP 요청 레벨에서 TV 채널의 총 전환 시간은 92ms에 달합니다. 새롭게 선택된 채널이 TV 스크린에 나타나는 실제 지연 시간은 MPEG 버퍼링, 오디오/비디오 동기화 등과 같은 많은 변수에 의해 좌우되며 1초 또는 그 이상 걸릴 수도 있습니다.

이뿐만 아니라, STB가 대략 5초 동안 양쪽 멀티캐스트 그룹에서 패킷을 받았기 때문에 별도의 대역폭을 낭비한 것입니다. 이런 손실을 피하려면 전환기를 즉각적인 이탈로 설정해야 합니다. 이것을 다음과 같이 실행합니다:

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

이런 방식으로 설정되면, 전환기는 순간적으로 배제된 그룹을 위한 데이터 스트림을 차단할 것입니다. 결과가 빨간 프레임 안에 보입니다. "IGMPv2: Leave Group 224.121.0.11"의 떠나라는 요청 후에 STB가 224.121.0.11 그룹을 위한 패킷을 받지 않았음을 볼 수 있습니다. 그러므로, 주어진 순간에 STB가 오직 하나의 채널에서 패킷을 수신합니다.

IGMP 요청의 임시 변수를 바르게 기록하기 위해, STB 상에서 프로브를 시작하기 전에 네트워크 인터페이스를 promisc 상태로 설정해야 합니다:

# ifconfig eth0 promisc

TODO List

• 다이어그램 개선(스케일, 이동 등)
• "PCR jitter" 다이어그램, 기타 다이어그램
• 다양한 유형의 IP STB를 위한 바이너리 프로브 구축
• 네트워크 관리를 위한 프로브 가용성 감시