UDP server nechytá všechny pakety jako sniffer

[dolfi]

Ahoj
dělám vývoj embedded zařízení s mikrokontrolérem, AD převodníky a ethernetem, který má posílat bursty dat (offset + vzorky v 500 bajtech payloadu udp datagramu) do PC.

Pro základní seznámení se sítěma jsem nejpve používal Wireshark pro analýzu  a pro základní komunikaci PC utilitku Packet sender.

Abych si mohl udělat nějaký základní procesing přijatých vzorků, tak jsem si z dostupných materiálů udělal jednoduchý konzolový UDP server v Cčku  (http://www.sallyx.org/sally/c/linux/udp, http://www.binarytides.com/udp-socket-programming-in-winsock/ - pro widle).
Na PC otevřu udp socket pro naslouchání na určitém portu a pak v nekonečné smyčce přes recvfrom tahám přijaté data, které chci ukládat do texťáku ve vhodném formátu pro Octave (pořadí vzorku: hodnota)

S hrůzou jsem zjistil, že z burstu udp packetů zachytila tahle primitivní aplikace cca polovinu...zatímco wireshark mi tvrdí, že zachytil všechny. Pro cílovou funkci nevadí, že některé vzorky ztratím (z principu UDP a požadavků aplikace jsem s tím počítal), ale přece jenom 50% ztrátovost je přece jenom moc .
Částečným řešením je snížit výstupní datový tok z embedded zařízení - ať už nějakým zpožděním mezi odesíláním jednotlivých paketů nebo zvýšit payload UDP datagramu a poslat ho vícekrát za sebou.

Zajímalo by mě, kde je problém, když Wireshark zachytí 98-100% UDP packetů z embedded zařízení.

Děkuji

[Reklama]

[julo]

bez vedomosti nejakych detailov o tvojej aplikacii a z toho co pises mi pride ze takmer isto musi byt problem s tvojou aplikaciou
ako si pisal, UDP protokol nepouziva ziadnu kontrolu spravneho prijatia ako TCP, cize ak je to pozadovane musi to byt riesene aplikaciou

ak teda vidis wiresharkom ze prijimas 98-100%paketov, tak ich jednoducho musis prijat, cize strata musi nastat az po prijati medzi sietovkou a tvojou aplikaciou.
je mozne ze tieto bursty paketov nezvlada tvoja aplikacia, siet by som z tohto nevinil

[Ovrscout]

Mno bez dalsich informaci budu taky hadat, chtelo by to videt zdrojak a taky pustit informaci kolik a jak velkych packetu zhruba chodi za jednu vteřinu/minutu.

Hadam ze nacitani i ukladani se dela v jedne smycce(vlaknu) a protoze ukladani trva moc dlouho tak se nestiha dostatecne rychle prijimat data.
Muzete zkusit zvesit buffer pro socket aby udrzel vice dat nez je aplikace stihne vycist.
Take by asi stalo za to vyzkouset jen bez ukladani na disk a pocitat kolik prislo packetu za nejakou dobu a pri ukonceni to vypsat a porovnat s wiresharkem.

Pokud je tech packetů a dat v nich hodně, bude mozna potreba oddelit prijem dat a ukladani do souboru, tak aby na sobe nebyli primo zavisle. Napr mít to v jiných vlaknech a data si predavat pres thread safe buffer. Např nějaká varianta double bufferu s velikosti nekolika MB (je treba vyzkouset-zmerit nebo odhadnout z velikosti datoveho toku)

Ukladani na disk dost dlouho trva, ale obecne je rychlejsi jednim zapisem ulozit 1MB, nez udelat 1M zapisu o velikosti 1Byte. Takze vyhradit na buffery dostatek RAM. Nekdy muze byt vyhodne u souboru vypnout standardni bufferovani pokud uz se buffruje v aplikaci.

P.S. take pozor na to ze pokud se kazdy packet vypisuje na konzoli(printf je v mnoha prikladech) tak to taky pekne zdrzuje.

[dolfi]

heh...
měli jste pravdu, pač zakopanej pes byl opravdu v aplikaci na PC - konkrétně ve volání printf funkce, která vypisovala obsah čítače přijatých paketů a prvních pár bajtů payloadu obsahující offset.
Jako člověk používající Cčko jenom pro embedded věci jsem žil v představě, že pamětová a výpočetní náročnost printf funkcí se netýká dnešních PC mašin
Díky za podnětné rady...