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
--
"Let's be realistic and try the impossible." - Che Guevara
