PDS proj Zdravím, jak počítáte jednotlivé statistiky? 1) Jak se v průběhu spojení měnilo sender/receiver window? - jen dle IP?? 2) Jaké byla rychlost v průběhu přenosu? - ?? dle timestampu + velikost prenesenych dat ?? 3) Jaký byl průběžný round trip time? - asi dle timestampu packetu a pakcetu predchoziho 4) Analýza sekvenčních čísel - zobrazení např. slow-start; - ?? toto moc nevim jak na to :D --- můžete mi prosím potvrdit správnost postupu u 1,2,3 a případně trochu popostrčit u 4, děkuji :)
1 a 2 ano, 3ku podle casu poslanyho datovyho paketu a prichodu odpovidajiho ACK, 4ku nikdo asi moc nechape, to se chce zeptat na upresneni
Opravdu staci na ty okna jen IP? Rekl bych ze musis pocitat s adresou i s portem :-)
Zobrazit všechny odpovědi (3)
Ja porty zobrazuju zvlast, nebot predstav si situaci s FTP. Michala by se komunikace z portu 20 a 21, a mel by si to jako rozdilny krivky v grafu, coz mi moc logicky neprijde
no FTP ma jeden port pro prikazy a druhy na data, tim padem je myslim spravne to zobrazit do dvou grafu ...
Pokud se nepletu, tak 2 porty = 2 TCP streamy, coz stejne ocekavat nemusime
ad 2) to je spíše teda rtt a velikost packetu ne? nebo jen proste rozdil timestamp dvou packetu a velikost packetu?
ako to riesite s vypisovanim statistik do grafu ak to porovnavam s wiresharkom tak on nevykresluje prvu hodnotu robite to tak isto alebo davate do grafov aj tu prvu hodnotu?
nedavam ale nezaručuji že je to správně
PDS Podařilo se někomu zprovoznit automatické načítání log souboru pomocí JS? Kromě způsobu co je na fóru předmětu(ten pro chrome nefunguje).
Nejjednoduzsi je jako log soubor generovat js file nebo json. Nacitani nejakyho obecnyho txt, ktery by bylo dobre samo o sobe citelny je asi zbytecny, hlavne pridava dalsi praci, kterou nikdo stejne neoceni.
PDS proj Na prosbu nahazuji svůj testovací pcap. Jedná se o tok stažení souboru z ulozto - jeden kompletní stream, který je celkem pěkně zachycený. Vypnul jsem před tím na windows vše, co by mohlo provádět segmentaci. Dnes po konzultaci s Grégrem by to snad mělo být ok. Je dost možné, že ani síťovka segmentaci vůbec nepodporuje (cca 7 let stará integrovaná). Zajímalo by mě, jestli se jedná o slow start podle grafu Throughput nebo ne (prosím o potvrzení/vyvrácení). V předchozím vláknu jsem nahazoval i své průběžné grafy a komentáře k výpočtu rychlosti přenosu, který stále ještě řeším. Pokud máte kdokoli nějaké poznatky k jakémukoliv bodu zadání, podělte se prosím, pomohlo by to nejen mně, ale určitě i ostatním :) Dílčí body zadání: - sender/receiver window? - rychlost v průběhu přenosu? - průběžný round trip time? - sekvenčních čísla (zobrazení např. slow-start)?
Přidávám, co jsem teď aktuálně schopný vyprodukovat, RTT a window sedí celkem hezky, i když mi chybí kontrola sekvenčních čísel pro odpovídající ACK u RTT, ale ta rychlost přenosu...
Zobrazit všechny odpovědi (6)
jak detekuješ sender/receiver? dle prvního paketu nebo nějak jinak? díky :)
Dle prvniho paketu, to asi ani jinak moc nejde. Predpokladam, ze se jedna o celej stream. Pokud by byl ze zacatku useklej, tak je to proste strana A a Bs tim, ze A komunikovala jako prvni.
Nemali by sa este tie velkosti okien shiftnut o WScale?
Martin Kacerik jj, mám to tak už udělané :)
Jerry Monroe prosímtě máš stále u toho RTT sender, ten počáteční vysoký bod? 1453 rel.seq.číslo, nebo ses ho nějak zbavil? díky ...že právě ve wiresharku není...
Martin Adamec mam, tohle je jeden z projektu, co by sel vic a vic vyladovat, ale uz jsem mu venoval dost, takze tyhle drobnosti uz neresim :)
ako pocitas RTT prosim ta?
Zobrazit všechny odpovědi (12)
Vezmu si vždy paket od jedné strany a první paket od druhé stanice a odečtu - kupodivu to vychází přesně jak ve wiresharku, ale chce to dodat kontrolu sekvenčních čísel, že opravdu daný paket z druhé strany je ACK na přechozí zprávu. Jen se mi moc nechce do ty implementace, ale jednodušší varianta asi není.
no lenze RTT je cas od poslania packetu do prijatia jeho ack, lenze tebe pride packet od serveru a hned posles ack a toto ked odcitas tak nedostanes RTT, ci nieco zle chapem?
Vladimír Vladis Vlkovič Jako neříkám, že je ten výpočet 2x korektní, zatím to bylo první, co jsem napsal, ale sedí to celkem s wiresharkem. V packet.time by měl být arrival time, ale nevím co je tam u těch paketů, které jsem odeslal já. Pak bych samozřejmě odečítaldobu příchodu paketu od serveru a odeslání paketu od sebe, což není úplně ideální. Obráceně by ot bylo lepší - odeslání svého paketu a příchod ack od serveru.
mna napadlo to iste co teba, len mi to prislo osobne prilis nepresne a momentalne stojim na tom ze neviem jak to RTT vypocitat, tak preto som sa pytal ci som daco neprehliadol
Vladimír Vladis Vlkovič Proto jsem rád, že se tu rozjela tahle diskuze, co jsem se tak i dnes bavil s více lidma, nikdo moc neví, takže když to nějak vymyslíme všechny ty body, bude to super :)
Ok, trosku sem se na to dival a rekl bych ze RTT by mel byt vypocitany jako cas prijeti ACK packetu(packet.time) minus cas odeslani SEQ packetu se stejnym cislem (druha pozice v timestamp z TCP options) tim se da ziskat jen RTT te strany, na ktere je pcap zachycen, jelikoz 1) p.time - ack.timestamp by byl pouze pul cesty pokud my ACK posilame (packet se ulozi kdyz my ho odesleme) 2) každy stroj muže mit jinak nastaveny/ řešeny timestamp takze by vysledne casy vysly divne. To potvrzuje i Wireshark, ktery graf udava jen pro jednu stranu, ale .. jak zjistim pro kterou? Napadlo me hodit tam nejaky threshold ale nevim jaky. (Kdyz se podivate na žraloka tak u každeho ACK packetu je RTT vypočitan, ale někdy je dost maly ... prave u tech packetu posilanych serveru)
https://blog.packet-foo.com/2014/08/tcp-expert-updates-in-wireshark-1-12/ tam je poznamka o 3ms pro urceni out of order ...
Gabriel Bordovský Díky moc, s tím už by tenhle graf měl být snad řešitelný :) Jen teda abych si to ujasnil. Ta druhá složka timestampu je teda fakt čas, kdy jsem odeslal packet na který mi teď přišlo ACK?
http://stackoverflow.com/questions/2524511/what-is-the-meaning-of-the-tsv-and-tser-fields-in-an-ethereal-dump podle tohodle jo
a nie su TSV a TSER optional? lebo ked hej tak to velmi nepomoze
Např. v tom streamu, co jsem postnul, tyto optiony nejsou, takže asi nezbyde nic jinyho, že se spolehnout na packet tam a zpátky.
zkoušel jsme implementaci pomocí Timestampů a vycházelo to divně (testováno na jíném pcapu).
Jednotky u osy x u RTT a window size jsou sekvencni cisla? A zkousel si to co jsem psal v predchozim threadu?
Zobrazit všechny odpovědi (4)
Na jednotky osy x vůbec nekoukej, tam nic nemám, tak tam graf cpe automaticky posloupnost od 1. Ještě nezkoušel, zkusím, ale nejsem si jistej, jestli to pomůže - průběžně posouvat 1s okno. Hlavně se to bdue pěkně blbě implementovat :D
EDIT | Nevim jestli je chyba u me, ale u RTT mi vychazi jinak jednotky. Uplne prvni RTT u SYN mi vychazi 20 ms, ty pri zemi kolem 23 us. Co se divam na hodnoty ve Wiresharku, tak by to melo odpovidat
Je možny, že to tam počítám špatně. A jak to teda počítáš? :)
Prijde paket, pokud ma data nebo to je SYN, vlozim do fronty. Pokud prijde paket s ACK (muze mit i data, muze byt piggybacked), projdu frontu poslanych paketu, vyhazim ty, ktery maji seq < ack, a u paketu s nejvetsim seq splnujici podminku (tedy posledni poslany, ktery prijaty ACK jeste potvrzuje) odectu jeho cas prichodu od prichodu ACK a ulozim. V pripade ztraty paketu u SACK to je jeste komplikovanejsi.
Zrovna jsem precetl tvuj postup mereni rychlosti z predchoziho postu a neco mi tam nesedi.. Podle me tim nepocitas aktualni prenosovou rychlost v danem case, ale prumernou rychlost od zacatku az do bodu pro ktery meris, takze treba kdyby ryhlost na konci nahle klesla, tak se to moc neprojevi jelikoz to pocita i s daty na zacatku. A nebo na to nahlizim nejak jinak?
Zobrazit všechny odpovědi (23)
My prave presny postup nevime (coz je celkem smutny), tak zkousime. Pokud mas nejaky napad, sem s nim
Říkáš to dobře, není to správně, ale je to zatím nejblíž tomu, když si to zobrazíš ve wiresharku. Když jsem to počítal tak, jak mi to přišlo logicky, např 100ms, měl jsem "zuby" přes celé a ne jen zákmity nahoře - viz to druhé vlákno. A popravdě nevím, co je správně.
Ja to mam zatim taky s temi zuby a kdyz jsem se ptal dneska na prednasce jak to ma byt, tak rikal ze je na nas jaky interval si zvolime pro mereni, takze treba pro 10ms tam ty zuby logicky budou, ale kdyz ten interval budes zvetsovat tak tak by se to melo vyhlazovat
Aleš Raszka Já vím, ty zuby mi nevadí, ale je rozdíl, jestli stoupne rychlost na max a pak ty zuby skáčou jenom nahoře (viz wireshark) a nebo skáčou přes celou výšku grafu, jak mi to vychází, když spočítám sumu toho, co přijde např. každých 10ms
Takhle mi vychazi moje posledni zminovana varianta pro server
A kdyz to vypisuju kazdych 10ms, tak jsou i zuby (Kofola reference :v )
Dominik Marton A jak to teda počítáš? :D
Repost: posuvny sekundovy okno. Postupne budes nacitat velikosti paketu a vzdycky je podelis sekundovym intervalem. Vysledek se bude vypisovat treba kazdych 200 ms. Pokud budes mit nacteny velikosti paketu, ktery prisly v ramci sekundy, zacnes ze zacatku velikosti ubirat a na konec pridavat, jak cyklicky buffer.
Dominik Marton Tak to funguje teda, jsem tomu mco nevěřil, takže jsem si říkal, že to zkusím až později a ono to fakt jede. Omlouvám se za nedůvěru a smekám :)
V pohode, ted uz zbyva jen analyza seq cisel
Jerry Monroe Akorat nevim, jestli do velikosti mam pocitat celej paket, nebo jen TCP payload
Dominik Marton To už jsou takovy detaily, ktery tak leda někde vyčíst, okoukat, jak to dělá wireshark nebo na forum
Dominik Marton Prosimtě, děláš tam ještě nějaký přepočty?. Ten cyklickej buffer vypadá dobře, ale stejně jsem trochu mimo od toho co Ti/wiresharku vychází. Max. hodnoty sedí, jen průběh ještě není úplně ok. Iteruju přes pakety, kontroluju jestli mám v bufferu víc jak 1s, pokud ano, tak zahazuju ze začátku. A každých 10ms vypíšu co mám aktuálně v bufferu k času posledního paketu v bufferu.
Nevypisuju to presne kazdych 10ms, ale pokud je posledni paket v bufferu - casovy bod > 10 ms, vypisu velikost v bufferu s casem posledniho paketu
Dominik Marton Už jsem to vyřešil, ale díky :)
Kdyz se ale ted divam na Wireshark, tak on pro vzorkovani po 0.1s ukazuje graf stejnej, jakej si mel uplne nazacatku, tzn. zuby od shora az dolu
Aha, tak uvidime no. Kdyz k tomu na naco jeste narazim, tak dam vedet :)
Dominik Marton A ono to dává smysl, když se nad tím zamýšlím, protože právě ta 1s, v rámci které to bufferujeme to vyhladí, ale jakmile máš buffer jen 0.1s (přesně těch 100ms, co jsem měl předtím) a vypisuješ to jen v rámci něho, tak se to nestihne nasumovat tak, aby to dělalo zuby nahoře a udělá to zuby přes cely.
Ktera varianta by se mela teda pouzit?
Dominik Marton Já bych se asi držel ty 1s spíš :) Ostatně je na nás, jak interpretujeme data, hlavně když to bude smysluplny.
Jen se chci ujistit jestli jsem zvolil správný postup - postupuju po intervalech, kde si sečtu velikost dat v paktech v daném intervale ( len(pkt) ) ...následně si získanou sumu vynásobím číslem (1/interval) ...tedy pro interval 0.2s, by to bylo 5 a tím získám jaká byla rychlost v daném intervalu za sekundu... nebo jsem to nějak blbě pochopil, díky :)
Martin Adamec Predstavi si krabici s otvorem nahore a dole, a s displejem. Shora vhazujes pakety a po intervalech jakych chces jen opisujes hodnotu s displeje, kterej ukazuje nashromazdenou velikost paketu v krabici. Pokud do krabice hodis paket, kterym se presahne objem jedne sekundy, tak ze spodu vypadne uplne prvni vhozenej paket a jeho velikost se odecte. Pri vhozeni dalsiho paketu by se pri prekroceni vyhodil druhej vlozenej paket atd. Trochu lepsi?
Dominik Marton pěkné vysvětlení ráno pozměním implementaci, díky ti ;)
Osobne jsem zmaten tou analyzou sekvencnich cisel. Co tim presne mysli? Dival jsem se na obrazky, kde je Reno atd. zobrazeno, a na osach casto maji cas a pocet paketu. Vysledny graf ale vypada uplne stejne jako rychlost, coz znamena ze pouzity algoritmus na congestion control lze vycist z rychlosti v prubehu prenosu. Co po nas teda chteji?
Zobrazit všechny odpovědi (7)
No ja mam za to, ze po nas chteji urcit, co bylo pouzito. Taky si to nechavam na konec ted. Tak zkusim mrknout, co se da z analyzy zjistit a jinak asi forum no.
vyslo vám pro ten slow start něco takovéhoto? Díky
Martin Adamec Jojo, mám to podobně
Jerry Monroe a udělal jsi graf i pro receivera? on nemá nějaký smysl moc, ale nevím jestli ho tam dát nebo ne....
Martin Adamec Udělal jsem, protože můžeš mít pak stream uploadu a tam to bude všechno jinak.
Martin Adamec staci spravit ten graf co mas na obrazku alebo mame tu sekvencnu analyzu robit takto:
Viliam Serečun ja doufam ze jen ten graf, mě už se s tím nechce nic dalšího dělat :D
PDS Huffmanv kód - neví někdo, jak se spočítá míra entropie H(x)? Normálně se počítá H(x) = -1 * sum( p(x) * log2(p(x))), ale v pds-01-teorie.pdf slide 29-31 jim dobře vychází střední délka zprávy, ale nechápu, jak se dostali k té entropii. Díky :)
Tak on standardní log na kalkulačce bude asi dekadickej :D Díky :)
PDS Tiez vam niekomu v diskusnom fore pribudlo "PDS - Zkoušky" ? Ako ja osobne sa este necitim na magistersky predmet ked nemam este hotovu bakalarku :)
Tak isto mam ja dostupne fora z IOSu. Asi len pri vytvarani nezaskrtli nejaku moznost ze len pre zapisanych.
Zobrazit všechny odpovědi (1)
jn IOS tam mam kazdy rok
PDS Zdravím, ve wis fóru u pds jsou zveřeněny informace k nadcházející půlsemestrálce.
Teda podla informacii na wis fore tam budu vsetky prednasky co su na serveri video zaznamov, plus prva prednaska, ktora tam chyba?
Asi ano, není mi z toho jasné, jestli i ta poslední přednáška na P2P, ale může se tam něco z toho objevit (viz. loňská fituška). Prostě vše, co je v datovém skladu k přednáškám :) a kalkulačky s sebou :D
PDS Mohol by sa niekto dnes Matouska opytat ci by nastavil prava na zaznamy ?
nekdo mu to oznamil, zaznamy jsou zverejneny
PDS Spominali na prednaskach odkial pokial bude polsemestralna skuska? Respektive, ma tam byt aj to co bude na zajtrajsej prednaske?
PIS PDS Kedy je planovana polsemka z tychto 2 predmetov?
mas chodit na prednasky :D
Predpokladejme, ze tam chodime, ale jen pro jistotu, kdy jsou terminy? :D
chodim, neviem lebo este nestanovil :D
jak moc velká blbost je chodit na PIS? slyšel jsem, že kvalita je děsná. ale info o půlsemce by se šiklo
Na PIS prednasce rikal, ze 15.3..
super, WAP 14., PIS 15.
PDS TCPstats Zdarec, nie som zrovna sietovo zdatny a nie je mi celkom jasne co mysleli v zadani tym, ze nie je vhodne robit analyzu nad suborom zachytenym na vlastnom kompe. Chceli tym len povedat, ze si mame v napr, Wiresharku najst daku tcp sietovu komunikaciu medzi strojmi, kde ani jeden nie je nas alebo nieco ine? Dik.
Ja to pochopil tak, ze tim nad vlastnim pc mysli, treba smycku, ze si budes posilat soubor sam sobe etc.
Vravel nieco ze idealne by bolo zrobit si siet s troma pocitacmi a posielat tcp pakety z jedneho pc cez treti na druhy a tu prevadzku odchytavat na tom tretom
hej, lebo kazdy ma po ruke 3 pocitace... (a nech mi nepovedia, ze sak mate cvt. uz vidim aki by boli spravcovia nadseni, ked by im tam ludia odpajali a prekablovavali pccka) Bude ale ta metoda s Wiresharkom co mne napadlo fungovat alebo je to uplne pase? (myslim, ze by to malo byt to iste, ale ako som pisal, siete nie su moja salka kavy)
Zobrazit všechny odpovědi (1)
mozes skusit virtualku, tri 3 op. sys. by slo vyrtualizovat bez velkych vypocetnych narokov
Neviem ani ja sa do toho nevyznam... ale bolo by asi vhodne z wiresharku vyrezat len jednu komunikaciu ak to ide
A jj bolo by super keby nam dali testovaci vstup, ze ako si to oni predstavuju
Ja osobne si myslim, ze ak sa postaras o to, aby bol TCP segment offloading vypnuty na oboch zariadeniach ktore komunikuju, tak nepotrebujes tretiu stranu. Pod linuxom sa da overit pomocou ethtool --show-offload. Pod windowsom to bude asi niekde v nastaveniach sietoveho adapteru.
Ja verim ze nejaka dobra dusa zverejni nieco na testy :D
Jakub Tutko pojď příkladem :D
Rad by som :D
PDS to dnes prednaska uz skoncila, trvala len hodinu a pol? :D
Před 17:00 mělo prý začít cvičení
Cvičení trvalo asi tak milion let.
hej hej streamoval som a fakt to bolo dlhe :D
tak on na minulé přednášce říkal, že dřív jak v 17:00 nemůže
PDS Lze to dělat v pythonu za použití libpcap-dev tak, aby všechno bylo instalováno z repozitářů? python-scapy/pcapy mají závislost na libpcap0.8, která ale neumí formát pcapng ..
PDS nemate nejake doporucenie jazyku a kniznice pre riesenie TCPstats projektu?
python 2.7+dpkt mozno budem robit, ale este som nepresiel komplet cele zadanie co tam chcu. No parsrovanie takychto dat je s tymto lahke. Dalsia moznost Scapy ale ta je pomala a neoptimalna
dpkt který je v repu ubuntu neumí pcapng ("Lze použít vše, co je na daném stroji dostupné, případně lze doinstalovat pomocí aptitude")
Pisal som na forum ci mozme riesit len pcap miesti pcapng tak uvidime :)
Gregr potvrdil, staci pcap
PDS proj Nevíte někdo něco k přihlašování? Končí už zítra, ale že by se dalo na něco přihlásit, to se říct nedá :D
Na přednášce bylo řečeno, že kdo chce uznat body (3.varianta) bo nějaký individuální projekt (2.varianta) má napsat maila, jinak budou mít všeci stejný projekt (1.varianta)... (pokud si správně pamatuju)
To vím, ale že se zítra přihlašování uzavírá a nic tam nemaj :D
Řekl bych že budeš po uplynutí termínu přihlášený učitelem na termín podle toho o co sis napsal/nenapsal vůbec... ale ruku do ohně bych za to nedal...
A nerikal, kdy zhruba bude hotove zadani projektu? (Nebo uz je a ja ho jen nenasel?)
PDS Řekne mi někdo prosím jak často a jak dlouhá jsou "numerická cvičení" v PDS (to, co je ve čtvrtek po přednášce) a také popř. co je jejich náplní, abych věděl, jestli bude vadit, když nějaké cvičení nebo jeho část vynechám?
"Democvičení slouží k prohloubení probírané látky, či praktickým ukázkám nad rámec obvyklé přednášky. Termíny cvičení a obsah látky bude upřesněn na začátku semestru.", vid Wiki stranka predmetu.
Loni tam Matoušek ukazoval různé zabezpečovací kódy a počítal s námi příklady, i když teda docela často řešil nějaké chyby.
Urcite na dema chodit. Hodi se to. Uplne nejlepe se na to predem trochu podivat. V prubehu nechava volny cas, aby si reseni prikladu kazdy zkusil sam a pak ukaze/rekne spravny vysledek.
Díky moc, pomohlo mi to v rozhodování :)