În prezent învăț despre TCP, în special despre aspectul ferestrei de recepție. Am citit din mai multe surse despre asta și vreau să mă asigur că înțeleg ceva.
Din ceea ce am învățat, receptor face publicitate unei „ferestre de primire”, care este - și aici mă confund - numărul de octeți pe care expeditorul are voie să-i trimită fără a fi confirmat, sau cu alte cuvinte, date în zbor.
Acum, dacă încerc să mă gândesc la asta, scopul nostru principal în controlul fluxului este să ne asigurăm că expeditorul nu va trimite mai mult decât poate procesa receptorul, adică dorim să prevenim o situație în care un expeditor le trimite date pe care receptorul va trebui să arunce, deoarece nu va avea unde să-l depoziteze!
Mergând cu această logică, ajung să cred că fereastra de primire ar trebui să corespundă cu dimensiunea bufferului de primire (nu știu dacă este exact aceeași, dar dimensiunea ferestrei ar trebui să fie oricum un derivat al bufferului de primire) și
motivul pentru care limităm date în zbor trimis de expeditor este că - dacă expeditorul va trimite mai mult decât dimensiunea ferestrei (care, din nou, este un derivat al tamponului de primire), iar receptorul nu a confirmat unele dintre date (actualizarea dimensiunii ferestrei), există Mai fi o situație în care receptorul nu va ține pasul - adică va primi datele mai repede decât le poate procesa aplicația care le consumă, ceea ce duce la eliminarea segmentelor (sper că este clar).
Dar, citind acest post, @DavidShwartz spune că scopul datelor în zbor NU este de a evita supraumplerea buffer-ului, ci mai degrabă de a gestionează întârzierea introdusă de canalul de comunicare. Pe care nu prea înțeleg.
Problema este că fiecare sursă care vorbește despre acest subiect nu explică legătura dintre scopul general al controlului fluxului și lucrul cu date în zbor.
Poate cineva să explice asta mai detaliat?