HTTP POST?

Ulli Horlacher

unread,

May 31, 2019, 2:04:32 PM5/31/19

to

Prolog: Ich hab nur rudiementaer Ahnung von Javascript.

Um die upload-Geschwindigkeit zu testen, wuerde ich gerne ein HTTP POST
mit dummy-Daten machen. Also kein echtes file upload, sondern nur
Null-Daten schicken, ohne sie von Platte zu lesen.

"Click here to test your upload speed"
----------

Das soll dann den dummy HTTP POST machen mit XX MB.

Wie wuerde man das angehen?

Bisher lass ich die user eine lokale Datei selektieren um die zu
verschicken. Viele User sind aber mit dieser Aktion ueberfordert :-}
"Was soll ich jetzt auswaehlen?! HILFAE!"

--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: horl...@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: http://www.tik.uni-stuttgart.de/

Thomas 'PointedEars' Lahn

unread,

May 31, 2019, 3:03:07 PM5/31/19

to

Ulli Horlacher wrote:

> Prolog: Ich hab nur rudiementaer Ahnung von Javascript.

Es gibt kein "Javascript":

<http://PointedEars.de/es-matrix>

> Um die upload-Geschwindigkeit zu testen, wuerde ich gerne ein HTTP POST
> mit dummy-Daten machen. Also kein echtes file upload, sondern nur
> Null-Daten schicken, ohne sie von Platte zu lesen.
>
> "Click here to test your upload speed"
> ----------
>
> Das soll dann den dummy HTTP POST machen mit XX MB.
>
> Wie wuerde man das angehen?

<https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest>

<https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWorkerGlobalScope/fetch>

Allerdings: <https://www.speedtest.net/>

--
PointedEars
FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

Arno Welzel

unread,

Jun 1, 2019, 7:18:56 AM6/1/19

to

Thomas 'PointedEars' Lahn:

> Ulli Horlacher wrote:
>
>> Prolog: Ich hab nur rudiementaer Ahnung von Javascript.
>
> Es gibt kein "Javascript":

Besser: "Die offizielle Schreibweise ist JavaScript."

--
Arno Welzel
https://arnowelzel.de

Thomas 'PointedEars' Lahn

unread,

Jun 1, 2019, 8:15:09 AM6/1/19

to

Arno Welzel wrote:

> Thomas 'PointedEars' Lahn:
>> Ulli Horlacher wrote:
>>> Prolog: Ich hab nur rudiementaer Ahnung von Javascript.
>> Es gibt kein "Javascript":
>
> Besser: "Die offizielle Schreibweise ist JavaScript."

Nein, das ist nicht besser, denn es sagt etwas anderes (Falsches) aus.
Siehe auch der von Dir nicht zitierte URI.

Arno Welzel

unread,

Jun 1, 2019, 8:34:39 AM6/1/19

to

Thomas 'PointedEars' Lahn:

> Arno Welzel wrote:
>
>> Thomas 'PointedEars' Lahn:
>>> Ulli Horlacher wrote:
>>>> Prolog: Ich hab nur rudiementaer Ahnung von Javascript.
>>> Es gibt kein "Javascript":
>>
>> Besser: "Die offizielle Schreibweise ist JavaScript."
>
> Nein, das ist nicht besser, denn es sagt etwas anderes (Falsches) aus.

Nein, das ist nicht falsch.

> Siehe auch der von Dir nicht zitierte URI.

Da - <http://pointedears.de/scripts/test/es-matrix/> - steht es ja genau
so drin:

"ECMAScript is a standard for object-oriented programming languages.
Superficially, its implementations, like JavaScript (...)".

Oder sollte man auch nicht über die Implementierung JavaScript sprechen,
sondern nur von ECMAScript?

Arno Welzel

unread,

Jun 1, 2019, 8:37:41 AM6/1/19

to

Arno Welzel:

Ergänzung: Du schreibst unter der o.G. URL auch, Zitat:

In fact, there is no “javascript”; there is JavaScript.

(Zitat Ende)

Warum ist also falsch, wenn jemand "Javascript" schreibt und man ihn
darauf hinweist, dass der Name der Implementierung offiziell
"JavaScript" heißt?

Ralph Aichinger

unread,

Jun 1, 2019, 9:11:18 AM6/1/19

to

Arno Welzel <use...@arnowelzel.de> wrote:
> Oder sollte man auch nicht über die Implementierung JavaScript sprechen,
> sondern nur von ECMAScript?

Ich habe tagtäglich mit Frontendlern zu tun, und die sprechen eigentlich
sowohl mir gegenüber als auch untereinander immer von JavaScript, nie
von ECMAScript, wobei zumindest untereinander ihnen klar ist, daß alle
Beteiligten wüßten was ECMAScript ist, und es auch von mir verstanden würde.

Wie ist das bei euch wenn ihr euch mit anderen unterhaltet?

/ralph
--
-----------------------------------------------------------------------------
https://aisg.at
ausserirdische sind gesund

Arno Welzel

unread,

Jun 1, 2019, 9:44:23 AM6/1/19

to

Ralph Aichinger:

> Arno Welzel <use...@arnowelzel.de> wrote:
>> Oder sollte man auch nicht über die Implementierung JavaScript sprechen,
>> sondern nur von ECMAScript?
>
> Ich habe tagtäglich mit Frontendlern zu tun, und die sprechen eigentlich
> sowohl mir gegenüber als auch untereinander immer von JavaScript, nie
> von ECMAScript, wobei zumindest untereinander ihnen klar ist, daß alle
> Beteiligten wüßten was ECMAScript ist, und es auch von mir verstanden würde.
>
> Wie ist das bei euch wenn ihr euch mit anderen unterhaltet?

Ich kenne das bislang auch nicht anders.

JFTR: Auf <http://pointedears.de/scripts/test/es-matrix/> meckert
Firefox 67.0 hier mit mehreren Warnungen:

In
<http://pointedears.de/scripts/test/es-matrix/application/scripts/object/object-compat.js>,
Zeile 413:

[anonymous Function].extend(undefined, [object Object]): Parent
constructor is undefined, using Object
jsx_warn@http://pointedears.de/scripts/test/es-matrix/application/scripts/object/object-compat.js:450:14
Function.prototype.extend@http://pointedears.de/scripts/test/es-matrix/application/scripts/object/object-compat.js:2523:14
@http://pointedears.de/scripts/builder?src=test/es-matrix/application/scripts/es,engine,dom/xpath,test/es-matrix/application/scripts/debug,http,string/hyphenation,dom,dom/css,dom/events,dom/forms,dom/widgets:7945:22

In
<http://pointedears.de/scripts/builder?src=test/es-matrix/application/scripts/es,engine,dom/xpath,test/es-matrix/application/scripts/debug,http,string/hyphenation,dom,dom/css,dom/events,dom/forms,dom/widgets>,
Zeile 5205:

Synchrone XMLHttpRequests am Haupt-Thread sollte nicht mehr verwendet
werden, weil es nachteilige Effekte für das Erlebnis der Endbenutzer
hat. Für weitere Hilfe siehe http://xhr.spec.whatwg.org/

Thomas 'PointedEars' Lahn

unread,

Jun 1, 2019, 10:07:02 AM6/1/19

to

Ralph Aichinger wrote:

> Arno Welzel <use...@arnowelzel.de> wrote:
>> Oder sollte man auch nicht über die Implementierung JavaScript sprechen,
>> sondern nur von ECMAScript?

Der Punkt ist (zum zigsten Mal): Es gibt nicht nur *eine* verbreitete
Implementierung von ECMAScript, und die Implementierungen unterscheiden
sich voneinander (heute weniger als früher, aber trotzdem).

> Ich habe tagtäglich mit Frontendlern zu tun,

*wink*

> und die sprechen eigentlich sowohl mir gegenüber als auch untereinander
> immer von JavaScript, nie von ECMAScript, wobei zumindest untereinander
> ihnen klar ist, daß alle Beteiligten wüßten was ECMAScript ist, und es
> auch von mir verstanden würde.

Ja, *als* *Kurzform*.

> Wie ist das bei euch wenn ihr euch mit anderen unterhaltet?

Das kommt darauf an, wer der/die andere ist.

Erschwerend kommt heutzutage hinzu, wie ich ja auch auf meiner Website und
schon in meiner Bachelorarbeit von 2011/2012 schreibe, dass es nicht nicht
nur eine ECMAScript-Implementierung gibt, sondern auch nicht mehr nur eine
Implementierung, die ganz offiziell “JavaScript” im Namen hat. (Dass
Microsoft JScript nun in der MSDN Library “JavaScript for Internet Explorer”
genannt wird, ist IMHO reines Marketing; aber zum Beispiel die Bezeichnung
“(Google) V8 JavaScript” hat durchaus ihre Berechtigung.)

Das sind eben *verschiedene* Sprachebenen und Situationen.

Hierzugruppe und in der Öffentlichkeit überhaupt muss man davon ausgehen
(und im konkreten Fall war es ja so), dass Anfänger mitlesen. Daher war
der Hinweis auf die irreführend-falsche Terminologie angezeigt.

Das hab’ ich (Arno Welzel) auch schon /ad nauseam/ erklärt.
Soifz. [psf 10.1]

Thomas 'PointedEars' Lahn

unread,

Jun 1, 2019, 12:43:42 PM6/1/19

to

Arno Welzel behauptete denselben Stuss zum zigsten Mal:

> Thomas 'PointedEars' Lahn:
>> Arno Welzel wrote:
>>> Thomas 'PointedEars' Lahn:
>>>> Ulli Horlacher wrote:
>>>>> Prolog: Ich hab nur rudiementaer Ahnung von Javascript.
>>>> Es gibt kein "Javascript":
>>> Besser: "Die offizielle Schreibweise ist JavaScript."
>> Nein, das ist nicht besser, denn es sagt etwas anderes (Falsches) aus.
>
> Nein, das ist nicht falsch.

Doch, das IST falsch, denn es gibt keine Programmiersprachen namens
“javascript”, und mit “javascript” ist typischerweise nicht nur
Netscape/Mozilla JavaScript oder überhaupt Sprachen, die “JavaScript” im
Namen haben gemeint. Das ist ja das Problem: PLANLOSERWEISE wird von
Wannabes alles in einen Topf geworfen!

>> Siehe auch der von Dir nicht zitierte URI.
>
> Da - <http://pointedears.de/scripts/test/es-matrix/> - steht es ja genau
> so drin:

Nein, das tut es nicht! Ich werde ja wohl noch wissen, was ich geschrieben
und wie ich es gemeint habe!

> "ECMAScript is a standard for object-oriented programming languages.
> Superficially, its implementations, like JavaScript (...)".

^^^^^^^^^^^^^
“[…] and JSCript, […]”

> Oder sollte man auch nicht über die Implementierung JavaScript sprechen,
> sondern nur von ECMAScript?

Bist Du senil? Wie oft muss ich es Dir jetzt noch erklären?

“like” ist in diesem Zusammenhang die englische Wendung für „wie zum
Beispiel“. Übersetzt also, so geschrieben dass es auch der letzte Idiot
merkt:

„ECMAScript ist ein Standard für objektorientierte Programmiersprachen.
OBERFLÄCHLICH BETRACHTET sind seine ImplementierungEN, WIE ZUM BEISPIEL
JavaScript UND JScript […]“

„[…] sehr ÄHNLICH. Sie werden daher oft in VEREINFACHENDER Weise
diskutiert. Aber HÄLT DIESER ANSATZ EINER GENAUEREN ÜBERPRÜFUNG STAND?“.

Da steht auch “implementationS”, „ImplementierungEN“. Plural. MEHRzahl.
Und mit “JavaScript” ist Netscape/Mozilla JavaScript gemeint (im Unterschied
zu MICROSOFT JScript).

Im übrigen ist das meine Übersetzung ins Englische der Zusammenfassung
(Abstract) *meiner* Bachelorarbeit von 2011/2012 (Fussnote 1). Diese habe
ich auf Deutsch geschrieben.

Wer lesen kann, ist hier klar im Vorteil!

kopfschüttelnd,

Arno Welzel

unread,

Jun 1, 2019, 2:17:08 PM6/1/19

to

Thomas 'PointedEars' Lahn:

> Ralph Aichinger wrote:
>
>> Arno Welzel <use...@arnowelzel.de> wrote:
>>> Oder sollte man auch nicht über die Implementierung JavaScript sprechen,
>>> sondern nur von ECMAScript?
>
> Der Punkt ist (zum zigsten Mal): Es gibt nicht nur *eine* verbreitete
> Implementierung von ECMAScript, und die Implementierungen unterscheiden
> sich voneinander (heute weniger als früher, aber trotzdem).

Habe ich das irgendwo bezweifelt?

Es ist in erster Näherung unwahrscheinlich, dass die Frage des OP zu
ECMAScript allgemein war, sondern zu einer Implementierung in Browsern -
und die wird von wenigen Ausnahmen abgesehen nun mal JavaScript genannt.

[...]

> Hierzugruppe und in der Öffentlichkeit überhaupt muss man davon ausgehen
> (und im konkreten Fall war es ja so), dass Anfänger mitlesen. Daher war
> der Hinweis auf die irreführend-falsche Terminologie angezeigt.
>
> Das hab’ ich (Arno Welzel) auch schon /ad nauseam/ erklärt.
> Soifz. [psf 10.1]

Das glaube ich Dir nicht. Du wirst auch in Zukunft noch dutzende oder
hunderte Male das selbe sagen und nicht akzeptieren, dass jeder außer
Dir kein Problem damit hat, von "JavaScript" zu sprechen und auch sehr
gut zu verstehen, was damit gemeint ist.

Arno Welzel

unread,

Jun 1, 2019, 2:19:45 PM6/1/19

to

Thomas 'PointedEars' Lahn:

> Arno Welzel behauptete denselben Stuss zum zigsten Mal:
>
>> Thomas 'PointedEars' Lahn:
>>> Arno Welzel wrote:
>>>> Thomas 'PointedEars' Lahn:
>>>>> Ulli Horlacher wrote:
>>>>>> Prolog: Ich hab nur rudiementaer Ahnung von Javascript.
>>>>> Es gibt kein "Javascript":
>>>> Besser: "Die offizielle Schreibweise ist JavaScript."
>>> Nein, das ist nicht besser, denn es sagt etwas anderes (Falsches) aus.
>>
>> Nein, das ist nicht falsch.
>
> Doch, das IST falsch, denn es gibt keine Programmiersprachen namens
> “javascript”, und mit “javascript” ist typischerweise nicht nur

Wo habe ich von "javascript" geschrieben?

Ich sagte "Die offizielle Schreibweise ist JavaScript."

> Netscape/Mozilla JavaScript oder überhaupt Sprachen, die “JavaScript” im
> Namen haben gemeint. Das ist ja das Problem: PLANLOSERWEISE wird von
> Wannabes alles in einen Topf geworfen!

Dein Problem.

>>> Siehe auch der von Dir nicht zitierte URI.
>>
>> Da - <http://pointedears.de/scripts/test/es-matrix/> - steht es ja genau
>> so drin:
>
> Nein, das tut es nicht! Ich werde ja wohl noch wissen, was ich geschrieben
> und wie ich es gemeint habe!

Du hast "JavaScript" als Implementierung erwähnt:

>> "ECMAScript is a standard for object-oriented programming languages.
>> Superficially, its implementations, like JavaScript (...)".
> ^^^^^^^^^^^^^
> “[…] and JSCript, […]”
>
>> Oder sollte man auch nicht über die Implementierung JavaScript sprechen,
>> sondern nur von ECMAScript?
>
> Bist Du senil? Wie oft muss ich es Dir jetzt noch erklären?

Also was jetzt? Soll man nur noch ECMAScript schreiben oder nicht?

Arno Welzel

unread,

Jun 1, 2019, 4:46:05 PM6/1/19

to

Arno Welzel:

> Thomas 'PointedEars' Lahn:
>
>> Arno Welzel behauptete denselben Stuss zum zigsten Mal:

[...]

>>> Oder sollte man auch nicht über die Implementierung JavaScript sprechen,
>>> sondern nur von ECMAScript?
>>
>> Bist Du senil? Wie oft muss ich es Dir jetzt noch erklären?
>
> Also was jetzt? Soll man nur noch ECMAScript schreiben oder nicht?

Ergänzend: <https://developer.mozilla.org/de/docs/Web/JavaScript>

Also - wie soll man es nennen, wenn man eine Frage zur Umsetzung eines
Scripts hat, was innerhalb eines Browser wie Firefox, Vivaldi oder
Chrome ausgeführt wird? Die jeweilige Implementierung des Browsers, die
auch "JavaScript" heißen kann oder ausschließlich "ECMAScript"?

Thomas 'PointedEars' Lahn

unread,

Jun 1, 2019, 10:06:52 PM6/1/19

to

Arno Welzel wrote:

> Thomas 'PointedEars' Lahn:
>> Arno Welzel behauptete denselben Stuss zum zigsten Mal:
>>> Thomas 'PointedEars' Lahn:
>>>> Arno Welzel wrote:
>>>>> Thomas 'PointedEars' Lahn:
>>>>>> Ulli Horlacher wrote:
>>>>>>> Prolog: Ich hab nur rudiementaer Ahnung von Javascript.

^^^^^^^^^^

>>>>>> Es gibt kein "Javascript":
>>>>> Besser: "Die offizielle Schreibweise ist JavaScript."
>>>> Nein, das ist nicht besser, denn es sagt etwas anderes (Falsches) aus.
>>> Nein, das ist nicht falsch.
>> Doch, das IST falsch, denn es gibt keine Programmiersprachen namens
>> “javascript”, und mit “javascript” ist typischerweise nicht nur
>
> Wo habe ich von "javascript" geschrieben?

Der OP hat es aber, nur eben mit “Javascript” (sic). Das ist nur leicht
anders falsch.

Zugrunde liegt dieselbe falsche Vorstellung: Es gäbe *eine*
Programmiersprache namens “Javascript”, die überall gleich sei (oder
"Dialekte" habe und sich nur *deshalb* in unterschiedlichen Umgebungen
voneinander unterschiede).

Widrigenfalls enthält diese Phantomsprache dann auch noch alle Host-Objekte,
d. h. konzeptuell fehlt auch noch das Verständnis des Unterschieds zwischen
eingebauten, nativen und Host-Objekten – da kommen dann meist Dinge wie
“window”, “document” und “getElementById”, die NICHT Teil *irgendeiner*
Programmiersprache sind, aber deren angebliches "Nichtfunktionieren" dann
eben dieser Phantomsprache angelastet werden. Hab’ ich alles schon gesehen.
Nervig.

Im aktuellen Fall ist dieses Missverständnis nicht (grösstenteils) dem OP
anzulasten; wenn man zu dem Thema oberflächlich oder gar nicht recherchiert,
findet man einfach haufenweise Unsinn von Wannabes.

Leider inzwischen auch in Büchern: Viele, die nur halb verstanden haben, was
sie tun, glauben, die Materie vollständig durchdrungen zu haben und sich mit
dem Schreiben eines Buchs einen Namen/Geld machen (oder, wenn man Altruismus
unterstellt, anderen etwas erklären und ihnen damit helfen) zu können.

Sofort fallen mir da David Flanagan (“JavaScript: The Definitive Guide”),
John Resig (jQuery und diverse Bücher mit “Ninja” und “Professional” im
Titel – klare Warnsignale) und Douglas Crockford (“JavaScript: The Good
Parts”) ein. Flanagan steckt irgendwie seit Jahrzehnten in einer Zeitkapsel
fest und hat nicht verstanden, dass es überhaupt nicht *nur* Netscape
JavaScript gibt (statt neue Editionen des immer gleichen falschen Buchs
herauszubringen, sollte er endlich mal sauber recherchieren und ein neues
Buch schreiben); Resig hatte zumindest bei der letzten Überprüfung den
Unterschied zwischen den Implementierungen nicht verstanden – obwohl ihm
offenbar klar ist, dass es verschiedene Umgebungen gibt; und Crockford hat
offenbar bis heute mindestens nicht den Unterschied zwischen Sprache und DOM
verstanden (also auch irgendwie ein Zeitkapsel-Syndrom – damals gab es den
Unterschied so noch nicht). Im deutschsprachigen Usenet ist Stefan Ram so
ein offenbar hoffnungsloser Fall, der (mangels Kritik*fähigkeit*) nicht
versteht, dass er sich mit Mozilla JavaScript nur noch mit einer
Randerscheinung beschäftigt; das wahre Leben spielt sich heute vor allem –
bei > 60 % weltweitem Marktanteil für Chrome [insgesamt, und Desktop und
Mobile separat¹] vs. < 6 % für Firefox – in V8 JavaScript ab. Die armen
Volkshochschüler; sie werden feststellen müssen, dass sie so gut wie nichts
von dem bei ihm "Gelernten" – falls man mit solchen Zeichenwüsten überhaupt
etwas lernen kann – IRL später gebrauchen können.)

[Nein, ich habe kein Buch geschrieben und werde auch keins schreiben,
jedenfalls jetzt nicht – habe derzeit anderes, Interessanteres zu tun.
(Eigentlich auch Wichtigeres als dieses Posting, zum Beispiel
schlafen – aber es musste wohl mal raus.)]

________
¹ <http://gs.statcounter.com/browser-market-share>

> Ich sagte "Die offizielle Schreibweise ist JavaScript."

Und das ist *falsch*, denn es impliziert *in diesem Kontext*, dass es *eine*
(1) Programmiersprache gäbe, die “javascript” genannt wird, deren offizielle
Schreibweise aber „JavaScript“ ist.

Eine solche Sprache gibt es aber nicht, denn die Leute, die “javascript”
schreiben, haben gar keine Ahnung, was sie damit meinen. Sie haben
ungesundes Halbwissen: sie wissen nicht, was sie nicht wissen. Ihnen ist
nicht klar oder sie wollen aufgrund Bequemlichkeit nicht akzeptieren, dass
das, was sie ”javascript” (oder “Javascript”) nennen, ein Konglomerat aus
sich *voneinander unterscheidenden* Implementierungen von ECMAScript ist
(manchmal sogar standardwidrige), und dass das Ganze mit Host-Objekten nur
insofern zu tun hat, als dass die jeweilige ECMAScript-Implementierung den
Zugriff auf diese Objekte ermöglicht.

>> Netscape/Mozilla JavaScript oder überhaupt Sprachen, die “JavaScript” im
>> Namen haben gemeint. Das ist ja das Problem: PLANLOSERWEISE wird von
>> Wannabes alles in einen Topf geworfen!
>
> Dein Problem.

Nein, es ist Deins, denn Du begehst genau diesen Fehler.
Und zwar leider *immer* *wieder*. Siehe oben.

>>>> Siehe auch der von Dir nicht zitierte URI.
>>> Da - <http://pointedears.de/scripts/test/es-matrix/> - steht es ja genau
>>> so drin:
>>
>> Nein, das tut es nicht! Ich werde ja wohl noch wissen, was ich
>> geschrieben und wie ich es gemeint habe!
>
> Du hast "JavaScript" als Implementierung erwähnt:

Und ich habe jetzt zum wiederholten Mal geschrieben, dass das eine
ZUSAMMENFASSUNG meiner Bachelorarbeit ist, und ich an dieser Stelle
NETSCAPE (heute: Mozilla) JavaScript meine, weil ich es zusammen
mit einem weiteren BEISPIEL, MICROSOFT JScript, nenne.

Dies deswegen, weil Netscape/Mozilla JavaScript und Microsoft JScript lange
Zeit (und 2012, v.a. über die entsprechenden Web-Browser) die beiden
verbreitetsten Implementierungen von ECMAScript waren², und die Grundlagen
für die erste Edition der ECMAScript Language Specification (niemand – nicht
Netscape und nicht Microsoft – wollte etwas aufgeben – Netscape nicht ihr
Original und Microsoft nicht ihre angepasste Kopie –, man wollte aber auch
einen Industriestandard, damit es kein komplettes Chaos im Web gibt; also
standardisierte man den kleinsten gemeinsamen Nenner).

Steht alles in meiner Bachelorarbeit auf Deutsch. Lies sie einfach
(endlich)!

________
² <http://gs.statcounter.com/browser-market-share#monthly-200901-201202>

>>> "ECMAScript is a standard for object-oriented programming languages.
>>> Superficially, its implementations, like JavaScript (...)".
>> ^^^^^^^^^^^^^
>> “[…] and JSCript, […]”
>>
>>> Oder sollte man auch nicht über die Implementierung JavaScript sprechen,
>>> sondern nur von ECMAScript?
>>
>> Bist Du senil? Wie oft muss ich es Dir jetzt noch erklären?
>
> Also was jetzt? Soll man nur noch ECMAScript schreiben oder nicht?

Nochmal für Einzeller (siehe BAfH³):

Man soll ECMAScript schreiben, wenn man ECMAScript meint. Also sich zum
Beispiel auf Features, die in einer Edition der ECMAScript Language
Specification definiert sind, bezieht oder die nach bestem Wissen in allen
Sprachen, die sich Implementierungen von ECMAScript nennen, gleich sind.

Man *kann* heutzutage auch *nur* “JavaScript” schreiben, wenn man damit
exakt alle Sprachen meint, die “JavaScript” im Namen haben; dann muss man
das aber auch klar schreiben. Ich zum Beispiel habe gelegentlich den
Begriff “JavaScript*s*” für das verwendet, was (nach meiner Analyse, die man
eben z. B. in der “ECMAScript Support Matrix” aufgelistet findet)
Netscape/Mozilla JavaScript, Google V8 JavaScript, Apple JavaScriptCore und
KDE JavaScript gemeinsam haben. (Das ist vermutlich auch nicht ganz
korrekt, dies sind oder waren aber die verbreitetsten Implementierungen im
Web-Bereich, um den es meist und in *.comp.lang.javascript ohne weitere
Angaben geht.)

In allen anderen Fällen sollte man genau schreiben, welche
Implementierung(en) (und damit auch welche Laufzeitumgebung[en]) man meint.

Siehe auch den Abschnitt “The same, but not the same” („Gleich und doch
nicht gleich“) der “ECMAScript Support Matrix”.

Wenn das jetzt *immer noch nicht* klar ist, lies einfach *genau* hin,
*beachte den Kontext*, und schreib es so, wie ich es *in dem jeweiligen
Kontext* geschrieben habe. Mir ist kein Fall bekannt, wo ich von obiger
Regel abgewichen bin.

______
³ <https://de.wikipedia.org/wiki/Bastard_Assistant_from_Hell>
<http://www.bas-services.de/basvs/BAND5.html>

Thomas 'PointedEars' Lahn

unread,

Jun 1, 2019, 11:02:56 PM6/1/19

to

Arno Welzel wrote:

> Ergänzend: <https://developer.mozilla.org/de/docs/Web/JavaScript>

Das ist *auch* ein *Wiki*. Schlimmer noch: es ist die unvollständige
Übersetzung eines umfangreicheren englischsprachigen Wikis¹. Jeweils
geschrieben für Anfänger und inzwischen grösstenteils (so jedenfalls mein
Eindruck) auch *von* Anfängern.

(Das macht es nicht /per se/ schlechter – ich als Experte trage gelegentlich
selbst dazu bei – aber es ist auch einfacher, darin Aussagen von Leuten zu
finden, die keine Ahnung haben. Daher sind alle unbelegten Aussagen und
Behauptungen mit Vorsicht zu geniessen – so wie eigentlich immer.)

_________
¹ <https://developer.mozilla.org/en-US/docs/Web/JavaScript>

> Also - wie soll man es nennen, wenn man eine Frage zur Umsetzung eines
> Scripts hat, was innerhalb eines Browser wie Firefox, Vivaldi oder
> Chrome ausgeführt wird?

Firefox basiert auf Mozilla Gecko; er unterstützt deshalb Mozilla JavaScript
und das Gecko DOM.

Google Chrome und Vivaldi basieren auf WebCore/Blink und Chrome V8; sie
unterstützen deshalb Chrome V8 JavaScript und das WebCore/Blink DOM.
Ob WebCore oder Blink hängt von der Browserversion ab (neu: Blink).

Beide Programmiersprachen implementieren eine Edition von ECMAScript.
Welche und in welchem Ausmass hängt von der Sprachversion bzw. der Version
der Script-Engine und damit von der Browserversion ab (aktuell: 9. Ed. aka
ES 2018; bin aber nicht sicher, wieviel davon schon implementiert wurde –
Tests stehen noch aus).

Beide DOMs implementieren ein Level des W3C DOMs (neuere Versionen eher das
unversionierte WHATWG DOM), was dann mit der jeweiligen Programmiersprache
genutzt werden kann. Welches Level und in welchem Ausmass implementiert
hängt von der Version der Layout-Engine und damit von der Browserversion ab
(aktuell: W3C DOM Level 4, WHATWG DOM je nach Wetterlage[tm]).

.----------------.
: W3C/WHATWG DOM :
'----------------'
^ ^
,--------------------. : : ,-------------. .---------------.
: Mozilla Gecko : : : : WebCore :<---: Blink :
:====================: : : :=============: :===============:
: Mozilla Gecko DOM :-----' `------: WebCore DOM : : Blink DOM :
:--------------------: `-------------' `---------------'
: Mozilla JavaScript :---. ^ ^
`--------------------' : .------------. : :
^ `-->: ECMAScript : : :
: `------------' `------------. :
Mozilla Firefox ^ : :
Mozilla Thunderbird : : :
SeaMonkey .----------------------. .----------.
Mozilla Suite : Chrome V8 JavaScript :<--------: Chromium :
Netscape 7.0+ `----------------------' `----------'
etc. ^ ^
: :
.----------' :
: :
Vivaldi Google Chrome

<https://en.wikipedia.org/wiki/Firefox> pp.
<https://en.wikipedia.org/wiki/Google_Chrome> pp.
<https://en.wikipedia.org/wiki/Vivaldi_(web_browser)> pp.

(Referenzen dort)

> Die jeweilige Implementierung des Browsers, die
> auch "JavaScript" heißen kann oder ausschließlich "ECMAScript"?

Du hast Deine Frage also gerade selbst beantwortet.

Claus Reibenstein

unread,

Jun 2, 2019, 3:37:04 AM6/2/19

to

Arno Welzel schrieb am 01.06.2019 um 22:45:

> Also - wie soll man es nennen, wenn man eine Frage zur Umsetzung eines
> Scripts hat, was innerhalb eines Browser wie Firefox, Vivaldi oder
> Chrome ausgeführt wird? Die jeweilige Implementierung des Browsers, die
> auch "JavaScript" heißen kann oder ausschließlich "ECMAScript"?

Nenne es, wie Du willst. Jeder wird es verstehen. Nur das Spitzohr wird
auf jeden Fall nicht damit einverstanden sein.

Diese Diskussion führen wir hier schon seit Jahren, und auch Du wirst
ihn nicht von seiner Engstirnigkeit abbringen können.

Also lass es einfach.

Gruß
Claus

Ulli Horlacher

unread,

Jun 2, 2019, 6:44:24 AM6/2/19

to

Stefan Ram <r...@zedat.fu-berlin.de> wrote:

> Ulli Horlacher <fram...@rus.uni-stuttgart.de> writes:
> >Das soll dann den dummy HTTP POST machen mit XX MB.
> >Wie wuerde man das angehen?
>

> Ich habe keine Zeit für einen vollständigen Test,
> daher hier nur eine Ideenskizze mit Pseudocode!
>
> Eine POST-Abfrage sollte ungefähr so gehen
> (ungetesteter Pseudocode):
>
> { const form = document.createElement( "form" );
> form.setAttribute( "method", "post" );
> form.setAttribute( "action", "http://www.example.com.invalid/" );
> const field = document.createElement( "input" );
> field.setAttribute( "type", "hidden" );
> field.setAttribute( "name", "data" );
> field.setAttribute( "value", "HAVE A HUGE TEXT HERE" );
> form.appendChild( field );
> document.body.appendChild( form );
> form.submit(); }

Ich will aber nicht 10 GB auf einmal verschicken, sondern in 64 kB
Haeppchen um den aktuellen Durchsatz anzuzeigen.
Ausserdem wuerden die meisten Clients dann heftig anfangen zu swappen.

> Ich weiß nicht, wie die Zeitmessung dann genau gehen soll,

Das hab ich schon:

<script>
var t0 = Date.now();
</script>
(...)
Transfer time: <label id="tt">$tt</label> s<br>
Transfer speed: <label id="kbs">$kBs</label> kB/s<br>
<script>
var tt = (Date.now()-t0)/1000;
document.getElementById("tt").innerHTML = Math.floor(tt);
document.getElementById("kbs").innerHTML = Math.floor(kB/tt);
</script>

Siehe http://flupp.belwue.de/tcpbm

Thomas 'PointedEars' Lahn

unread,

Jun 2, 2019, 7:39:15 AM6/2/19

to

| Zugrunde liegt dieselbe falsche Vorstellung: Es gäbe *eine*
| Programmiersprache namens “Javascript”, die überall gleich sei (oder
| "Dialekte" habe und sich nur *deshalb* in unterschiedlichen Umgebungen
| voneinander unterschiede).
|
| Widrigenfalls enthält diese Phantomsprache dann auch noch alle Host

| Objekte, d. h. konzeptuell fehlt auch noch das Verständnis des
| Unterschieds zwischen eingebauten, nativen und Host-Objekten – da kommen
| dann meist Dinge wie “window”, “document” und “getElementById”, die NICHT
| Teil *irgendeiner* Programmiersprache sind, aber deren angebliches
| "Nichtfunktionieren" dann eben dieser Phantomsprache angelastet
| werden. Hab’ ich alles schon gesehen. Nervig.

| > Ich sagte "Die offizielle Schreibweise ist JavaScript."
|

| Und das ist *falsch*, denn es impliziert *in diesem Kontext*, dass es
| *eine* (1) Programmiersprache gäbe, die “javascript” genannt wird, deren
| offizielle Schreibweise aber „JavaScript“ ist.
|
| Eine solche Sprache gibt es aber nicht, denn die Leute, die “javascript”

^^^^^^^^^^^^^^^^^^^^^^^^^^^

| schreiben, haben gar keine Ahnung, was sie damit meinen. Sie haben

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

| ungesundes Halbwissen: sie wissen nicht, was sie nicht wissen. Ihnen ist

^^^^^^^^^^^^^^^^^^^^^

| nicht klar oder sie wollen aufgrund Bequemlichkeit nicht akzeptieren,

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

| dass das, was sie ”javascript” (oder “Javascript”) nennen, ein Konglomerat
| aus sich *voneinander unterscheidenden* Implementierungen von ECMAScript
| ist (manchmal sogar standardwidrige), und dass das Ganze mit Host-Objekten
| nur insofern zu tun hat, als dass die jeweilige ECMAScript-Implementierung
| den Zugriff auf diese Objekte ermöglicht.

q.e.d.

Thomas 'PointedEars' Lahn

unread,

Jun 2, 2019, 8:00:24 AM6/2/19

to

Ulli Horlacher wrote:

> Stefan Ram <r...@zedat.fu-berlin.de> wrote:
>> Ulli Horlacher <fram...@rus.uni-stuttgart.de> writes:
>> > Das soll dann den dummy HTTP POST machen mit XX MB.
>> > Wie wuerde man das angehen?
>>
>> Ich habe keine Zeit für einen vollständigen Test,
>> daher hier nur eine Ideenskizze mit Pseudocode!
>>
>> Eine POST-Abfrage sollte ungefähr so gehen
>> (ungetesteter Pseudocode):
>>
>> { const form = document.createElement( "form" );

>> […]

>
> Ich will aber nicht 10 GB auf einmal verschicken, sondern in 64 kB
> Haeppchen um den aktuellen Durchsatz anzuzeigen.

Was gefällt Dir an <https://www.speedtest.net/> nicht?

> Ausserdem wuerden die meisten Clients dann heftig anfangen zu swappen.

Es sollte gar nicht möglich sein, 10 GiB hochzuladen, ausser Du willst eine
Sicherheitslücke auf Deinem Server schaffen.

>> Ich weiß nicht, wie die Zeitmessung dann genau gehen soll,
>
> Das hab ich schon:
>
> <script>
> var t0 = Date.now();

Date.now() wurde erst mit ECMAScript Ed. 5 (2009), eingeführt:

<https://www.ecma-international.org/ecma-262/5.1/#sec-15.9.4.4>

Abwärtskompatibel ist:

if (typeof Date.now == 'undefined')
{
Date.now = function () {
var d = new Date();
return d.setMinutes(d.getTimezoneOffset());

};
}

> </script>
> (...)
> Transfer time: <label id="tt">$tt</label> s<br>
> Transfer speed: <label id="kbs">$kBs</label> kB/s<br>
> <script>
> var tt = (Date.now()-t0)/1000;
> document.getElementById("tt").innerHTML = Math.floor(tt);
> document.getElementById("kbs").innerHTML = Math.floor(kB/tt);

.textContent, NICHT .innerHTML

> </script>
>
> Siehe http://flupp.belwue.de/tcpbm

Das ist so nicht korrekt, denn die Client-Uhr muss nicht synchron mit der
Server-Uhr gehen. Wenn Du das so misst, dann musst Du zuerst die Differenz
zwischen Client-Zeit und Server-Zeit bestimmen. Und hoffen, dass der Client
die korrekte Zeitzone meldet.

Stefan Reuther

unread,

Jun 2, 2019, 11:19:34 AM6/2/19

to

Am 02.06.2019 um 12:44 schrieb Ulli Horlacher:

> Stefan Ram <r...@zedat.fu-berlin.de> wrote:
>> { const form = document.createElement( "form" );
>> form.setAttribute( "method", "post" );
>> form.setAttribute( "action", "http://www.example.com.invalid/" );
>> const field = document.createElement( "input" );
>> field.setAttribute( "type", "hidden" );
>> field.setAttribute( "name", "data" );
>> field.setAttribute( "value", "HAVE A HUGE TEXT HERE" );
>> form.appendChild( field );
>> document.body.appendChild( form );
>> form.submit(); }
>
> Ich will aber nicht 10 GB auf einmal verschicken, sondern in 64 kB
> Haeppchen um den aktuellen Durchsatz anzuzeigen.
> Ausserdem wuerden die meisten Clients dann heftig anfangen zu swappen.

Es gibt
https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/upload,
welches dir den Status eines großen Uploads verraten kann.

Wenn du wirklich genauestmögliche Kontrolle haben willst, was wann
gesendet wird, brauchst du Websockets.

Ich habe mich noch nicht damit beschäftigt, wie genau übliche Speedtests
funktionieren, aber so viel Datenvolumen verbrauchen die gar nicht. Wenn
der Speedtest 150 MB durch die Gegend wuppen würde um mir zu sagen "yup,
LTE 150 MBit/s" würde ich mich schon bedanken - und ein einzelnes
Megabyte braucht halt nur 50 ms, und misst damit wohl am meisten die
Round-Trip-Zeiten für den TCP/SSL-Verbindungsaufbau. Mit Websockets
entfallen all diese Overheads, dafür ist das serverseitig vermutlich
immer noch recht knifflig.

Stefan

Arno Welzel

unread,

Jun 2, 2019, 12:05:48 PM6/2/19

to

Thomas 'PointedEars' Lahn:

> Arno Welzel wrote:
[...]

>> Also - wie soll man es nennen, wenn man eine Frage zur Umsetzung eines
>> Scripts hat, was innerhalb eines Browser wie Firefox, Vivaldi oder
>> Chrome ausgeführt wird?
>
> Firefox basiert auf Mozilla Gecko; er unterstützt deshalb Mozilla JavaScript
> und das Gecko DOM.
>
> Google Chrome und Vivaldi basieren auf WebCore/Blink und Chrome V8; sie
> unterstützen deshalb Chrome V8 JavaScript und das WebCore/Blink DOM.
> Ob WebCore oder Blink hängt von der Browserversion ab (neu: Blink).

Weil Du ja immer großen Wert auf Genauigkeit legst: Google selbst nennt
es nicht "V8 JavaScript" sondern einfach nur "V8":

<https://chromium.googlesource.com/v8/v8.git>

"V8 is Google's open source JavaScript engine."

Dich wird vermutlich stören, dass hier nicht "ECMAScript implementation"
statt "JavaScript engine" steht, weil die Aussage "JavaScript engine"
vermutlich komplett falsch und irreführend ist.

> Beide Programmiersprachen implementieren eine Edition von ECMAScript.

[...]

Danke für die Grafik - aber sie war für die Beantwortung meiner Frage
überflüssig.

>> Die jeweilige Implementierung des Browsers, die
>> auch "JavaScript" heißen kann oder ausschließlich "ECMAScript"?
>
> Du hast Deine Frage also gerade selbst beantwortet.

Nein, die Frage ist für mich weiterhin offen. Wie lautet die Antwort?
Ja, das meine ich ernst.

Ich will nämlich vermeiden, dass Du dann wieder meckerst, weil jemand
von "ECMAScript" schreibt, obwohl ein Problem mit JavaScript oder V8
gemeint ist oder Du erklärst, "JavaScript" wäre bei Chrome nicht
implementiert oder ähnliches.

Arno Welzel

unread,

Jun 2, 2019, 12:12:39 PM6/2/19

to

Thomas 'PointedEars' Lahn:

> Claus Reibenstein wrote:
>
>> Arno Welzel schrieb am 01.06.2019 um 22:45:
>>> Also - wie soll man es nennen, wenn man eine Frage zur Umsetzung eines
>>> Scripts hat, was innerhalb eines Browser wie Firefox, Vivaldi oder
>>> Chrome ausgeführt wird? Die jeweilige Implementierung des Browsers, die
>>> auch "JavaScript" heißen kann oder ausschließlich "ECMAScript"?
>>
>> Nenne es, wie Du willst. Jeder wird es verstehen. Nur das Spitzohr wird
>> auf jeden Fall nicht damit einverstanden sein.
>>
>> Diese Diskussion führen wir hier schon seit Jahren, und auch Du wirst
>> ihn nicht von seiner Engstirnigkeit abbringen können.
>
> | Zugrunde liegt dieselbe falsche Vorstellung: Es gäbe *eine*
> | Programmiersprache namens “Javascript”, die überall gleich sei (oder
> | "Dialekte" habe und sich nur *deshalb* in unterschiedlichen Umgebungen
> | voneinander unterschiede).

Falsch - diese Vorstellung herrscht ja gerade nicht. Das glaubst nur Du,
dass Leute so denken.

Die Vorstellung ist, dass man etwas in "JavaScript" schreiben kann, was
in allen gängigen Browsern lauffähig ist. Zumindest habe ich hier noch
nie Fragen zu Node.js oder ähnlichen Umgebungen gesehen oder Rückfragen
gesehen, wieso etwas, das in einem Browser läuft, nicht in Node.js
ebenso möglich ist oder umgekehrt.

Deine Einwände sind auch unglaubwürdig, da Du *nur* mit deinem "es gibt
kein xyz" reagierst, wenn jemand nicht exakt "JavaScript" schreibt -
also z.B. "Javascript" oder "javascript" o.Ä.. Ich kann mich nicht
erinnern, dass Du jemals "es gibt kein JavaScript" geschrieben hättest.
Aber ich lerne gerne dazu, die entsprechenden Message-IDs kennzulernen,
wo Du Leuten erklärst, dass es kein "JavaScript" gibt.

Arno Welzel

unread,

Jun 2, 2019, 12:22:11 PM6/2/19

to

Thomas 'PointedEars' Lahn:

[...]

> Und ich habe jetzt zum wiederholten Mal geschrieben, dass das eine
> ZUSAMMENFASSUNG meiner Bachelorarbeit ist, und ich an dieser Stelle
> NETSCAPE (heute: Mozilla) JavaScript meine, weil ich es zusammen
> mit einem weiteren BEISPIEL, MICROSOFT JScript, nenne.

Eben - es gibt eine *Implementierung* von ECMAScript, die den
offiziellen Namen "JavaScript" hat. Und nichts anderes - GAR NICHTS -
habe ich damit gemeint.

Hätte der OP "Prolog: Ich hab nur rudiementaer Ahnung von JavaScript."
geschrieben, hättest Du ihn dann auch auf diese Thematik hingewiesen?

[...]

> Man *kann* heutzutage auch *nur* “JavaScript” schreiben, wenn man damit
> exakt alle Sprachen meint, die “JavaScript” im Namen haben; dann muss man

V8 hat "JavaScript" nicht im Namen!

<https://v8.dev/docs>

"V8 is Google’s open source high-performance JavaScript and WebAssembly
engine, written in C++."

Also künftig immer aufpassen, wenn man von einem Script spricht, dass in
Firefox und Chrome lauffähig sein soll, dass man tunlichst beachtet von
"JavaScript und V8" zu sprechen, sonst wird Herr Lahn darauf hinweisen,
dass es in Chrome kein "JavaScript" gibt.

Ulli Horlacher

unread,

Jun 2, 2019, 5:02:58 PM6/2/19

to

Stefan Reuther <stefa...@arcor.de> wrote:

> > Ich will aber nicht 10 GB auf einmal verschicken, sondern in 64 kB
> > Haeppchen um den aktuellen Durchsatz anzuzeigen.
> > Ausserdem wuerden die meisten Clients dann heftig anfangen zu swappen.
>
> Es gibt
> https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/upload,
> welches dir den Status eines großen Uploads verraten kann.

Da fehlt mir noch etwas Beispielcode. Mit der formalen Beschreibung kann
ich wenig anfangen.

> Ich habe mich noch nicht damit beschäftigt, wie genau übliche Speedtests
> funktionieren, aber so viel Datenvolumen verbrauchen die gar nicht. Wenn
> der Speedtest 150 MB durch die Gegend wuppen würde um mir zu sagen "yup,
> LTE 150 MBit/s" würde ich mich schon bedanken

150 MB ist zu wenig. Das rauscht bei uns in einer Zentelsekunde durch.
Das kann man nicht vernuenftig messen. Deshalb zeigen die "ueblichen
Speedtests" auch nonsense an. Ich hab noch keinen gefunden, der nicht
wenigstens um Faktor 2 daneben lag. Oft ist es Faktor 10 und mehr.

Ich hab vor im Bereich 1-10 GB Daten zu verschicken.
Das kann ich aber schlecht in einer Datenstruktur im RAM aufbauen, das
muss in 64 kB Bloecken verschickt werden.

Mein Perl-Client macht das so. Das will ich nun in Javascript haben, weil
viele Leute mit Perl Code nichts anfangen koennen.

In Javascript hab ich bisher nur rudimentaer was programmiert.
Deshalb frag ich ja hier.

Arno Welzel

unread,

Jun 2, 2019, 6:06:42 PM6/2/19

to

Ulli Horlacher:

[...]

> Ich hab vor im Bereich 1-10 GB Daten zu verschicken.
> Das kann ich aber schlecht in einer Datenstruktur im RAM aufbauen, das
> muss in 64 kB Bloecken verschickt werden.
>
> Mein Perl-Client macht das so. Das will ich nun in Javascript haben, weil
> viele Leute mit Perl Code nichts anfangen koennen.
>
> In Javascript hab ich bisher nur rudimentaer was programmiert.
> Deshalb frag ich ja hier.

Das Problem ist, dass XMLHttpRequest.send() nicht mehrmals
hintereinander aufgerufen werden kann, sondern nur einmal pro Anfrage.

Als Beispiel wie bei
<https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/send#Example_POST>
gezeigt:

// Neue XHR-Anfrage fuer ein HTTP POST erzeugen
var xhr = new XMLHttpRequest();
xhr.open("POST", "/server", true);
xhr.setRequestHeader("Content-Type",
"application/x-www-form-urlencoded");

// Handler fuer Statusmeldung nach Absenden der Anfrage
xhr.onreadystatechange = function()
{
if (this.readyState === XMLHttpRequest.DONE && this.status === 200)
{
// Anfrage wurde erfolgreich beendet
// hier entsprechende Behandlung ergaenzen
}
}

// Anfrage mit Inhalt abschicken - das geht nur einmal nach open()!
xhr.send("foo=bar&lorem=ipsum");

// Alternativen:
//
// xhr.send(new Int8Array());
// xhr.send(document);

Wenn Du kontinuierlich einen größeren Datenstrom senden willst, wirst Du
um Websockets und eine entsprechende Serverseite dazu nicht herumkommen.

Arno Welzel

unread,

Jun 2, 2019, 6:47:32 PM6/2/19

to

Arno Welzel:

Ergänzung:

<https://www.speedtest.net> benutzt wohl eine Kombination mit Websockets
für den Download und nacheinander ausgeführten HTTP POST-Requests für
den Test der Uploads.

Das ist auch schön zu sehen, wenn man z.B. Firefox benutzt und sich in
der Entwicklerkonsole im "Network"-Tab ansieht, was da während eines
Tests passiert.

Ulli Horlacher

unread,

Jun 3, 2019, 2:06:34 AM6/3/19

to

Arno Welzel <use...@arnowelzel.de> wrote:
> Arno Welzel:

> > Wenn Du kontinuierlich einen größeren Datenstrom senden willst, wirst Du
> > um Websockets und eine entsprechende Serverseite dazu nicht herumkommen.
>

> <https://www.speedtest.net> benutzt wohl eine Kombination mit Websockets
> für den Download und nacheinander ausgeführten HTTP POST-Requests für
> den Test der Uploads.

Wenn der Server eine Datei zum download anbietet, koennte man die dann
wieder mit POST zurueckschicken?

Claus Reibenstein

unread,

Jun 3, 2019, 6:38:20 AM6/3/19

to

Ulli Horlacher schrieb am 02.06.2019 um 23:02:

> 150 MB ist zu wenig. Das rauscht bei uns in einer Zentelsekunde durch.

Das glaube ich kaum. Selbst in einem Gigabit-LAN dauert dies mindestens
1,2 Sekunden. Dabei ist der Protokoll-Overhead noch gar nicht
berücksichtigt.

Gruß
Claus

Jan Novak

unread,

Jun 3, 2019, 8:54:38 AM6/3/19

to

Am 01.06.19 um 13:18 schrieb Arno Welzel:

> Thomas 'PointedEars' Lahn:
>
>> Ulli Horlacher wrote:
>>

>>> Prolog: Ich hab nur rudiementaer Ahnung von Javascript.
>>
>> Es gibt kein "Javascript":
>
> Besser: "Die offizielle Schreibweise ist JavaScript."

Diese Gruppe heisst "d.c.l.*javascript* :-)

Jan

Arno Welzel

unread,

Jun 3, 2019, 9:51:54 AM6/3/19

to

Claus Reibenstein:

Und bei 10 GBit sind es eben noch nur 0,12 Sekunden. Ja, solche Netze
gibt es.

Thomas 'PointedEars' Lahn

unread,

Jun 3, 2019, 12:43:34 PM6/3/19

to

Ulli Horlacher wrote:

> Arno Welzel <use...@arnowelzel.de> wrote:
>> Arno Welzel:
>> > Wenn Du kontinuierlich einen größeren Datenstrom senden willst, wirst
>> > Du um Websockets und eine entsprechende Serverseite dazu nicht
>> > herumkommen.
>>
>> <https://www.speedtest.net> benutzt wohl eine Kombination mit Websockets
>> für den Download und nacheinander ausgeführten HTTP POST-Requests für
>> den Test der Uploads.
>
> Wenn der Server eine Datei zum download anbietet, koennte man die dann
> wieder mit POST zurueckschicken?

Im Prinzip ja.

Stefan Reuther

unread,

Jun 3, 2019, 12:45:58 PM6/3/19

to

Am 02.06.2019 um 23:02 schrieb Ulli Horlacher:
> Stefan Reuther <stefa...@arcor.de> wrote:
>> Ich habe mich noch nicht damit beschäftigt, wie genau übliche Speedtests
>> funktionieren, aber so viel Datenvolumen verbrauchen die gar nicht. Wenn
>> der Speedtest 150 MB durch die Gegend wuppen würde um mir zu sagen "yup,
>> LTE 150 MBit/s" würde ich mich schon bedanken
>
> 150 MB ist zu wenig. Das rauscht bei uns in einer Zentelsekunde durch.
> Das kann man nicht vernuenftig messen. Deshalb zeigen die "ueblichen
> Speedtests" auch nonsense an. Ich hab noch keinen gefunden, der nicht
> wenigstens um Faktor 2 daneben lag. Oft ist es Faktor 10 und mehr.

Bei welcher Anwendung kommt es denn darauf an, ob man 1 GBit/s oder 10
GBit/s hat? Da spielen doch eh noch zahlreiche andere Faktoren hinein:
Last auf dem Server wäre die eine, andere Nutzer auf dem Netzsegment
andere. Bei TLS dann auch noch Leistungsfähigkeit der Krypto-Engine.

> Ich hab vor im Bereich 1-10 GB Daten zu verschicken.

Also das 1-20fache des Monatsvolumens typischer Mobilfunkverträge.

> Das kann ich aber schlecht in einer Datenstruktur im RAM aufbauen, das
> muss in 64 kB Bloecken verschickt werden.

Wennschon sollte es ein adaptives Verfahren werden. Mit dem 64-kB-Block
wird erstmal abgetestet, ob wir über 14.4er Modem, ISDN oder was
schnelleres reden. Und wenn der 64-kB-Block in zu kleiner Zeit
durchflutscht, geht es mit einem größeren weiter.

Aber auch da hast du mit POST keine Kontrolle darüber, ob der Browser
für jede Anfrage eine neue TCP/TLS-Verbindung aufbaut inkl.
beträchtlichem Overhead (TCP-Handshake, Key-Exchange, HTTP-Header) oder
nicht. Pufferung im Netzwerkstack gibt's auch noch. Ich war geraume Zeit
mit 100 MBit/s LAN an 2 MBit/s DSL unterwegs, da hat der 10 MByte Upload
gerne mal verkündet "10 MByte übertragen in 2 Sekunden". Das war die
Zeit, die er fürs Verpacken und in den Kernelpuffer schreiben benötigt
hat, bevor er auf den ersten ACK-Paketen bestanden hat.

TL;DR: wenn du genau steuern willst, was wann gesendet wird, müssen es
Websockets sein.

Stefan

Ulli Horlacher

unread,

Jun 3, 2019, 4:26:18 PM6/3/19

to

Wir haben 100 Gb/s

Ulli Horlacher

unread,

Jun 3, 2019, 4:31:50 PM6/3/19

to

Stefan Reuther <stefa...@arcor.de> wrote:

> Bei welcher Anwendung kommt es denn darauf an, ob man 1 GBit/s oder 10
> GBit/s hat?

Filetransfer.

> > Ich hab vor im Bereich 1-10 GB Daten zu verschicken.
>
> Also das 1-20fache des Monatsvolumens typischer Mobilfunkverträge.

Das ist voellig uninteressant bei uns.

> TL;DR: wenn du genau steuern willst, was wann gesendet wird, müssen es
> Websockets sein.

root@fex01:~# tcpbm flupp.belwue.de
sent: 19752 MB in 10 s = 1975 MB/s
received: 23124 MB in 10 s = 2312 MB/s

Das sind HTTP GET und POST.
Nix websocket.

Aber halt Perl und nicht Javascript.

--
Ullrich Horlacher Server und VirtualisierungRechenzentrum TIK

Stefan Reuther

unread,

Jun 4, 2019, 12:12:18 PM6/4/19

to

Am 03.06.2019 um 22:31 schrieb Ulli Horlacher:
> Stefan Reuther <stefa...@arcor.de> wrote:
>> Bei welcher Anwendung kommt es denn darauf an, ob man 1 GBit/s oder 10
>> GBit/s hat?
>
> Filetransfer.

Und da willst du adaptiv dem Nutzer je nach Bandbreite eine andere Datei
geben, oder wozu must du a priori die Bandbreite wissen?

Filetransfer ist für mich was, das stoße ich an, und irgendwann ist es
fertig, und wenn die Übertragung mit 90% Wirespeed läuft, freu ich mich.
Da nutzt es mir gar nichts, vorher auszumessen, dass die Übertragung mit
1 Gbit/s stattfinden könnte, wenn kurz nach dem Start alle meine
Nachbarn Netflix UHD anwerfen oder der Server ein Plattenimage in den
Backup-Filer schieben.

>> TL;DR: wenn du genau steuern willst, was wann gesendet wird, müssen es
>> Websockets sein.
>
> root@fex01:~# tcpbm flupp.belwue.de
> sent: 19752 MB in 10 s = 1975 MB/s
> received: 23124 MB in 10 s = 2312 MB/s
>
> Das sind HTTP GET und POST.
> Nix websocket.
>
> Aber halt Perl und nicht Javascript.

Perl mit einem eigenen direkt kontrollierbaren HTTP-Stack vermutlich.
Klar, schafft man mit JavaScript und einem eigenen direkt
kontrollierbaren HTTP-Stack unter node.js auch, die Sprache an sich
schränkt dich da nicht ein.

Aber ich hatte verstanden, dass du was für den Browser willst, und da
macht der HTTP-Stack in erster Linie, was er will.

Aber auch mit dem eigenen HTTP-Stack würde ich erwarten, dass bei einer
Rate von 1975 MB/s = 31600x 64 kByte/s noch etwas Luft ist, die mit
größeren Paketen rausgelassen werden kann.

Stefan

Arno Welzel

unread,

Jun 4, 2019, 1:31:47 PM6/4/19

to

Ulli Horlacher:

> Arno Welzel <use...@arnowelzel.de> wrote:
>> Claus Reibenstein:
>>
>>> Ulli Horlacher schrieb am 02.06.2019 um 23:02:
>>>
>>>> 150 MB ist zu wenig. Das rauscht bei uns in einer Zentelsekunde durch.
>>>
>>> Das glaube ich kaum. Selbst in einem Gigabit-LAN dauert dies mindestens
>>> 1,2 Sekunden. Dabei ist der Protokoll-Overhead noch gar nicht
>>> berücksichtigt.
>>
>> Und bei 10 GBit sind es eben noch nur 0,12 Sekunden. Ja, solche Netze
>> gibt es.
>
> Wir haben 100 Gb/s

Und wozu braucht man da noch eine Durchsatzmessung? Bei 100 GBit/s sind
10 GB in einer Sekunde übertragen. Fallen da Daten von mehreren TB
Umfang an, dass es wichtig wird, ob die 100 GBit/s voll verfügbar sind
oder nicht?

Claus Reibenstein

unread,

Jun 4, 2019, 3:48:34 PM6/4/19

to

Und Du hast dort tatsächlich diese Zeit gemessen?

Gruß
Claus

Manfred Haertel

unread,

Jun 5, 2019, 12:00:03 AM6/5/19

to

Stefan Reuther schrieb:

> Filetransfer ist für mich was, das stoße ich an, und irgendwann ist es
> fertig, und wenn die Übertragung mit 90% Wirespeed läuft, freu ich mich.

Ich war in meinem Berufsleben noch NIE mit dem Problem beschäftigt, dass
man die letzten paar Prozent Bandbreite noch unbedingt ausnutzen MUSS.

Dafür war ich schon mehrfach mit dem Problem konfrontiert, dass
Latenz-empfindliche Anwendungen langsam liefen oder gar Timeouts zeigten
und bei der Problemanalyse heraus kam, dass parallel eben genau große
(oft in der Größe oder zu der Zeit "unnötige", weil nicht dringende)
Filetransfers liefen, die die Leitung saturierten und alles andere "zur
Seite drängten"...

--
Manfred Härtel, DB3HM mailto:Manfred...@rz-online.de
http://rz-home.de/mhaertel

Ulli Horlacher

unread,

Jun 5, 2019, 2:09:32 AM6/5/19

to

Arno Welzel <use...@arnowelzel.de> wrote:

> > Wir haben 100 Gb/s
>
> Und wozu braucht man da noch eine Durchsatzmessung? Bei 100 GBit/s sind
> 10 GB in einer Sekunde übertragen. Fallen da Daten von mehreren TB
> Umfang an, dass es wichtig wird, ob die 100 GBit/s voll verfügbar sind
> oder nicht?

Ja.
Wir transferieren (auch) Daten im TB-Bereich.

Ulli Horlacher

unread,

Jun 5, 2019, 2:14:05 AM6/5/19

to

Claus Reibenstein <4spame...@kabelmail.de> wrote:

> >>> 150 MB ist zu wenig. Das rauscht bei uns in einer Zentelsekunde durch.
> >>
> >> Das glaube ich kaum. Selbst in einem Gigabit-LAN dauert dies mindestens
> >> 1,2 Sekunden. Dabei ist der Protokoll-Overhead noch gar nicht
> >> berücksichtigt.
> >
> > Und bei 10 GBit sind es eben noch nur 0,12 Sekunden. Ja, solche Netze
> > gibt es.
>
> Und Du hast dort tatsächlich diese Zeit gemessen?

150 MB kann man nicht vernuenftig messen. Deshalb nimmt man groessere
Datenmengen.

root@fex01:~# tcpbm flupp.belwue.de
sent: 18087 MB in 10 s = 1808 MB/s
received: 18724 MB in 10 s = 1872 MB/s

Nachts oder am Wochenende gehts deutlich schneller, dann ist der Server
nicht so belastet.

Ulli Horlacher

unread,

Jun 5, 2019, 2:30:41 AM6/5/19

to

Stefan Reuther <stefa...@arcor.de> wrote:
> Am 03.06.2019 um 22:31 schrieb Ulli Horlacher:
> > Stefan Reuther <stefa...@arcor.de> wrote:
> >> Bei welcher Anwendung kommt es denn darauf an, ob man 1 GBit/s oder 10
> >> GBit/s hat?
> >
> > Filetransfer.
>
> Und da willst du adaptiv dem Nutzer je nach Bandbreite eine andere Datei
> geben, oder wozu must du a priori die Bandbreite wissen?

Ich bin der Admin. Ich geb den Usern keine Dateien. Die geben die sich
gegenseitig. Aber wir wollen wissen, ob und wo es einen Flaschenhals gibt.
Testen und Monitoring ist notwendig fuer einen professionellen Betrieb.
Dazu gehoert auch, dass die User selber testen koennen.
Der typische DAU kann aber nur seinen Webbrowser bedienen. Dem kann man
kein CLI tool geben.

> Filetransfer ist für mich was, das stoße ich an, und irgendwann ist es
> fertig, und wenn die Übertragung mit 90% Wirespeed läuft, freu ich mich.

Und wenn es nur 0.9% ist, moechte man wissen, woran es liegt.
Da kann es viele Ursachen geben. Deshalb muss man vielen Stellen messen
koennen. Eine davon ist die (reine) Uebertragungsgeschwindigkeit.

> > root@fex01:~# tcpbm flupp.belwue.de
> > sent: 19752 MB in 10 s = 1975 MB/s
> > received: 23124 MB in 10 s = 2312 MB/s
> >
> > Das sind HTTP GET und POST.
> > Nix websocket.
> >
> > Aber halt Perl und nicht Javascript.
>
> Perl mit einem eigenen direkt kontrollierbaren HTTP-Stack vermutlich.

Ja.
In Perl ist das trivial:
tcp-connect, HTTP request absetzen, Daten senden bzw empfangen (und
Transferrate anzeigen). Fertig.

> Klar, schafft man mit JavaScript und einem eigenen direkt
> kontrollierbaren HTTP-Stack unter node.js auch, die Sprache an sich
> schränkt dich da nicht ein.

node.js laeuft doch auf dem Server? Das brauch ich nicht, die Serverseite
habe ich bereits implementiert. Ich will nun nur noch wissen, wie es auf
Clientseite in Javascript geht.

> Aber ich hatte verstanden, dass du was für den Browser willst, und da
> macht der HTTP-Stack in erster Linie, was er will.

Also geht das mit Javascript gar nicht (nur mit HTTP GET und POST)?

Alles neu zu implementieren mit websockets ist mir zu aufwaendig.

Ralph Aichinger

unread,

Jun 5, 2019, 9:22:34 AM6/5/19

to

Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
> Der typische DAU kann aber nur seinen Webbrowser bedienen. Dem kann man
> kein CLI tool geben.

Eventuell ist es einfacher ein ookla.com-Partner zu werden oder das
Ding zu lizensieren (nein, keine Ahnung wie kompliziert/teuer/problematisch
das ist)? Das ist endbenutzertauglich.

/ralph
--
-----------------------------------------------------------------------------
https://aisg.at
ausserirdische sind gesund

Stefan Reuther

unread,

Jun 5, 2019, 12:13:55 PM6/5/19

to

Am 05.06.2019 um 08:30 schrieb Ulli Horlacher:
> Stefan Reuther <stefa...@arcor.de> wrote:
>> Am 03.06.2019 um 22:31 schrieb Ulli Horlacher:
>>> root@fex01:~# tcpbm flupp.belwue.de
>>> sent: 19752 MB in 10 s = 1975 MB/s
>>> received: 23124 MB in 10 s = 2312 MB/s
>>>
>>> Das sind HTTP GET und POST.
>>> Nix websocket.
>>>
>>> Aber halt Perl und nicht Javascript.
>>
>> Perl mit einem eigenen direkt kontrollierbaren HTTP-Stack vermutlich.
>
> Ja.
> In Perl ist das trivial:
> tcp-connect, HTTP request absetzen, Daten senden bzw empfangen (und
> Transferrate anzeigen). Fertig.
>
>> Klar, schafft man mit JavaScript und einem eigenen direkt
>> kontrollierbaren HTTP-Stack unter node.js auch, die Sprache an sich
>> schränkt dich da nicht ein.
>
> node.js laeuft doch auf dem Server? Das brauch ich nicht, die Serverseite
> habe ich bereits implementiert. Ich will nun nur noch wissen, wie es auf
> Clientseite in Javascript geht.

Genauso, wie du eine Perl-Umgebung auf dem Client installieren kannst,
kannst du natürlich eine node.js-Umgebung auf dem Client installieren.
Aber die node.js-Umgebung bietet dir halt nicht die gleichen APIs wie
der Browser.

>> Aber ich hatte verstanden, dass du was für den Browser willst, und da
>> macht der HTTP-Stack in erster Linie, was er will.
>
> Also geht das mit Javascript gar nicht (nur mit HTTP GET und POST)?

Es geht mit JavaScript *im Browser* halt nur mit Einschränkungen, weil
der sich selbst überlegt, wie er dein XMLHTTPRequest auf HTTP abbildet.

Wenn's nur um ein Schätzeisen für den User geht, kann man mit den
Einschränkungen dann auch sicher leben.

Dann kannst du mit 64k-Blöcken arbeiten und schauen, wie nah du an der
Realität landest. Eventuell nutze noch etwas Parallelität, z.B. immer 10
Blöcke aktiv, der Browser sortiert das dann schon irgendwie, so dass
bereits direkt nach dem Empfang eines Pakets klar ist, wie es
weitergeht, und nicht erst in die JavaScript-Engine, GUI usw.
reingerufen werden muss.

Eventuell brauchst du dann auch kein POST sondern kommst mit GET hin
("ist ja nur ein Schätzeisen"). Eventuell kommst du mit Megabyte-Blöcken
genauere Ergebnisse wie mit 64k.

Vielleicht kannst du dann auch bestimmte Einschränkungen bzgl. der
Browser treffen, die ein allgemeiner Dienstanbieter nicht kann. Und sei
es sowas wie "mit Browser $XYZ sind die Ergebnisse am nähesten an der
Realität".

Stefan

Ulli Horlacher

unread,

Jun 5, 2019, 4:25:06 PM6/5/19

to

Stefan Ram <r...@zedat.fu-berlin.de> wrote:
> Ulli Horlacher <fram...@rus.uni-stuttgart.de> writes:

> >Der typische DAU kann aber nur seinen Webbrowser bedienen. Dem kann man
> >kein CLI tool geben.
>

> Neben Web-Browser und Kommandozeilenprogramm gibt es ja auch
> noch GUI-Programme. Sie lassen sich auch in Perl schreiben
> (wxPerl, Perl-Tk, Perl/Qt, gtk2-Perl, ...). Für Endanwender
> bräucht man noch ein Installationsprogramm (PDK deployment
> tools?).

Wir haben keine Windows-Programmierer.
Ausserdem muesste man dann auf Windoows auch noch Perl installieren.
Nein, das ist nicht machbar.

Claus Reibenstein

unread,

Jun 6, 2019, 3:49:10 AM6/6/19

to

Ulli Horlacher schrieb am 05.06.2019 um 22:25:

> Ausserdem muesste man dann auf Windoows auch noch Perl installieren.
> Nein, das ist nicht machbar.

<http://www.perl.org/get.html>

Gruß
Claus

Ulli Horlacher

unread,

Jun 6, 2019, 4:47:18 AM6/6/19

to

ICH kann das, aber nicht meine User, die sind damit VOELLIG ueberfordert.

Arno Welzel

unread,

Jun 8, 2019, 8:51:00 AM6/8/19

to

Ulli Horlacher:

> Stefan Reuther <stefa...@arcor.de> wrote:

[...]

>> Aber ich hatte verstanden, dass du was für den Browser willst, und da
>> macht der HTTP-Stack in erster Linie, was er will.
>
> Also geht das mit Javascript gar nicht (nur mit HTTP GET und POST)?

Korrekt. Du kannst natürlich statt einmalig 1 GB auch 100x10 MB
nacheinander via XHR abschicken und jeweils messen und dann als Näherung
ausreichnen, wie lange es wohl dauern würde, wenn man 1 GB am Stück hat.
Aber mit "genau" hat das nichts mehr zu tun, da dann auch 100x der
Overhead für Verbindungsaufbau etc. dazukommt.

> Alles neu zu implementieren mit websockets ist mir zu aufwaendig.

Dann schreibe eine Anleitung, wie die Leute das Perl-Tool nutzen können.
Wenn sie in der Lage sind F*EX zu verwenden, werden sie ja auch tcpbm
aufrufen können.

Arno Welzel

unread,

Jun 8, 2019, 8:53:29 AM6/8/19

to

Ulli Horlacher:

> Stefan Ram <r...@zedat.fu-berlin.de> wrote:
>> Ulli Horlacher <fram...@rus.uni-stuttgart.de> writes:
>>> Der typische DAU kann aber nur seinen Webbrowser bedienen. Dem kann man
>>> kein CLI tool geben.
>>
>> Neben Web-Browser und Kommandozeilenprogramm gibt es ja auch
>> noch GUI-Programme. Sie lassen sich auch in Perl schreiben
>> (wxPerl, Perl-Tk, Perl/Qt, gtk2-Perl, ...). Für Endanwender
>> bräucht man noch ein Installationsprogramm (PDK deployment
>> tools?).
>
> Wir haben keine Windows-Programmierer.

Was hat das mit Windows zu tun? wxPerl oder Perl-TK läuft
plattformübergreifend.

> Ausserdem muesste man dann auf Windoows auch noch Perl installieren.
> Nein, das ist nicht machbar.

Und für F*EX braucht man kein Perl auf Windows?

BTW: Nextcloud hat auch mit mehreren GB oder TB kein Problem, solange
der Server entsprechend konfiguriert ist.

Ulli Horlacher

unread,

Jun 8, 2019, 3:31:43 PM6/8/19

to

Arno Welzel <use...@arnowelzel.de> wrote:
> Ulli Horlacher:
>
> > Stefan Ram <r...@zedat.fu-berlin.de> wrote:
> >> Ulli Horlacher <fram...@rus.uni-stuttgart.de> writes:
> >>> Der typische DAU kann aber nur seinen Webbrowser bedienen. Dem kann man
> >>> kein CLI tool geben.
> >>
> >> Neben Web-Browser und Kommandozeilenprogramm gibt es ja auch
> >> noch GUI-Programme. Sie lassen sich auch in Perl schreiben
> >> (wxPerl, Perl-Tk, Perl/Qt, gtk2-Perl, ...). Für Endanwender
> >> bräucht man noch ein Installationsprogramm (PDK deployment
> >> tools?).
> >
> > Wir haben keine Windows-Programmierer.
>
> Was hat das mit Windows zu tun? wxPerl oder Perl-TK läuft
> plattformübergreifend.

Es gibt keine (funktionierenden) Perl Compiler fuer Windows mehr.

> > Ausserdem muesste man dann auf Windoows auch noch Perl installieren.
> > Nein, das ist nicht machbar.
>
> Und für F*EX braucht man kein Perl auf Windows?

Nein. Das geht entweder ueber den Webbrowser oder ein standalone Executable.

Ulli Horlacher

unread,

Jun 8, 2019, 3:34:04 PM6/8/19

to

Arno Welzel <use...@arnowelzel.de> wrote:
> Ulli Horlacher:
>
> > Stefan Reuther <stefa...@arcor.de> wrote:
> [...]
> >> Aber ich hatte verstanden, dass du was für den Browser willst, und da
> >> macht der HTTP-Stack in erster Linie, was er will.
> >
> > Also geht das mit Javascript gar nicht (nur mit HTTP GET und POST)?
>
> Korrekt. Du kannst natürlich statt einmalig 1 GB auch 100x10 MB
> nacheinander via XHR abschicken und jeweils messen und dann als Näherung
> ausreichnen, wie lange es wohl dauern würde, wenn man 1 GB am Stück hat.
> Aber mit "genau" hat das nichts mehr zu tun, da dann auch 100x der
> Overhead für Verbindungsaufbau etc. dazukommt.

Eben, das ist dann so sinnlos.
Ok, dann ist das Projekt gestorben. "Geht halt nicht".

> Dann schreibe eine Anleitung, wie die Leute das Perl-Tool nutzen können.
> Wenn sie in der Lage sind F*EX zu verwenden, werden sie ja auch tcpbm
> aufrufen können.

NO WAY. Das sind DAUs.
Ausserdem hat tcpbm erst mal nichts mit F*EX zu tun. Da gibts hoechstens
eine Anwenderschnittmenge.

Thomas 'PointedEars' Lahn

unread,

Jun 8, 2019, 6:45:17 PM6/8/19

to

Ulli Horlacher wrote:

> Arno Welzel <use...@arnowelzel.de> wrote:
>> Ulli Horlacher:
>> > Stefan Reuther <stefa...@arcor.de> wrote:
>> [...]
>> >> Aber ich hatte verstanden, dass du was für den Browser willst, und da
>> >> macht der HTTP-Stack in erster Linie, was er will.
>> >
>> > Also geht das mit Javascript gar nicht (nur mit HTTP GET und POST)?

Es gibt immer noch kein “Javascript”.

>> Korrekt.

Dass es mit clientseitigem Scripting geht, beweist speedtest.net.

>> Du kannst natürlich statt einmalig 1 GB auch 100x10 MB nacheinander via
>> XHR abschicken und jeweils messen und dann als Näherung ausreichnen, wie
>> lange es wohl dauern würde, wenn man 1 GB am Stück hat. Aber mit "genau"
>> hat das nichts mehr zu tun, da dann auch 100x der Overhead für
>> Verbindungsaufbau etc. dazukommt.

Schon weil seit HTTP/1.1 “persistent connections” der Default sind, ist das
schlicht Unfug.

> Eben, das ist dann so sinnlos.
> Ok, dann ist das Projekt gestorben. "Geht halt nicht".

Glaub nicht gleich alles, was Du liest.

Stefan Reuther

unread,

Jun 9, 2019, 5:14:44 AM6/9/19

to

Am 08.06.2019 um 21:34 schrieb Ulli Horlacher:
> Arno Welzel <use...@arnowelzel.de> wrote:
>> Ulli Horlacher:
>>> Stefan Reuther <stefa...@arcor.de> wrote:
>>>> Aber ich hatte verstanden, dass du was für den Browser willst, und da
>>>> macht der HTTP-Stack in erster Linie, was er will.
>>>
>>> Also geht das mit Javascript gar nicht (nur mit HTTP GET und POST)?
>>
>> Korrekt. Du kannst natürlich statt einmalig 1 GB auch 100x10 MB
>> nacheinander via XHR abschicken und jeweils messen und dann als Näherung
>> ausreichnen, wie lange es wohl dauern würde, wenn man 1 GB am Stück hat.
>> Aber mit "genau" hat das nichts mehr zu tun, da dann auch 100x der
>> Overhead für Verbindungsaufbau etc. dazukommt.
>
> Eben, das ist dann so sinnlos.
> Ok, dann ist das Projekt gestorben. "Geht halt nicht".

Natürlich geht das. Mit Einschränkungen. Die wichtigste Einschränkung
dabei: du kannst nicht beeinflussen, wann und wie oft der Browser eine
Verbindung aufbaut und wie lange er dazu benötigt. Und je nachdem,
wieviel Logik, Zeit und Datenvolumen du investierst, um so genauer wird
die Messung.

Websockets dürften am nähesten kommen. Multiple parallele große XHR für
POST und GET für mehrere Sekunden im Kreis senden am zweitbesten.

Dazu wäre aber noch zu sagen, dass die Browser-APIs zur Zeitmessung
inzwischen künstlich in der Genauigkeit beschnitten sind, um
Timingangriffen (Meltdown, Spectre) zu begegnen. *Ein* Paket senden und
aus der in µs gemessenen RTT Schlüsse zu ziehen klappt also sowieso nicht.

>> Dann schreibe eine Anleitung, wie die Leute das Perl-Tool nutzen können.
>> Wenn sie in der Lage sind F*EX zu verwenden, werden sie ja auch tcpbm
>> aufrufen können.
>
> NO WAY. Das sind DAUs.
> Ausserdem hat tcpbm erst mal nichts mit F*EX zu tun. Da gibts hoechstens
> eine Anwenderschnittmenge.

Naja, sonderlich engagiert kommst du jetzt in diesem Thread aber auch
nicht rüber.

Aber die genaueste Messung, um rauszubekommen, wie lange eine
Dateiübertratung mit F*EX aktuell dauert, ist ja eh immer noch, mit F*EX
eine Datei zu übertragen und zu schauen, wie lange das dauert.

Stefan

Ulli Horlacher

unread,

Jun 9, 2019, 8:06:57 AM6/9/19

to

Stefan Reuther <stefa...@arcor.de> wrote:

> > Ok, dann ist das Projekt gestorben. "Geht halt nicht".
>
> Natürlich geht das. Mit Einschränkungen. Die wichtigste Einschränkung
> dabei: du kannst nicht beeinflussen, wann und wie oft der Browser eine
> Verbindung aufbaut und wie lange er dazu benötigt.

Und eben damit geht eine genaue Durchsatzmessung nicht, weil die vielen
HTTP-connects overhead das Messergebnis verfaelscht.
tcpbm macht genauen einen HTTP connect.

> Dazu wäre aber noch zu sagen, dass die Browser-APIs zur Zeitmessung
> inzwischen künstlich in der Genauigkeit beschnitten sind, um
> Timingangriffen (Meltdown, Spectre) zu begegnen. *Ein* Paket senden und
> aus der in µs gemessenen RTT Schlüsse zu ziehen klappt also sowieso nicht.

Deshalb sendet tcpbm default 10 s lang.

> > Ausserdem hat tcpbm erst mal nichts mit F*EX zu tun. Da gibts hoechstens
> > eine Anwenderschnittmenge.
>

> Aber die genaueste Messung, um rauszubekommen, wie lange eine
> Dateiübertratung mit F*EX aktuell dauert, ist ja eh immer noch, mit F*EX
> eine Datei zu übertragen und zu schauen, wie lange das dauert.

NOCHMALS: das hat NICHTS mit F*EX zu tun!

Stefan Reuther

unread,

Jun 10, 2019, 5:18:44 AM6/10/19

to

Am 09.06.2019 um 14:06 schrieb Ulli Horlacher:
> Stefan Reuther <stefa...@arcor.de> wrote:
>>> Ok, dann ist das Projekt gestorben. "Geht halt nicht".
>>
>> Natürlich geht das. Mit Einschränkungen. Die wichtigste Einschränkung
>> dabei: du kannst nicht beeinflussen, wann und wie oft der Browser eine
>> Verbindung aufbaut und wie lange er dazu benötigt.
>
> Und eben damit geht eine genaue Durchsatzmessung nicht, weil die vielen
> HTTP-connects overhead das Messergebnis verfaelscht.

Deswegen parallel.

Fehlkonfigurationen ausgenommen wird kein Browser der letzten 20 Jahre
wirklich für jeden Request eine neue Verbindung aufbauen. Browser werden
Limits haben, wieviele Verbindungen parallel laufen oder wieviele
Requests maximal über eine Verbindung gesendet werden, bevor sie
geschlossen wird. Aber Connection-Recycling machen sie.

Parallelität sorgt dafür, dass nach dem Ende einer Übertragung bereits
ein neuer Request bereitsteht, was den Browser vielleicht motiviert, die
Verbindung offen zu halten. Und wenn er stattdessen eine neue Verbindung
aufbaut, geht der Aufbau-Overhead im Warten auf die Daten des
Parallelrequests unter.

>>> Ausserdem hat tcpbm erst mal nichts mit F*EX zu tun. Da gibts hoechstens
>>> eine Anwenderschnittmenge.
>>
>> Aber die genaueste Messung, um rauszubekommen, wie lange eine
>> Dateiübertratung mit F*EX aktuell dauert, ist ja eh immer noch, mit F*EX
>> eine Datei zu übertragen und zu schauen, wie lange das dauert.
>
> NOCHMALS: das hat NICHTS mit F*EX zu tun!

Mag ja sein, aber wir reden von Endusern? Wenn ich Probleme mit der
HTTP-Download-Geschwindigkeit von Server X hab, pack ich nicht gleich
das Profi-Bandbreiten-Messgerät aus, sondern messe erstmal die
HTTP-Download-Geschwindigkeit von Server Y, um auf "mein Ende" oder "X's
Ende" einzugrenzen.

Stefan

Ulli Horlacher

unread,

Jun 10, 2019, 5:47:11 AM6/10/19

to

Stefan Reuther <stefa...@arcor.de> wrote:
> Am 09.06.2019 um 14:06 schrieb Ulli Horlacher:
> > Stefan Reuther <stefa...@arcor.de> wrote:
> >>> Ok, dann ist das Projekt gestorben. "Geht halt nicht".
> >>
> >> Natürlich geht das. Mit Einschränkungen. Die wichtigste Einschränkung
> >> dabei: du kannst nicht beeinflussen, wann und wie oft der Browser eine
> >> Verbindung aufbaut und wie lange er dazu benötigt.
> >
> > Und eben damit geht eine genaue Durchsatzmessung nicht, weil die vielen
> > HTTP-connects overhead das Messergebnis verfaelscht.
>
> Deswegen parallel.

Das macht es nicht (viel) besser.
Jeder HTTP connect dauert vieeeeeeeeeeeeeeeel laenger als das Uebertragen
von Daten.

> Fehlkonfigurationen ausgenommen wird kein Browser der letzten 20 Jahre
> wirklich für jeden Request eine neue Verbindung aufbauen.

Wenn ihm das die Gegenseite vorschreibt, schon.
Da gibts mehrere Moeglichkeit. Eine davon waere ein Proxy.
Oder mein tcpbm Server.

> >> Aber die genaueste Messung, um rauszubekommen, wie lange eine
> >> Dateiübertratung mit F*EX aktuell dauert, ist ja eh immer noch, mit F*EX
> >> eine Datei zu übertragen und zu schauen, wie lange das dauert.
> >
> > NOCHMALS: das hat NICHTS mit F*EX zu tun!
>
> Mag ja sein, aber wir reden von Endusern? Wenn ich Probleme mit der
> HTTP-Download-Geschwindigkeit von Server X hab, pack ich nicht gleich
> das Profi-Bandbreiten-Messgerät aus, sondern messe erstmal die
> HTTP-Download-Geschwindigkeit von Server Y, um auf "mein Ende" oder "X's
> Ende" einzugrenzen.

Die Upload Geschwindigkeit kann um Faktor 100 von der des Dowmloads
abweichen. Deshalb brauch ich ein Tool, das beides kann.
Country UND Western.

Arno Welzel

unread,

Jun 10, 2019, 11:29:14 AM6/10/19

to

Thomas 'PointedEars' Lahn:

> Ulli Horlacher wrote:
>
>> Arno Welzel <use...@arnowelzel.de> wrote:
>>> Ulli Horlacher:
>>>> Stefan Reuther <stefa...@arcor.de> wrote:
>>> [...]
>>>>> Aber ich hatte verstanden, dass du was für den Browser willst, und da
>>>>> macht der HTTP-Stack in erster Linie, was er will.
>>>>
>>>> Also geht das mit Javascript gar nicht (nur mit HTTP GET und POST)?
>
> Es gibt immer noch kein “Javascript”.
>
>>> Korrekt.
>
> Dass es mit clientseitigem Scripting geht, beweist speedtest.net.

Nein, tut es nicht. speedtest.net nutzt Websockets und entsprechende
Serverdienst auf der Gegenseite.

>>> Du kannst natürlich statt einmalig 1 GB auch 100x10 MB nacheinander via
>>> XHR abschicken und jeweils messen und dann als Näherung ausreichnen, wie
>>> lange es wohl dauern würde, wenn man 1 GB am Stück hat. Aber mit "genau"
>>> hat das nichts mehr zu tun, da dann auch 100x der Overhead für
>>> Verbindungsaufbau etc. dazukommt.
>
> Schon weil seit HTTP/1.1 “persistent connections” der Default sind, ist das
> schlicht Unfug.

Dann zeige ein Beispiel, wie man das in JavaScript nutzen kann. Die
reine Feststellung, dass es etwas gibt, hilft hier exakt gar nicht.

>> Eben, das ist dann so sinnlos.
>> Ok, dann ist das Projekt gestorben. "Geht halt nicht".
>
> Glaub nicht gleich alles, was Du liest.

Da Herr Lahn auch nichts besseres vorschlägt - glaube es ruhig.

Claus Reibenstein

unread,

Jun 10, 2019, 11:38:02 AM6/10/19

to

Stefan Reuther schrieb am 10.06.2019 um 11:16:

> Fehlkonfigurationen ausgenommen wird kein Browser der letzten 20 Jahre
> wirklich für jeden Request eine neue Verbindung aufbauen.

HTTP ist nach meinen Informationen ein verbindungsloses Protokoll.
Heißt: Es wird überhaupt keine Verbindung aufgebaut. Vielmehr schickt
der Browser einen oder mehrere Requests auf die Reise und lauscht auf
seinen Ports auf Antworten.

Oder meinst Du etwas Anderes?

Gruß
Claus

Ulli Horlacher

Das gilt so pauschal schon länger nicht mehr. Aktuell können Browser
durchaus *eine* Verbindung aufbauen und darüber *mehrere* Requests
abschicken und auf die Antworten warten.

Bei HTTP/1.1 nennt sich der Mechanismus "keep alive":

<https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Keep-Alive>

Bei HTTP/2 ist das generell so und gar nicht mehr anders vorgesehen.

Claus Reibenstein

unread,

Jun 11, 2019, 5:57:33 AM6/11/19

to

Arno Welzel schrieb am 11.06.2019 um 10:48:

> Claus Reibenstein:

>
>> HTTP ist nach meinen Informationen ein verbindungsloses Protokoll.
>
> Aus Anwendungssicht, ja.

Ok.

>> Heißt: Es wird überhaupt keine Verbindung aufgebaut. Vielmehr schickt
>> der Browser einen oder mehrere Requests auf die Reise und lauscht auf
>> seinen Ports auf Antworten.
>
> Das gilt so pauschal schon länger nicht mehr. Aktuell können Browser
> durchaus *eine* Verbindung aufbauen und darüber *mehrere* Requests
> abschicken und auf die Antworten warten.
>
> Bei HTTP/1.1 nennt sich der Mechanismus "keep alive":
>
> <https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Keep-Alive>
>
> Bei HTTP/2 ist das generell so und gar nicht mehr anders vorgesehen.

Danke für die ausführlichen Erklärungen. Damit kann ich etwas anfangen.

Gruß
Claus

Stefan Reuther

unread,

Jun 11, 2019, 11:56:23 AM6/11/19

to

Am 10.06.2019 um 11:47 schrieb Ulli Horlacher:
> Stefan Reuther <stefa...@arcor.de> wrote:
>> Am 09.06.2019 um 14:06 schrieb Ulli Horlacher:
>>> Stefan Reuther <stefa...@arcor.de> wrote:
>>>>> Ok, dann ist das Projekt gestorben. "Geht halt nicht".
>>>>
>>>> Natürlich geht das. Mit Einschränkungen. Die wichtigste Einschränkung
>>>> dabei: du kannst nicht beeinflussen, wann und wie oft der Browser eine
>>>> Verbindung aufbaut und wie lange er dazu benötigt.
>>>
>>> Und eben damit geht eine genaue Durchsatzmessung nicht, weil die vielen
>>> HTTP-connects overhead das Messergebnis verfaelscht.
>>
>> Deswegen parallel.
>
> Das macht es nicht (viel) besser.
> Jeder HTTP connect dauert vieeeeeeeeeeeeeeeel laenger als das Uebertragen
> von Daten.

Vermutet oder gemessen? Und insbesondere: gemessen im Kontext eines
Browsers?

Ein HTTP-Connect ist ein TCP-Verbindungsaufbau (3 Pakete) + die
Requestdaten. Wirklich langsam wird das eigentlich alles nur, wenn du
z.B. irgendwelche Randfälle von Nagle's Algorithm o.ä. triffst, wo eine
Seite erst einen Timeout oder ACK abwartet, bevor sie sich traut, ein
Folgepaket zu schicken.

Und all das lässt sich durch Vergrößerung der Datenmenge reduzieren.
Mehr Daten in der Payload = Kernel hat immer was zu senden = Overhead
geht besser unter.

>> Fehlkonfigurationen ausgenommen wird kein Browser der letzten 20 Jahre
>> wirklich für jeden Request eine neue Verbindung aufbauen.
>
> Wenn ihm das die Gegenseite vorschreibt, schon.
> Da gibts mehrere Moeglichkeit. Eine davon waere ein Proxy.
> Oder mein tcpbm Server.

Ich gehe natürlich von einem angepassten Server aus. Also keinem, der
bei so einem Benchmark-Request erst das CGI vom NFS startet.

>>>> Aber die genaueste Messung, um rauszubekommen, wie lange eine
>>>> Dateiübertratung mit F*EX aktuell dauert, ist ja eh immer noch, mit F*EX
>>>> eine Datei zu übertragen und zu schauen, wie lange das dauert.
>>>
>>> NOCHMALS: das hat NICHTS mit F*EX zu tun!
>>
>> Mag ja sein, aber wir reden von Endusern? Wenn ich Probleme mit der
>> HTTP-Download-Geschwindigkeit von Server X hab, pack ich nicht gleich
>> das Profi-Bandbreiten-Messgerät aus, sondern messe erstmal die
>> HTTP-Download-Geschwindigkeit von Server Y, um auf "mein Ende" oder "X's
>> Ende" einzugrenzen.
>
> Die Upload Geschwindigkeit kann um Faktor 100 von der des Dowmloads
> abweichen. Deshalb brauch ich ein Tool, das beides kann.

Wenn ich Probleme mit der Upload-Geschwindigkeit hab, mach ich das
selbstverständlich ganz genauso.

Stefan

Ulli Horlacher

unread,

Jun 11, 2019, 4:02:23 PM6/11/19

to

Stefan Reuther <stefa...@arcor.de> wrote:

> >>> Und eben damit geht eine genaue Durchsatzmessung nicht, weil die vielen
> >>> HTTP-connects overhead das Messergebnis verfaelscht.
> >>
> >> Deswegen parallel.
> >
> > Das macht es nicht (viel) besser.
> > Jeder HTTP connect dauert vieeeeeeeeeeeeeeeel laenger als das Uebertragen
> > von Daten.
>
> Vermutet oder gemessen?

Gemessen.

> Und insbesondere: gemessen im Kontext eines Browsers?

Beides.

> Ein HTTP-Connect ist ein TCP-Verbindungsaufbau (3 Pakete) + die
> Requestdaten. Wirklich langsam wird das eigentlich alles nur, wenn du
> z.B. irgendwelche Randfälle von Nagle's Algorithm o.ä. triffst, wo eine
> Seite erst einen Timeout oder ACK abwartet, bevor sie sich traut, ein
> Folgepaket zu schicken.

Du vergisst den Overhead beim Serverstart.

> Und all das lässt sich durch Vergrößerung der Datenmenge reduzieren.
> Mehr Daten in der Payload = Kernel hat immer was zu senden = Overhead
> geht besser unter.

Meine Server machen ca 5 GB/s Durchsatz. In dem Bereich muesste ich Daten
verschicken um den Overhead zu minimieren. Das ist bei langsamer
Client-Anbindung (DSL, WLAN, etc) unbrauchbar.

> >> Fehlkonfigurationen ausgenommen wird kein Browser der letzten 20 Jahre
> >> wirklich für jeden Request eine neue Verbindung aufbauen.
> >
> > Wenn ihm das die Gegenseite vorschreibt, schon.
> > Da gibts mehrere Moeglichkeit. Eine davon waere ein Proxy.
> > Oder mein tcpbm Server.
>
> Ich gehe natürlich von einem angepassten Server aus. Also keinem, der
> bei so einem Benchmark-Request erst das CGI vom NFS startet.

Einen Proxy kannst du nicht beeinflussen. Du musst den benutzen, so, wie
er ist.

Ralph Aichinger

unread,

Jun 12, 2019, 1:45:06 AM6/12/19

to

Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
> Du vergisst den Overhead beim Serverstart.

Läßt man nicht heute einen Pool von Prefork-Servern durchlaufen?

Ulli Horlacher

unread,

Jun 12, 2019, 2:08:33 AM6/12/19

to

Ralph Aichinger <r...@pi.h5.or.at> wrote:
> Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
> > Du vergisst den Overhead beim Serverstart.
>
> Läßt man nicht heute einen Pool von Prefork-Servern durchlaufen?

Nicht jeder Server macht das.

Ralph Aichinger

unread,

Jun 12, 2019, 4:16:10 AM6/12/19

to

Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
> Ralph Aichinger <r...@pi.h5.or.at> wrote:
>> Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
>> > Du vergisst den Overhead beim Serverstart.
>>
>> Läßt man nicht heute einen Pool von Prefork-Servern durchlaufen?
>
> Nicht jeder Server macht das.

Klar, aber wenn es einem auf kurze Reaktionszeiten schon ankommt,
wär das nicht das Mittel der Wahl (ernst gemeinte Frage, ich will
nicht trollen oder besserwissern)?

Thomas 'PointedEars' Lahn

unread,

Jun 12, 2019, 4:37:20 AM6/12/19

to

Ulli Horlacher wrote:

> Stefan Reuther <stefa...@arcor.de> wrote:
>> >>> Und eben damit geht eine genaue Durchsatzmessung nicht, weil die
>> >>> vielen HTTP-connects overhead das Messergebnis verfaelscht.
>> >>
>> >> Deswegen parallel.
>> >
>> > Das macht es nicht (viel) besser.
>> > Jeder HTTP connect dauert vieeeeeeeeeeeeeeeel laenger als das
>> > Uebertragen von Daten.
>>
>> Vermutet oder gemessen?
>
> Gemessen.
>
>> Und insbesondere: gemessen im Kontext eines Browsers?
>
> Beides.

Dann mal Butter bei die Fische.

>> Ein HTTP-Connect ist ein TCP-Verbindungsaufbau (3 Pakete) + die
>> Requestdaten. Wirklich langsam wird das eigentlich alles nur, wenn du
>> z.B. irgendwelche Randfälle von Nagle's Algorithm o.ä. triffst, wo eine
>> Seite erst einen Timeout oder ACK abwartet, bevor sie sich traut, ein
>> Folgepaket zu schicken.
>
> Du vergisst den Overhead beim Serverstart.

Wie bitte? Der HTTP-Server *läuft* und *lauscht*.

Ulli Horlacher

unread,

Jun 12, 2019, 5:05:20 AM6/12/19

to

Ralph Aichinger <r...@pi.h5.or.at> wrote:
> Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
> > Ralph Aichinger <r...@pi.h5.or.at> wrote:
> >> Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
> >> > Du vergisst den Overhead beim Serverstart.
> >>
> >> Läßt man nicht heute einen Pool von Prefork-Servern durchlaufen?
> >
> > Nicht jeder Server macht das.
>
> Klar, aber wenn es einem auf kurze Reaktionszeiten schon ankommt,
> wär das nicht das Mittel der Wahl

Mein Server kann das nicht und es ist auch nicht notwendig, da pro Messung
nur ein tcp connect gemacht wird.

Stefan Reuther

unread,

Jun 12, 2019, 12:18:20 PM6/12/19

to

Am 11.06.2019 um 22:02 schrieb Ulli Horlacher:
> Stefan Reuther <stefa...@arcor.de> wrote:

>> Ein HTTP-Connect ist ein TCP-Verbindungsaufbau (3 Pakete) + die
>> Requestdaten. Wirklich langsam wird das eigentlich alles nur, wenn du
>> z.B. irgendwelche Randfälle von Nagle's Algorithm o.ä. triffst, wo eine
>> Seite erst einen Timeout oder ACK abwartet, bevor sie sich traut, ein
>> Folgepaket zu schicken.
>
> Du vergisst den Overhead beim Serverstart.

Ich gehe natürlich davon aus, dass ein Übertragungsratenmesstool als
Gegenseite einen Übertragensratenmesstoolserver hat und keinen
generischen HTTP-Server mit Server-Architektur der 90er. Der Server
sollte schon da sein, und nicht erst vom inetd gestartet werden.

Einen solchen Server von Null an zu schreiben ist wirklich kein Hexenwerk.

>> Und all das lässt sich durch Vergrößerung der Datenmenge reduzieren.
>> Mehr Daten in der Payload = Kernel hat immer was zu senden = Overhead
>> geht besser unter.
>
> Meine Server machen ca 5 GB/s Durchsatz. In dem Bereich muesste ich Daten
> verschicken um den Overhead zu minimieren. Das ist bei langsamer
> Client-Anbindung (DSL, WLAN, etc) unbrauchbar.

Deswegen adaptiv. Wie lange brauchen 64k? Wenn unter einer Sekunde: wie
lange brauchen 256k? Und so weiter.

>>>> Fehlkonfigurationen ausgenommen wird kein Browser der letzten 20 Jahre
>>>> wirklich für jeden Request eine neue Verbindung aufbauen.
>>>
>>> Wenn ihm das die Gegenseite vorschreibt, schon.
>>> Da gibts mehrere Moeglichkeit. Eine davon waere ein Proxy.
>>> Oder mein tcpbm Server.
>>
>> Ich gehe natürlich von einem angepassten Server aus. Also keinem, der
>> bei so einem Benchmark-Request erst das CGI vom NFS startet.
>
> Einen Proxy kannst du nicht beeinflussen. Du musst den benutzen, so, wie
> er ist.

Eine synthetische Bandbreitenmessung über einen Proxy ist aber auch
ziemlich absurd.

Stefan

Ulli Horlacher

unread,

Jun 12, 2019, 5:28:40 PM6/12/19

to

Stefan Reuther <stefa...@arcor.de> wrote:

> Ich gehe natürlich davon aus, dass ein Übertragungsratenmesstool als
> Gegenseite einen Übertragensratenmesstoolserver hat und keinen
> generischen HTTP-Server mit Server-Architektur der 90er. Der Server
> sollte schon da sein, und nicht erst vom inetd gestartet werden.
>
> Einen solchen Server von Null an zu schreiben ist wirklich kein Hexenwerk.

Bitte, mach das, wenn das doch SO einfach ist.

> >> Und all das lässt sich durch Vergrößerung der Datenmenge reduzieren.
> >> Mehr Daten in der Payload = Kernel hat immer was zu senden = Overhead
> >> geht besser unter.
> >
> > Meine Server machen ca 5 GB/s Durchsatz. In dem Bereich muesste ich Daten
> > verschicken um den Overhead zu minimieren. Das ist bei langsamer
> > Client-Anbindung (DSL, WLAN, etc) unbrauchbar.
>
> Deswegen adaptiv. Wie lange brauchen 64k? Wenn unter einer Sekunde: wie
> lange brauchen 256k? Und so weiter.

Auch das ist zu viel Overhead und verfaelscht das Ergebnis.

> > Einen Proxy kannst du nicht beeinflussen. Du musst den benutzen, so, wie
> > er ist.
>
> Eine synthetische Bandbreitenmessung über einen Proxy ist aber auch
> ziemlich absurd.

Manche Leute kommen nur ueber einen Proxy ins Internet.
Die wollen trozdem wissen, wie schnell es geht.
Mit meinem tcpbm koennen sie das feststellen.

Ralph Aichinger

unread,

Jun 12, 2019, 5:55:46 PM6/12/19

to

Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
> Manche Leute kommen nur ueber einen Proxy ins Internet.

Chinesen? Schüler, die das Schul-WLAN verwenden weil
die Datenmenge vom Handy überschritten ist?

Manfred Haertel

unread,

Jun 13, 2019, 12:00:05 AM6/13/19

to

Ralph Aichinger schrieb:

> Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
>> Manche Leute kommen nur ueber einen Proxy ins Internet.
>
> Chinesen? Schüler, die das Schul-WLAN verwenden weil
> die Datenmenge vom Handy überschritten ist?

Jeder Mitarbeiter eines Unternehmens?

--
Manfred Härtel, DB3HM mailto:Manfred...@rz-online.de
http://rz-home.de/mhaertel

Ralph Aichinger

unread,

Jun 13, 2019, 1:40:45 AM6/13/19

to

Manfred Haertel <Manfred...@rz-online.de> wrote:
> Ralph Aichinger schrieb:
>
>> Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
>>> Manche Leute kommen nur ueber einen Proxy ins Internet.
>>
>> Chinesen? Schüler, die das Schul-WLAN verwenden weil
>> die Datenmenge vom Handy überschritten ist?
>
> Jeder Mitarbeiter eines Unternehmens?

Es mag solche Dinge geben, aber sehr häufig kann das nicht mehr
sein: In der IT-Branche z.B. kann ich mir das gar nicht vorstellen,
ohne direkten Zugriff aufs Internet kann man wohl nicht sinnvoll
Webservices testen.

Auch in anderen Branchen stell ich mir die Nützlichkeit nur
mehr begrenzt vor: Dank HTTPS kann es sowieso nur sinnvoll
funktionieren wenn man lokal auf den Clients Zertifikate
unterschieben kann, d.h. einen völlig zugenagelten Client
mit entsprechender Supportinfrastruktur hat. Gibts sicher,
z.B. in Banken, aber der durchschnittliche Mittelbetrieb
tut sich sowas nicht an, wenn die Mitarbeiter sowieso ein
nicht zu beschränkendes Handy in der Tasche haben, mit dem
sie gesperrte oder mitgehörte Seiten ansurfen können.

Gibt es belastbare Zahlen wieviel Prozent der User heute
hinter Proxies sitzen?

Ich hab eine Zeit lang in viele viele Kundennetzwerke
reingesehen und bei hunderten Kunden hab ich nur 2
wahrgenommen die Proxies als Forward- (nicht Reverse Proxy)
verwendet haben. Beide aus dem Schulbereich.

Nein, es waren keine Banken und Finanzdienstleister drunter,
sondern viele Autozulieferer und anderen industriellen
Mittelbetriebe, aber da hat es IIRC nirgends einen Proxy gegeben.
Häufig ist es bestimmt nicht, alleine schon wegen der
Kosten.

Ich hab ein bißchen danach gegooglet aber nicht viel aussage-
kräftiges gefunden.

Stefan Reuther

unread,

Jun 14, 2019, 12:14:50 PM6/14/19

to

Am 12.06.2019 um 23:28 schrieb Ulli Horlacher:
> Stefan Reuther <stefa...@arcor.de> wrote:
>> Ich gehe natürlich davon aus, dass ein Übertragungsratenmesstool als
>> Gegenseite einen Übertragensratenmesstoolserver hat und keinen
>> generischen HTTP-Server mit Server-Architektur der 90er. Der Server
>> sollte schon da sein, und nicht erst vom inetd gestartet werden.
>>
>> Einen solchen Server von Null an zu schreiben ist wirklich kein Hexenwerk.
>
> Bitte, mach das, wenn das doch SO einfach ist.

Siehe unten, knappe Dreiviertelstunde. Kann sicher noch ein, zwei
Reviews vertragen, und etwas Härtung gegen DoS/Teergrube, etwas
verbesserte Protokollparserei. Ebenso wäre eine spannende Übung, poll()
zu verwenden und auf fork() zu verzichten. Getestet mit curl und wget.
100k-Download: wget http://127.0.0.1:8000/filename?size=100000

Einen HTTP-Server zu hacken würde ich heute fast als Grundqualifikation
sehen. Das schöne an den RfC-Protokollen ist, dass man mit erstaunlich
wenig Aufwand erstaunlich viel erreichen kann.

>>>> Und all das lässt sich durch Vergrößerung der Datenmenge reduzieren.
>>>> Mehr Daten in der Payload = Kernel hat immer was zu senden = Overhead
>>>> geht besser unter.
>>>
>>> Meine Server machen ca 5 GB/s Durchsatz. In dem Bereich muesste ich Daten
>>> verschicken um den Overhead zu minimieren. Das ist bei langsamer
>>> Client-Anbindung (DSL, WLAN, etc) unbrauchbar.
>>
>> Deswegen adaptiv. Wie lange brauchen 64k? Wenn unter einer Sekunde: wie
>> lange brauchen 256k? Und so weiter.
>
> Auch das ist zu viel Overhead und verfaelscht das Ergebnis.

Irgendwie gewinne ich schon den Eindruck, du willst nur hören/sagen,
dass alles doof ist, aber nur keine Lösung. Adaptiv = solange die
Parameter austarieren, bis der Overhead verschwindet, dann messen.

>>> Einen Proxy kannst du nicht beeinflussen. Du musst den benutzen, so, wie
>>> er ist.
>>
>> Eine synthetische Bandbreitenmessung über einen Proxy ist aber auch
>> ziemlich absurd.
>
> Manche Leute kommen nur ueber einen Proxy ins Internet.
> Die wollen trozdem wissen, wie schnell es geht.
> Mit meinem tcpbm koennen sie das feststellen.

Dann wissen sie, wie schnell HTTP über den Proxy geht. Das wissen sie
aber auch, wenn sie einen Up- oder Download machen. Und dann wissen sie
nicht, wie schnell ein nicht auf HTTP basierendes Protokoll ist. F*EX
war doch sowas?

Stefan

----8<--------8<----[nullserver.c]----8<--------8<----
/*
* Quick & Dirty HTTP server
*
* Accepts any request.
* POST data is just swallowed.
* If the request URI contains a "size=N" token, that is the size of the response in bytes.
*/

#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <sys/wait.h>
#include <sys/time.h>
#include <stdio.h>
#include <errno.h>
#include <stdlib.h>
#include <string.h>
#include <ctype.h>
#include <unistd.h>

#define PORT 8000
#define MIN(a,b) ((a)<(b) ? (a) : (b))
#define CHECK(x) check(x, #x)

static int check(int result, const char* what)
{
if (result == -1) {
fprintf(stderr, "error in %s: %s\n", what, strerror(errno));
exit(1);
}
return result;
}

static int read_line(int fd, char* buf, size_t len)
{
char ch;
while (1) {
if (read(fd, &ch, 1) != 1) {
return 0;
}
if (ch == '\n') {
*buf = '\0';
return 1;
}
if (ch != '\r' && len > 1) {
*buf++ = tolower((unsigned char) ch);
--len;
}
}
}

static void handle_connection(int fd)
{
static const char zeroes[16384] = {};
char buffer[16384];

while (1) {
// Read first line
if (!read_line(fd, buffer, sizeof buffer)) {
// Probably means they closed the connection although it was a keepalive connection
return;
}

// Check parameters
int is_post = (strncmp(buffer, "post", 4) == 0);
int keepalive = (strstr(buffer, "http/1.1") != 0);
size_t result_size = 0;
char* p = strstr(buffer, "size=");
if (p) {
result_size = strtoul(p+5, 0, 10);
}
size_t post_size = 0;

// Read header
while (1) {
if (!read_line(fd, buffer, sizeof buffer)) {
printf("Failed to read header line\n");
return;
}
if (buffer[0] == '\0') {
break;
}
if (strncmp(buffer, "content-length:", 15) == 0) {
post_size = strtoul(buffer+15, 0, 0);
}
if (strncmp(buffer, "connection:", 11) == 0) {
keepalive = strstr(buffer, "keep-alive") != 0;
}
}
printf("Request: upload %zd bytes, download %zd bytes\n", post_size, result_size);

// For POST, read body
while (is_post && post_size > 0) {
int n = read(fd, buffer, MIN(post_size, sizeof buffer));
if (n <= 0) {
printf("Failed to read POST body\n");
return;
}
post_size -= n;
}

// Response header
sprintf(buffer,
"HTTP/1.1 200 OK\r\n"
"Connection: %s\r\n"
"Content-Type: application/octet-stream\r\n"
"Content-Length: %zd\r\n\r\n",
keepalive ? "keep-alive" : "close",
result_size);
if (write(fd, buffer, strlen(buffer)) != (int)strlen(buffer)) {
printf("Failed to write response header\n");
return;
}

// Send response
while (result_size > 0) {
int n = write(fd, zeroes, MIN(result_size, sizeof(zeroes)));
if (n <= 0) {
printf("Failed to write response\n");
return;
}
result_size -= n;
}

if (!keepalive) {
break;
}
}
}

int main()
{
// Set up a socket
int listen_fd;
struct sockaddr_in me;

CHECK(listen_fd = socket(AF_INET, SOCK_STREAM, 0));

int one = 1;
CHECK(setsockopt(listen_fd, SOL_SOCKET, SO_REUSEADDR, &one, sizeof(one)));

me.sin_family = AF_INET;
me.sin_port = htons(PORT);
me.sin_addr.s_addr = 0;
CHECK(bind(listen_fd, (struct sockaddr*)&me, sizeof(me)));

CHECK(listen(listen_fd, 10));

// Main loop
printf("Listening...\n");
while (1) {
struct sockaddr_in them;
socklen_t their_size = sizeof(them);
int connection_fd;

CHECK(connection_fd = accept(listen_fd, (struct sockaddr*)&them, &their_size));

struct timeval tv;
tv.tv_sec = 10;
tv.tv_usec = 0;
CHECK(setsockopt(connection_fd, SOL_SOCKET, SO_RCVTIMEO, &tv, sizeof(tv)));
CHECK(setsockopt(connection_fd, SOL_SOCKET, SO_SNDTIMEO, &tv, sizeof(tv)));

pid_t pid = fork();
if (pid == 0) {
// Child
close(listen_fd);
handle_connection(connection_fd);
close(connection_fd);
_exit(0);
} else {
// Parent
printf("Got connection fd=%d, pid=%d\n", connection_fd, (int) pid);
close(connection_fd);

// Reap ripe children
pid_t other_child;
int status;
while ((other_child = waitpid(-1, &status, WNOHANG)) > 0) {
printf("Child %d done\n", (int) other_child);
}
}
}
}

Arno Welzel

unread,

Jun 15, 2019, 12:33:07 PM6/15/19

to

Manfred Haertel:

> Ralph Aichinger schrieb:
>
>> Ulli Horlacher <fram...@rus.uni-stuttgart.de> wrote:
>>> Manche Leute kommen nur ueber einen Proxy ins Internet.
>>
>> Chinesen? Schüler, die das Schul-WLAN verwenden weil
>> die Datenmenge vom Handy überschritten ist?
>
> Jeder Mitarbeiter eines Unternehmens?

Ich habe schon in diversen Unternehmen gearbeitet, wo es keinen Proxy gab.