Hoe bandbreedte afknijpen?

[Verwijderd]

Naar aanleiding van meerdere topics over hoe je bandbreedte kan 'afknijpen'/beperken (per process/poort) zou ik weleens willen weten hoe ik dit zou kunnen doen.

En dan doel ik niet op welke API te gebruiken maar puur het functionele.
Dus stel ik bouw een proxy en hoe zorg ik er dan voor dan er maximaal 5KB verkeer is of iets dergelijks.....

Ik hoop dat iemand mij kan helpen met dit aangezien ik veel andere mensen wil helpen die op zoek zijn naar zo'n prog voor windows

[Verwijderd]

Elk data pakketje over een netwerkinterface heeft een bepaalde grootte. Je kan dan dus simpelweg instellen dat er maximaal N pakketjes over de lijn per seconde mogen gaan. Na dat aantal pakketjes knijp je ze gewoon af (queue niet processen) totdat je bij de volgende seconde bent.

[Verwijderd]

Op maandag 29 april 2002 11:49 schreef beelzebubu het volgende:
Elk data pakketje over een netwerkinterface heeft een bepaalde grootte. Je kan dan dus simpelweg instellen dat er maximaal N pakketjes over de lijn per seconde mogen gaan. Na dat aantal pakketjes knijp je ze gewoon af (queue niet processen) totdat je bij de volgende seconde bent.

Mmmmmz dit klinkt inderdaad wel intressant...maar is het dan niet zo dat je queue niet erg vol begint te staan, ik bedoel:
-Sender stuurt 1000 packages a sec en je er mogen er maximaal 100 per sec door...dan komen er per seconden 900 nieuwe packages in je queue te staan, dus na 5 minuten zijn er 300.000 - 30.000 = 270.000 packages in de queue, kan ik deze niet beter droppen aangezien het anders toch goed fout gaat

[DRvDijk]

Ik ben wel n00b, maar volgens mij klopt het als ik zeg dat alleen een flut-programma zoveel packages stuurt zonder te wachten totdat er zoveel en zoveel packages zijn verstuurd.. Ik ken alleen ping -f dat gewoon packages door blijft sturen.. Iets als KaZaa zal dat niet doen mag ik aannemen; Anders gaat KaZaa er vanuit dat er geen limiet op de bandbreedte zit, wat wel het geval is natuurlijk, denk alleen al aan mensen die inbellen!

[Janoz]

Als de queue vol zit stuur je gewoon geen ack meer terug. Het TCP/IP protocol is zo ingericht dat de sender, bij het niet ontvangen van ACK pakketjes automatisch langzamer gaat versturen. (Komt eigenlijk op hetzelfde neer als gewoon niks meer accepteren). Dit is ongeveer hetzelfde effect als wat je krijgt waneer je upload helemaal vol zit. Op dat moment kunnen er ook nauwelijks meer ACK-pakketjes doorheen waardoor je downloads ook enorm naar beneden zakken.

[Verwijderd]

We hebben het nu over 'packets' maar ik wil op application niveau dus een proxy hebben die het hele gebeuren 'afknijpt' is dit dus ook mogenlijk op application niveau of moet ik echt op een lager niveau gaan zitten.
Want ik neem aan dat de TCP/IP verbinding zelf de ACK's stuurt en niet de applicatie tenminste normaler wijs doe ik dat niet zelf
Help me please.

[Verwijderd]

knijper op de kabel.

op school hebben we ook zo iets ik zal na de vakantie even kijken hoe dat heet bij ons op school heeft iedere pc 5 kb down en 2.5 up. en dat doen ze met een progie wat niet te kraken is

[Verwijderd]

Op maandag 29 april 2002 14:30 schreef computerboer22 het volgende:
knijper op de kabel.

op school hebben we ook zo iets ik zal na de vakantie even kijken hoe dat heet bij ons op school heeft iedere pc 5 kb down en 2.5 up. en dat doen ze met een progie wat niet te kraken is

Alles is te kraken....maar ik zoek geen proggie maar de techniek...
Als je weet wel proggie het is kun je het het beste ff posten in de draadjes in SA

[Verwijderd]

Als het wat ruimer moet... dus voor bijvoorbeeld hosting waarbij je iets van B/W metering/shaping op IP niveau wilt doen, 2 NIC's in een PC. Met packet drivers kun je dan je eigen doorgeefluik/bridge in elkaar prutsen.

[Verwijderd]

Op maandag 29 april 2002 15:47 schreef MarcoTC het volgende:
Als het wat ruimer moet... dus voor bijvoorbeeld hosting waarbij je iets van B/W metering/shaping op IP niveau wilt doen, 2 NIC's in een PC. Met packet drivers kun je dan je eigen doorgeefluik/bridge in elkaar prutsen.

Das dus juist niet de bedoeling ik wil het op Applicatie niveau doen (Applicatie niveau in het OSI model).

[Janoz]

Mijn reactie sloeg meer op de reactie van jouw boven die van mij skunkah. Het komt er op neer dat als je applicatie geen packetjes meer accepteerd dat er dan ook een stuk minder verstuurd gaan worden.

[Verwijderd]

Op maandag 29 april 2002 13:04 schreef Janoz het volgende:
Als de queue vol zit stuur je gewoon geen ack meer terug. Het TCP/IP protocol is zo ingericht dat de sender, bij het niet ontvangen van ACK pakketjes automatisch langzamer gaat versturen. (Komt eigenlijk op hetzelfde neer als gewoon niks meer accepteren). Dit is ongeveer hetzelfde effect als wat je krijgt waneer je upload helemaal vol zit. Op dat moment kunnen er ook nauwelijks meer ACK-pakketjes doorheen waardoor je downloads ook enorm naar beneden zakken.

In principe is de queue van een TCP/IP client niet groter dan enkele datapakketjes. Dat heet toch sliding window principe oid? . Als die queue vol is zal de eerstvolgende write() van de applicatie of een fout returnen (O_NONBLOCK) of blocken totdat de queue niet meer vol is (geen O_NONBLOCK). Dus de queue zal nooit voller worden dan de grootte die je hem toestaat... Daar houdt je kernel wel rekening mee. .

[Verwijderd]

ZEER WENSVOL PROGJE, maar http://www.xcat-industries.com/ is d0wn dus kan de alpha niet dlen. Al vorderingen gemaakt met je progje?

[MSalters]

RFC 1812, 4.3.2.8 Rate Limiting , page 56.

Zoekbewerking duurde 0.05 seconden

[rvanlooijen]

Intresting, ik was idd de verzoeker in een van je eerdere topics. Ik heb deze wens/dit probleem nogsteeds niet kunnen tackelen en wacht dus nogsteeds in spanning op een oplossing . De oplossing zoals Chefke die noemt klinkt erg intressant, al vrees ik dat dit weer of een socks proxy is of een ISA server. Een proxy is geen afdoende oplossing (om duidelijke redenen) en om nou een ISA server op te zetten

edit:
die kick van een half jaar valt me nu pas op, still true tough...

[rvanlooijen]

nav MSalters:

4.3.2.8 Rate Limiting

A router which sends ICMP Source Quench messages MUST be able to limit the rate at which the messages can be generated. A router SHOULD also be able to limit the rate at which it sends other sorts of ICMP error messages (Destination Unreachable, Redirect, Time Exceeded, Parameter Problem). The rate limit parameters SHOULD be settable as part of the configuration of the router. How the limits are applied (e.g., per router or per interface) is left to the implementor's discretion.

DISCUSSION
Two problems for a router sending ICMP error message are:
(1) The consumption of bandwidth on the reverse path, and
(2) The use of router resources (e.g., memory, CPU time)

To help solve these problems a router can limit the frequency with
which it generates ICMP error messages. For similar reasons, a
router may limit the frequency at which some other sorts of
messages, such as ICMP Echo Replies, are generated.

IMPLEMENTATION
Various mechanisms have been used or proposed for limiting the
rate at which ICMP messages are sent:

(1) Count-based - for example, send an ICMP error message for
every N dropped packets overall or per given source host.
This mechanism might be appropriate for ICMP Source Quench,
if used, but probably not for other types of ICMP messages.

(2) Timer-based - for example, send an ICMP error message to a
given source host or overall at most once per T milliseconds.

(3) Bandwidth-based - for example, limit the rate at which ICMP
messages are sent over a particular interface to some
fraction of the attached network's bandwidth.

bron: http://community.roxen.com/developers/idocs/rfc/rfc1812.html

Zelf kan ik er in dit verband niets mee, maar misschien iemand anders wel... Skunkah?

[aj-san]

Verwijderd schreef op 29 april 2002 @ 11:49:
Elk data pakketje over een netwerkinterface heeft een bepaalde grootte. Je kan dan dus simpelweg instellen dat er maximaal N pakketjes over de lijn per seconde mogen gaan. Na dat aantal pakketjes knijp je ze gewoon af (queue niet processen) totdat je bij de volgende seconde bent.

Dit is precies zoals de eerste kabel internet verbindingen geknepen werden... Een eenvoudige workaround was dan ook het vergroten van de packets... heel veel van die programmaatjes die zogenaamd het cable modem boosten doen niets anders dan zorgen dat er grotere packets verstuurd worden.

Als je het op deze manier wilt doen moet je dus wel uitgaan van een maximale packet size.