No treba my to delame sice lamersky, ale jede to. Zvykli jsme si na simple queue, ale spise jsme to nasadili, a od te doby nepredelavali. Shapujeme na nejblizsim uzlu i na centralnim bodu.
Co se tyce nutnosti shapovani tam nebo onam, to asi zalezi. Myslim ze Gregy ma pravdu - je sice mozna "zacatecnik", ale uvazuje imo spravne. TCP neni zadna magie. V OS je cache (napr. 64KB pro connection u W2K a vyse). Kdyz na vas nekdo zacne chrlit data, tak kdyz se zacne cache zaplnovat, zacne TCP stack snizovat parametr tzv. Window. Stahnete si Ethereal (WireShark) a odpozorujte si, jak vypada TCP komunikace. Druha strana JE POVINNA v pripade snizeneho Window parametru zpomalit zasilani dat.
Na tomto principu funguje i Tarpit - nezahodi pakety, ale podrzi si spojeni tim, ze v ACK zasle window=0, a druha strana prestane posilat data. Kdyby i presto posilala, posle se RST a spojeni bude ukonceno. Vim to proto, ze jsme na hvezdarne vyvijeli CCD cameru, a ten maly TCP stack v SX52 jednocipu na to nebyl schopen reagovat :-) Tak jsme ten stack museli modifikovat ....
Takze - podle me je fama, ze vam smerem k internetu pak lita hodne dat - lita pouze mozna nez se na centralnim routeru pro dane spojeni zaplni cache, pak se to zreguluje. Samozrejme, ze jinym smerem (mimo centralni shaping), treba mezi usery, pak takovyto user muze komunikovat naplno. Takze je na vas, zdali omezite i na nejblizsim userove bodu. My to tak delame. Dalsi otazkou je, kolik tam mate klientu a jestli a nakolik to pak vsechno brzdi treba maly RB. Ale RB532 s cca 20 - 30 klienty se SQ a routovanym trafficem z dalsiho uzlu nam slape celkem pekne ....
Toz tolik a sorry, pokud se mylim :-)
Petr
