Parca n-am inteles intrebarile chiar asa ... dar s-ar putea sa gresesc. Oricum:
1. Este split horizon, nu "spliting[sic]" horizon ... si daca apare asa in carte, atunci evident este gresit ... apropos - cele mai bune explicatii in domeniul interconectiilor le gasesti avind-o ca autor pe Radia Perlman - uita-te pe tot ce a scris cucoana (cea care a inventat spanning tree protocol, ca si IS-IS si algoritmii folositi de routing protocols) 2. Eu am inteles "free ride" din intrebare ca: "freee ride on the back of an ACK" - si asta este ceeea ce mentionasem in primul raspuns la thread-ul asta, si anume ca intotdeauna se asteapta ca un timer sa expire (200 ms pentru Linux, parca), inainte ca un ACK "singurel" sa fie trimis, tocmai pentru a oferi sansa de "piggybacking" - nu imi amintesc exact ce RFC numbers contin specificatia, dar fie o vizita la http://www.faqs/org, fie o lectura a oricarui material precum: http://www.mnlab.cs.depaul.edu/~ehab/Courses/TDC562/PDF/8-TCP-errorflow.pdf at trebui sa lamureasca toate problemele enuntate pina acum. Stefan On Monday 21 July 2003 06:51 am, you wrote: > 1. editia III era tradusa cam cu picioarele (la ce sa te astepti de la > profesorii din poli). Ed IV pare mai ingrijita la capitolul asta. Acum, > tre' sa recunoastem ca nu e simplu de tradus in asa fel incat sa-i > multumesti pe toti... > > 2. din RFC 793 - Transmission control protocol. Ca sa nu mai googleuiti: > > Window Management Suggestions: > > - Allocating a very small window causes data to be transmitted in > many small segments when better performance is achieved using > fewer large segments. > > - One suggestion for avoiding small windows is for the receiver to > defer updating a window until the additional allocation is at > least X percent of the maximum allocation possible for the > connection (where X might be 20 to 40). > > *** Another suggestion is for the sender to ___avoid sending small > segments by waiting until the window is large enough before > sending data____. If the the user signals a push function then > the data must be sent even if it is a small segment. > > - Note that the acknowledgments should not be delayed or unnecessary > retransmissions will result. One strategy would be to send an > acknowledgment when a small segment arrives (with out updating the > window information), and then to send another acknowledgment with > new window information when the window is larger. > > - The segment sent to probe a zero window may also begin a break up > of transmitted data into smaller and smaller segments. If a > segment containing a single data octet sent to probe a zero window > is accepted, it consumes one octet of the window now available. > If the sending TCP simply sends as much as it can whenever the > window is non zero, the transmitted data will be broken into > alternating big and small segments. As time goes on, occasional > pauses in the receiver making window allocation available will > result in breaking the big segments into a small and not quite so > big pair. And after a while the data transmission will be in > mostly small segments. > - The suggestion here is that the TCP implementations need to > actively attempt to combine small window allocations into larger > windows, since the mechanisms for managing the window tend to lead > to many small windows in the simplest minded implementations. > > Deci, raspuns final, este o sugestie a RFC. Sorry pentru aliniere. Copy > and paste :) > > > ----- Original Message ----- > > From: "Adrian Pirciu" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Saturday, July 19, 2003 10:57 PM > > Subject: [rlug] Re: TCP(Linux offtopic) > > > > > Depinde ce cauti... Tanenbaum iti da o 'cultura generala' > > > deosebit de cuprinzatoare si iti face o introducere in cam > > > tot ce inseamna retele. Evident ca pentru ceva specializat > > > trebuie cautat altundeva. Pentru asta iti stau la dispozitie > > > cele cate pagini bune de referinte. Dar e o carte din care > > > poti afla chestii noi si la a x-a rasfoire (de fapt sa constien- > > > tizezi, nu sa afli). Una peste alta, ca aici voiam sa ajung, > > > mi se pare lectura obligatorie pentru orice retelist. Nici > > > stricta specializare pe ceva anume nu e prea buna mereu.... > > > Prea multi stiu cum functioneaza ssh dar nu stiu ce e ala arp > > > si prea multi stiu, sa zicem, de tcp sliding window dar nu > > > au macar o vaga idee de securitatea retelelor....(doar exemple) > > > > Am citit ceva de spliting horizon in cartea lui Tanenbaum. > > Traducerea sucks.La greu.(parerea mea mon cher:)) > > Ca sa revin la ce ma interesa: Andrei spunea ca sunt > > niste countere pentru ACK (ca la sender) si daca prinde > > un packet face un "ride free of charge". Chestia este sigura? > > Este o specificatie RFC? > > Gabi
