TCP/IP (Winsock) maximale Downloadgeschwindigkeit vom Server verlangen

Naja das ist es eben, ich habe die TCP-Theorie verstanden(naja grob zumindest), man kann die Paketgröße im Header bestimmen, aber in welchem Interval diese Pakete gesendet werden ist mir bis jetzt unklar. Also wenn ich die Paketgröße von 50Bytes festlege kann es doch sein, daß ich in der Sekunde 2 Pakete von je 50Bytes empfange wenn meine Bandbreite es zulässt...

Headhunter

Hallo!

Dem Server kannst du nichts sagen, der schickt und schickt und schickt..

Schau mal hier: http://azureus.sourceforge.net/faq.php#6
Vielleicht helfen dir dir Links/der Sourcecode

Dann muss ich wohl selbst nur eine bestimmte/maximale Anzahl an Bytes im gewünschten Interval bestätigen und nicht gleich nach dem Empfang? Naja ich sollte Quellcodes anschauen wie die das machen eMule z.B.
@Headhunter auf der Seite bieten sie leider nur fertige Programme an, die die Geschwindigkeit anzeigen/minimieren.

net 0

Strogij schrieb:

ich sollte Quellcodes anschauen wie die das machen eMule z.B.

das hilft dir aber nicht weiter, wenn du downloads über ftp oder http machen willst. emule benutzt eigene protolle dafür (dieses e-donkey zeug etc.).

btw:
1. im tcp header befindet sich ein feld 'window size'. damit teilt dein tcp dem anderen mit, wieviel es senden darf, also wieviel platz in deinem buffer noch ist. dieser wert ist aber sehr dynamisch und man hat keinen direkten einfluss drauf.

2. bei der verbindungsaufnahme tauschen die tcp's eine option aus 'maximum segment size (mss)'. wenn dein tcp diesen wert zu klein wählt, kann es passieren, dass downloads langsam sind (jedes segment erfordert ein 'ack'). unglücklicherweise ist die mss abhängig vom unteren layer, also ppp oder ethernet d.h. ist meistens knapp unter 1500 bytes gross. kann sein, dass dein betriebssystem eine einstellmöglichkeit für diesen wert hat. sollte der unter 1400irgendwas sein, könntest du ihn erhöhen, aber die wahrscheinlichkeit ist nicht gross, dass das viel bringt (es sei den der steht bei 512 oder so).

3. tcp hat keine 'quality of service' option.

Hmm aber wie machen es dann die Downloadmanager? Verstehe es jetzt nicht.
Du sagst das hilft mir nicht im Falle von z.B. HTTP oder eMule, aber diese Sachen benutzen doch alle (meistens) TCP, um eine Verbindung herzustellen, HTTP ist demnach ein virtuelles (Unter-)Protokoll, baut also auf TCP. Da hast du dich wohl geirrt.

net 0

Strogij schrieb:

Hmm aber wie machen es dann die Downloadmanager? Verstehe es jetzt nicht.

weiss auch nicht, wie die das machen. irgendwie machen die mehrere verbindungen auf aber jede verbindung beginnt ja wieder von vorne mit dem download. anders bei emule o.ä. die saugen pro verbindung von einem anderen offset der datei, also nix doppelt.

Strogij schrieb:

Du sagst das hilft mir nicht im Falle von z.B. HTTP oder eMule, aber diese Sachen benutzen doch alle (meistens) TCP, um eine Verbindung herzustellen, HTTP ist demnach ein virtuelles (Unter-)Protokoll, baut also auf TCP.

http benutzt tcp als transport layer. das emule-protokoll wohl auch (muss aber nicht). aber man kann tcp kaum sagen 'wie' es die daten holen soll (obwohl es gibt einige socket options und ioctls) aber man kann es doch nur als stream benutzen und ihm nicht grossartig vorschreiben, 'wie' es daten zu versenden/empfangen hat

Unix-Tom

Ich glaube du hast da was falsch verstanden.

Wenn du eine Anfrage an den Server sendest das du z.B. ein File haben willst dann sendet der Server deinem Rechner das File mit der maximalen Geschwindigkeit des langsamsten der beiden. (In der Regel dein Rechner und nicht der Server)
Das kannst du nicht beeinflüssen außer du verlangsamst deine Leitung.
Ein Programm (Client) holt sich nicht von Server die Daten.
Die Daten werden von eigenen Rechner abgeholt.
Die Daten selbst werden im Kernel abgespeichert da dieser die unetrste Schicht ist.

Im Grunde siehst es so aus das Packete auf deiner Netzwerkkarte ankommen. Dieser Pakcete gibt es viele. Insbesondere in einem lokalen Netzwerk.
Der Kernel entscheidet nun ob das Packet für ihn bestimmt ist. Wenn nein ignoriert er es. Wenn ja sucht er seinen passenden Speicherbereich dazu und legt das Packet dort ab. Der Client holt über die API diese Daten.

Wenn du selbst eine Server hast dann kannst du den Trasfer einschränken indem du einfach mal eine Pause beim senden machst.
Darus errechnet sich dann die Transferrate/Sekunde.

Ja Tomy, du hast schon Recht aber die Frage ist/bleibt nur: wie zum Geier schaffen es Programme wie FlashGet? Ich habe die halbe Welt abgesucht und in anderen Foren hat keiner auf ähnliche Frage antworten können...

vineon

Wahrscheinlich empfangen diese Programme die Daten nur so schnell von z.B. winsock, wie es eingestellt ist. Irgendwann ist der interne Vorhaltecache voll (windowsize!) und die Socketimplementation setzt den Empfang weiterer Pakete aus bis dieser wieder halbwegs leer ist.

Ich glaube ich habe die Antwort: Mit dem Congestion-Control Algorithmus wird die maximale Bandbreite des Clients schrittweise erkannt (dazu Google nach Congestion-Control + TCP). Ob man nun über winsock diese Informationen manipulieren kann ist eine andere Frage.

Headhunter

Die Programme auf die ich verwiesen habe sind alle OpenSource, deshalb auch der Hinweis sich den Quellcode anzuschauen.
Da hättest du schonmal drei Beispielimplementierungen wies geht.

Eine Netzwerklib die Up und Downstreambeschränkung hat, ist "enet" (http://enet.cubik.org/), ist zwar für UDP aber vielleicht findest du dort etwas.

Der Downloadmanager "wget" hat auch eine Downloadbeschränkung und ist OpenSource.