CBQ & masq

[Slavek Banko (axis)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ano, to máte pravdu. Ostatně jak jsem psal, jedná se o "nepřímé" 
ovlivnění provozu, neboť ani není zřejmé, kolik provozu přibrzdím 
zdržením konkrétního ACK paketu.

V případech, kde lze provoz řídit na základě přesnějších čísel, bych též 
jednoznačně volil jinou metodu. V případech, kde jiná možnost není, se mi 
toto jeví jako "alespoň nějaká šance" k ovlivnění provozu.

Slávek.
- --

Dne po 10. červen 2002 09:58 David Trcka napsal(a):
> On Mon, 10 Jun 2002, Slavek Banko (axis) wrote:
> > Stanice k ničemu nepřesvědčuji - jen manipuluji s prioritou paketů,
> > které skrz mně prochází. Pro mně jsou to jen pakety s určitými
> > zdrojovými či cílovými porty a podle toho je řadím do fronty s
> > určitou prioritou.
>
> To vam neberu, ale napsal jste:
> > Pro upload klienti jistě používají TCP ==> klient po odeslání dat
> > očekává potvrzení o příjmu dat. Omezení "potvrzenek" by tak mělo
> > nepřímo způsobit, že klient přibrzdí odesílání.
>
> Jinymi slovy omezujete objem (=frekvenci) ACK paketu. Toto je ale dost
> promenliva velicina, ktera zavisi predevsim na konkretni implementaci
> TCP/IP stacku komunikujicich stran. Kdyz si najdu server, ktery posila
> ACK 2x pomaleji, ziskam 2x rychlejsi upload.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9BGOkBqd9Bu0fSIQRArL4AJ9BcWrPAaHA99swGzIDfP8MygWNFQCgtksC
f0FUOd3wttddgueS4aFQf0Y=
=v/Ks
-----END PGP SIGNATURE-----