Sper sa pot explica bine ce mi s-a explicat :) (thanks mihvoi) Un receiver trimite ack-uri fara sa-l intereseze de window size. El nu se 'asteapta' la o anumita marime a ferestrei. El efectiv trimite ack-uri cand poate si cum poate. Pe masura ce el trimite ack-uri, sender-ul isi 'misca' fereastra (de aici sliding window). Intr-adevar, cand senderul a trimis numarul maxim de pachete din window-ul receptorului, se va opri asteptand un ack de la acesta. (daca nu vine, se retransmite ultimul window).
Cat de cat mai clar. Receptor: trimite un pachet cu window de 3000 B Emitator: are de trimis 2000B (in 4 pachete sa zicem). Emitatorul va incepe sa trimita primul pachet, al doilea ... receptorul nu are timp sa raspunda.. emitatorul trimite in continuare si pe al treilea. S-au trimis 1500B pana acum. In acest moment receptorul poate trimite un ACK, si din now windowu de 3000B. Din acest moment, emitatorul are iar la dispozitie 3000B pe care ii poate trimite fara sa primeasca un ACK. Dar el mai are de trimis doar 500B. Trimite pachetul si la un moment dat, cand receptorul e mai liber, va raspunde cu ACK. Greseala fundamentala a noastra a fost sa presupunem ca receptorul asteapta neaparat un anumit nr. de byti (i.e. o fereastra). Wrong. el raspunde cand poate, emitatorul avand grija sa nu trimita prea mult. nu cred ca pot fi mai clar. e prea cald :) > 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 -- "Let's be realistic and try the impossible." - Che Guevara
