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 ... ;) Stefan On Thursday 17 July 2003 04:55 am, Gabriel Cernat wrote: > La o comunicatie de layer transport- TCP, cum > stie receiver-ul cat sa astepte inainte sa transmita > un ACK ? > ( Completare, ca suna iurea intrebarea-> > Cand i se umple bufferul?- dar poate sender-ul nu mai > bytes de transmis! > Cand expira niste countere?) > > Gabi
