Názory k článku
FSP protokol - Internetová Legenda (5)
Michal Kára (neregistrovaný)
3. 3. 2005 8:08
Nový
Zalagovane site
celé vlákno
No teda nevim, mne vychazi, ze zalagovanych sitich bude lepsi TCP diky oknu a ze FSP bude strasne pomale, protoze na prenos jednoho packetu bude potrebovat RTT. Jedine, kde ma TCP problemy, jsou site, kde ztratovost packetu dosahuje patologickych hodnot (a mozna kde RTT _silne_ kolisa, coz take povazuji za patologicky stav).
Michal Kára (neregistrovaný)
3. 3. 2005 10:02
Nový
Re: Zalagovane site
celé vlákno
A co s nim - pokud vim, tak i pres nej jede TCP docela rozumne. Na to, ze je to technologie pro pristup k internetu (pevny - tak jak se pouziva u nas) zcela nevhodna. BTW, vzhledem k jeho vysokym latencim bych rekl, ze na nem bude FSP nepouzitelne.
uživatel si přál zůstat v anonymitě
3. 3. 2005 14:32
Nový
Re: Zalagovane site
celé vlákno
Spravne implementovane TCP by melo chodit i na ztratovych
sititch. Podle RFC ma TCP pro vypocet retransmit timeru
pouzivat pouze ne-retransmitovane packety. (pri
retransmitech nasobit cas dvema, ale po uspechu opet
spadnout na puvodni hodnotu pred zacatkem nasobeni). Ale
existuji bugovite implementace, ktere pocitaji cas i podle
retrasmitnutych packetu a s nimi se pak deje to, ze se
spojeni zpomaluje a zpomaluje az uplne vytuhne.
Dalsim problemem TCP jsou linky, kde se hodne meni round
trip time --- tam totiz retransmit timer muze dosahnout i
nekolikanasobne vyssi hodnoty nez je hodnota nejvyssiho
dosazeneho round trip time. Tenhle vypocet bohuzel
predepisuje RFC.
sititch. Podle RFC ma TCP pro vypocet retransmit timeru
pouzivat pouze ne-retransmitovane packety. (pri
retransmitech nasobit cas dvema, ale po uspechu opet
spadnout na puvodni hodnotu pred zacatkem nasobeni). Ale
existuji bugovite implementace, ktere pocitaji cas i podle
retrasmitnutych packetu a s nimi se pak deje to, ze se
spojeni zpomaluje a zpomaluje az uplne vytuhne.
Dalsim problemem TCP jsou linky, kde se hodne meni round
trip time --- tam totiz retransmit timer muze dosahnout i
nekolikanasobne vyssi hodnoty nez je hodnota nejvyssiho
dosazeneho round trip time. Tenhle vypocet bohuzel
predepisuje RFC.
uživatel si přál zůstat v anonymitě
3. 3. 2005 14:32
Nový
Re: Zalagovane site
celé vlákno
Spravne implementovane TCP by melo chodit i na ztratovych
sititch. Podle RFC ma TCP pro vypocet retransmit timeru
pouzivat pouze ne-retransmitovane packety. (pri
retransmitech nasobit cas dvema, ale po uspechu opet
spadnout na puvodni hodnotu pred zacatkem nasobeni). Ale
existuji bugovite implementace, ktere pocitaji cas i podle
retrasmitnutych packetu a s nimi se pak deje to, ze se
spojeni zpomaluje a zpomaluje az uplne vytuhne.
Dalsim problemem TCP jsou linky, kde se hodne meni round
trip time --- tam totiz retransmit timer muze dosahnout i
nekolikanasobne vyssi hodnoty nez je hodnota nejvyssiho
dosazeneho round trip time. Tenhle vypocet bohuzel
predepisuje RFC.
sititch. Podle RFC ma TCP pro vypocet retransmit timeru
pouzivat pouze ne-retransmitovane packety. (pri
retransmitech nasobit cas dvema, ale po uspechu opet
spadnout na puvodni hodnotu pred zacatkem nasobeni). Ale
existuji bugovite implementace, ktere pocitaji cas i podle
retrasmitnutych packetu a s nimi se pak deje to, ze se
spojeni zpomaluje a zpomaluje az uplne vytuhne.
Dalsim problemem TCP jsou linky, kde se hodne meni round
trip time --- tam totiz retransmit timer muze dosahnout i
nekolikanasobne vyssi hodnoty nez je hodnota nejvyssiho
dosazeneho round trip time. Tenhle vypocet bohuzel
predepisuje RFC.
