Jazyk: C#

Kniznica: SharpPcap 1.6 (nadstavba Winpcap)

Typ Aplikacie: Console

Portabilita: Moznost rozbehania aplikacie na Linuxe s naistalovanym mono (ekvivalent .Net) systemom a kniznicou libpcap (ekvivalent Winpcap) -zistene na zaklade prispevku vo fore na www.codeproject.com Citat: "I have configured (with a mono option) that the SharpPcap import the "libPcap" instead the "WinPcap", in this mean work all fine!"

odchytavanie SIP paketov na zaklade identifikacie portu SIP(5060) - citanie hlavicky pomocou kodovania UTF8 - rozoznanie INVITE paketu - citanie tela INVITE paketu pomocou kodovania UTF8 - zistena variabilna dlzka (nemoznost citania urcitych bajtov kvoli ziskaniu RTP portu) - vyhladavanie charakterizijuceho retazca, za ktorym nasleduje cislo portu

odchytavanie RTP paketu na zaklade portu zisteneho zo SIP paketu -citanie 3. a 4. bajtu za ucelom ziskania SEQUNCE ID prevodom z bin sustavy do dec (zobrazenie na standardny vystup)

prerobenie aplikacie na viacvlaknovu -zachovanie funkcnosti 1. vlakonvej aplikacie avsak - vznikli problemy pri samotnom odchytavani RTP paketov (velka cast sa nezachytila) - problem: sposob odchytavania (event handler) je nevhodny pre pouzitie vo viac-vlaknovej aplikacii - zistene riesenie: odchytavanie zabezpecit pomocou priameho citania prichadzajucich paketov (funkcia PcapGetNextPacket()) - predchadzajuci sposob riesenia pomocou PcapGetNextPacket po vzkonani par testov vykazoval jedinu vyhodu, a to ze pakety neodchytavame vzdy(ako event handler) ale len ked chceme- pri zavolani funkcie. Pre Moju potrebu je vsak tato "vyhoda absolutne nepodstatna". Napriek tomu som vyuzil tento sposob odchytavania paketov pretoze pri tejto metode ma zrojovy kod jednoduchsiu strukturu a lepsie sa v nom orientuje.

MULTITHREADING Pri multithreadingu som narazil na problem ked som zistil ze funkcia PcapOpen() mi nevytvara novu instaciu sietovej karty, takze vsetky vlastnosti tykajuce sa sietoveho rozhrania vo vsetkych vlaknach su ovplinene ich poslednou zmenov v lubovolnom vlakne. To malo za nasledok ze kazde vytvorene vlakno mi odchytavalo pakety podla posledne nastaveneho filtru (napr ked SIPvlakno po vyskyte INVITE paketu spustilo RTPvlakno kde sa nastavil novy filter tak polovicu paketov chytalo RTPvlakno a druhu SIPvlakno co sa javilo ako 50% packetloss). Neskvor som sa prestal hrat s parametrami vlakien a sietoveho rozhrania a v dvoch vlaknach som spustil cely povodny 1vlaknovy proces, ako vysledok som mal program s 2 nezavisle fungujucimi vlaknami - obe chytali SIP aj RTP (tak ako jednovlaknovy proces) . Co je ale podstatne vlakna sa navzajom neovplivnovali co bolo sposobene ako som neskvor zistil vdaka funkcii GetPcapDevice() / GetAllDevices() , ktora vytvorila novu instanciu sietoveho rozhrania. Kedze vlakna fungovali nezavisle, pristupil som k ich rozdeleniu na SIPvlakno a RTPvlakno. Vysledok: konstatne beziace SIP-vlakno, ktore pri vyskyte INVITE a OK (potvrdzovaci paket) paketu spusti nove RTPvlakno. Pri BYE pakete RTPvlakno naopak zatvori. Pri dalsom INVITE-OK otvori spusti nove RTPvlakno a pri BYE ho zavrie...atd. RTP vlakno ktrore bezi len pri vyskyte RTP komunikacie.

Pridana funkcionalita:

Doteraz sa odchytavanie RTP paketov inicializovalo na zaklade INVITE paketu - co ale predpokladalo rovnaky pouzity port na RTP komunikaciu na oboch stranach - teda ak treba odchytavat obojsmernu prevadzku. Odchytavanie sa neukoncovalo.

Odteraz: 1) detekuje sa aj OK paket volaneho, ktory potvrdzuje INVITE paket volajuceho a zaroven obsahuje pouzity port u voleneho ucastnika. Vdaka tomu je mozne odchytavat komunikaciu obidvomi smermi aj ked bezi na roznych portoch 2) detekuje sa BYE paket , vdaka comu sa dalej nepotrebne RTPvlakno ukonci a nebrie tak zbytocne systemove prostriedky.

Zistenie stratovosti paketov -pri strate paketu / paketov sa pri doruceni dalsieho paketu vypise na monitor pocet stratenych paketov (na zaklade sequenceID) v oboch smeroch (packetloss) -testovane pomocou firewalu -zaujimave zistenie: v smere k mojmu pocitacu som schopny odchytit (prichadzajuce) pakety skvor ako ich zastavi firewall (ESET)

Zistenie jitter-u -odcitavanie Time-stampu z RTP paketu, jeho nasledne zobrazenie a zobrazenie casoveho rozdielu medzi aktualnym a predchadzajucim paketom (delay) -na zaklade zmeny hodnoty delay sa pocita jitter ... Na nete som nasiel pekne popisany popis k pocitaniu jittera pre voip spojenie a o jeho dopade na kvalitu telefonovania cez internet. Pracuje sa na doimplementovanie samotneho merania do aplikacie(DRAFTING)

Bridged network Rozbehal som Bridged network medzi host-OS a wmv-OS kvoli vznikajucim problemom pri nastaveni sietoveho rozhrania na NAT, Bolo potreba nahodenia dalsiej virtualnej NIC na ktorej teraz odchytavam komunikaciu (MS Loopback interface)

Optimalizacia RTP-THREAD (HASHTAB) Optimalizoval som multivlaknovy proces pre beh viacerych pararelnych RTP vlakien, k comu bolo potrebne vytvoryt hashtabulku na ukladanie odkazov na jedn. RTP-vlakna podla parametrov spojenia IP:PORT->IP:PORT implementovat ukladanie tychto odkazov do tabulky ako aj upravit sekvenciu kodu na rusenie vlakna , kde bolo potrebne pridat najprv nacitanie vlakna z hashtabulky.

PACKETLOSS Na zaklade hore-spomenuteho zistovania stratovosti paket som pridal funkciu na percentulane zistovanie packetlosu, ktore sa pocita ako podiel doslich paketov lomene sequnce ID posledneho paketu od zaciatku telefonatu az po jeho koniec pre obidva smery dokopy

Parametrizovany start aplikacie Bola pridana moznost spustat aplikaciu s parametrom urcujucim ktoru sietovu kartu je potrbne odpocuvat - V takomto pripade spustenia aplikacie, sa uz vyber karty vo vnutri samotnej aplikacie nepozaduje. Boli pridane funkcie blbovzdornosti pre zadavanie tohto parametra tak ako pomocou parameta pri spustani aplikacie tak aj pri jeho zadavani po vyzvani v samotnom programe.

Pracuje sa na nastudovani funkcnosti GET protokolu na generovanie eventov + na vyssie spominanom jittery

-- Main.MartinTkacik - 26 Oct 2008