jenže vtip je v tom, že až do routeru to jde taky 100Mbit, a teprve TAM se sníží rychlost na ty 4Mbit. To se fakt blbě vysvětluje, když nechápeš ani základy TCP/IP. A netlimiter to omezuje vše pouze lokálně, není to router, ergo jeden endpoint patří jemu (buď odchozí, nebo příchozí) -- to se limituje daleko lépe a snadněji (v zásadě stačí "pozdržet" resp. nevydat ACK-SYN nebo ACK). Není problém s tím, že bys nemohl omezovat, problém je s tím, jak synchronizovat všechna PC v síti. Nebo se domníváš, že řešení 3 PC on-line, ale jen 2 sosají, tak dám všem 1/3 pásma je ok? Rozhodně ne, protože tak se vlastně strašně plýtvá pásmem (třetina "leží ladem") a není to QoS, ale shaping "napevno". Tudíž je lepší, aby rozdělení bylo na 1/2, ale to bys musel zajistit, že v případě, že 3. PC začne sosat, se pásmo rozdělí na 1/3. To je sice pěkně napsané, ale v reále se potkávají "krátké" datové toky typu html stránka (pár kb) s "dlouhým" tokem typu ISO image (pár MB), navíc ještě v čase rychlostně ovlivněné použitelnou šířkou pásma "na druhém konci". No a vtip je i v tom, že než se tyto limiterské aplikace "dohodnou" (protože: zjistím, že sosám (tj. se musím napíchnou na TCP stack), dávám echo broadcastem přes TCP ostatním, ty to musí přijmout a předat svým limiterům a ty zase aplikovat limity na TCP), tak stav "sosání" už může být diametrálně odlišný, a půjde "nová úprava". Výsledkem může být totální chaos, protože dopravní zpoždění (regulační terminus technicus) je prostě na současný ethernet po LAN příliš pomalý. Dnešní routery (ať už krabičkové, nebo "velké" linuxy) mají daleko sofistikovanější možnosti QoS a shapingu, to je ale za horizontem toho, co se tu dá sdělit. Doufám, že to je už jasné.
