Ermitteln der aktuellen Bandbreite
-
Guten Morgen an alle,
ich hab da mal die Frage, ist es möglich mit den Windows Sockets die aktuelle Bandbreite zu ermitteln?
Bevor ich ein Paket versenden möchte ich wissen wie groß die Latenzzeit für ein Paket (z.B. 160 Byte groß über UDP) ist. Dadurch will ich erreichen das ich immer berechnen kann wie groß die Wartezeit ist bevor ich das nächste Paket absende.Hoffe man versteht was ich meine, wenn nicht Fragen;)
Besten Dank im voraus und Beste Grüße
-
Man kann zur Laufzeit bestimmte Funktionszeiten messen. Nichts anderes muesstest du tun: Du musst ein entspr. Paket senden, auf eine Antwort warten, und die dazwischenliegende Zeit messen. Das kannst du entsprtechend hochrechnen. Je groesser die Pakete oder je mehr Pakete es sind, die du misst, umso sicherer ist die Angabe. Wenn du z.B. ein 160Byte-Paket misst und das auf 1 GB hochrechnest, kannst du dir sicher denken, dass die Angabe mehr als ungenau ist.
Die Latenzzeit aendert sich uebrigens nicht proportional zur Datenmenge, sondern sie bleibt gleich oder schwankt allgemein auf der Datenleitung. Die Bandbreite kann man nur zur Laufzeit messen, es gibt keine Moeglichkeit der Vorberechnung / Schaetzung.
-
Problem ist das es sich um Echtzeitdaten handelt, worauf ich keine Antwort erhalte. Müsste ich also praktisch ein Dummy Paket versenden welches auch eine Anwort erhält und daraus dann die Dauer nehmen um zu schätzen wie groß die Pause sein muss???
-
Fakt ist, dass sich nunmal nur Live-Daten messen lassen. Ansonsten kannst du nur von konstanten Faktoren ausgehen, wie theoretische Bandbreite Client und Server. Diese muesstest du erstmal erfragen.
-
Was genau willst du machen?
Latenz und Bandbreite sind 2 komplett unterschiedliche Sachen.Wenn es dir um niedrige Latenz geht: pumpe über UDP soviele Daten wie geht und die Gegenstelle verwirft die veralteten Pakete einfach.
-
Also mein eigentliches Problem ist, ich habe eine Echtzeitanwendung der ich via RTP Audiodaten senden. Jedes Paket ist 160 Byte + RTP/UDP/IP groß. Nun scheint es irgendwo ein Problem zu geben. Mache ich bei mir ein Sleep rein mit 20ms bevor das nächste Paket versendet wird dann werden die Audioframes auch korrekt abgespielt(Empfänger: VoIP Phone bzw. VoIP Client). Setze ich den Sleep auf 15ms runter dann werden die Daten zu schnell abgespielt bzw setze ich ihn auf 0 wird so schnell abgespielt das man nur Bruchstückhaft mitbekommt das überhaupt was überkommt. Setze ich Sleep auf z.B. 30ms dann kommt am anderen Ende nur eine leiernde Ausgabe heraus. Timestamp und SequenceNo der RTP Pakete sind korrekt gesetzt, daher weiß ich nicht mehr woran es noch liegen könnte.
Da aber in anderen Netzen die Geschwindigkeit varrieren kann und die 20ms Pause vllt. zuviel ist wollte ich halt die Übertragungsverzörgerung der einzelnen Pakete dynamisch anhand der Bandbreite setzen, so das es in jedem Netz funzt.Hab RTP aber bei meiner Anfrage rausgehalten gehabt, da sobald ich das Protokoll bei Anfragen mit ins Spiel bringe keine Antworten kommen .
Gruß
-
Dann läuft irgendwas anderes Schief.
Das Protokoll muss auf unterschiedlich schnell eintreffende Pakete reagieren können (RTP ist ja ein Industrie Standard). Es darf also nicht an einem Sleep oder ähnlichen liegen.
Gerade wenn es mobile Geräte sind kann es sehr leicht zu Latenzschwankungen kommen (und ich meine von 10ms auf 2000ms und dergleichen). Hab mal kurz in RTP reingelesen und der Timestamp im Header scheint doch genau dem vorzubeugen was du hier hast: die Pakete werden abgespielt wie sie ankommen und nicht in der korrekten Frequenz.
-
Also das seltsame ist, dass ich bereits einen VoIP Client entwickelt habe mit dem ich die RTP Pakete genauso versende wie ich es mit der jetzigen Applikation mache. Dort funktioniert es wunderbar. Deshalb habe ich den Timesamp ausgeschlossen. Recht hast du aber auch mit dem dass der empfange Part dies handeln können sollte. Wie gesagt mit meinem Client kriegt er das auch hin...
Darum bin ich momentan eher ratlos.
