On Thursday 17 July 2003 11:50 pm, you wrote: > ----- Original Message ----- > From: "stefmit" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Thursday, July 17, 2003 10:40 PM > Subject: [rlug] Re: TCP(Linux offtopic) > > > Cuvinte cheie pentru google (incerc in ordinea in care se leaga oarecum > > de intrebarile lui Gabi, precum si de a le citi intr-o anumita ordine, > > asa > > incit > > > si cunostintele sa se adune logic): > > > > tcp (duh!!!;)) > > delayed acknowledgment > > nagle algorithm > > window size advertisement (aici de de speriat citi din cei ce au raspuns > > sint > > > pe dinafara: window size NU SE NEGOCIAZA - se avertizeaza de catre > > fiecare capat!!!) > > sliding window > > silly window syndrome > > urgent mode > > slow start > > timeout > > retransmission > > congestion avoidance > > fast retransmit > > > > NOTA: in teorie TCP poate sa ACK data CHIAR INAINTE ca layer-ul superior > > sa o > > > fi primit si procesat, DACA NU SINT ALTI ALGORITMI/REGULI (vezi lista de > > mai > > > sus), care sa overide asta, CU CONDITIA CA TCP sa fi recunoscut data ca > > corect/complet primita. In mod normal TCP nu ACK data imediat ce a > > primit-o, > > > ci o "amina" in speranta ca mai are ceva de transmis (alt cuvint cheie pe > > care l-am uitat mai sus: "piggyback") - aminarea este de aprox 200 ms in > > Linux (DACA imi amintesc bine!!!), deci, daca - in teorie - cineva ar > > "type" > > > cite un caracter intr-o sesiune de rlogin, cu "echo enabled", si ar lasa > > timer-ul sa expire, ati putea vedea valorea pe care eu cred ca imi > > amintesc a > > > fi 200 ms, intr-un tcpdump trace. Acum - ca am scris asta - si un trace > > tcpdump la ambele capate ale unei conectii ar putea sa arate valoarea > > temir-ului. > > > > O sa incerc sa citesc in weekend toate emailurile atent, sa vad daca e > > ceva la > > > care pot sa mai arunc si eu un leu sau doi ... ;) > > Nu sunt sigur dar cam asa vad si eu problema, bineinteles > nu ma bag la Nagle, Leno sa. > Se pare ca o data fereastra anuntata de catre receiver, > sender stie in orice moment cati bytes mai poate transmite, > asa ca receiver ar tb. sa anunte in momentul in care a mai eliberat > din buffer. Daca mai asteapta inca un packet sau nu pt. ACK > pb. ca depinde de implementare. Cred ca un priceput daca s-ar uita > prin sursa (de aia e misto open source) ne-ar lamuri in 2 timpi si 3 ACK:) > G.
Revin la ce am mai spus: un raspuns imediat, fara mare bataie de cap cu privire la a citi documente si a invata de fapt cum merg treburile astea, ar fi: 1. #tcpdump -w <your_file>, rulat la ambele capete ale conectiei (daca se poate - daca nu, si una e buna) 2. rlogin session (sau telnet), cu conditia de a intra caracterele de la tastatura, cu suficient interval sa fie intre ele (peste 500ms - maximum acceptat de standard), dar nu prea mult, sa nu deconectezi; 3. importul ambelor fisiere tcpdump (sau numai al unuia, daca atit s-a capturat) in tcpillust (pentru cei ce nu stiu ce-i aia - o scula haioasa pentru training - http://www.csl.sony.co.jp/person/nishida/tcpillust.html) 4. si voila, mon cher: mura-n gura timings, ACKs, flags, etc ... ca in carticica marelui Stevenson (TCP/IP Illustrated vol I) In rest - pentru teorie si intelegerea fenomenelor: burta pe carte ;) ... Stefan
