Groups > de.comp.lang.javascript > #5044 > unrolled thread

HTTP POST?

Started by	Ulli Horlacher <framstag@rus.uni-stuttgart.de>
First post	2019-05-31 18:04 +0000
Last post	2019-06-11 11:57 +0200
Articles	20 on this page of 81 — 8 participants

Back to article view | Back to de.comp.lang.javascript

  HTTP POST? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2019-05-31 18:04 +0000
    Re: HTTP POST? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2019-05-31 21:03 +0200
      Re: HTTP POST? Arno Welzel <usenet@arnowelzel.de> - 2019-06-01 13:18 +0200
        Re: HTTP POST? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2019-06-01 14:15 +0200
          Re: HTTP POST? Arno Welzel <usenet@arnowelzel.de> - 2019-06-01 14:34 +0200
            Re: HTTP POST? Arno Welzel <usenet@arnowelzel.de> - 2019-06-01 14:37 +0200
            Re: HTTP POST? Ralph Aichinger <ra@pi.h5.or.at> - 2019-06-01 15:11 +0200
              Re: HTTP POST? Arno Welzel <usenet@arnowelzel.de> - 2019-06-01 15:44 +0200
              Re: HTTP POST? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2019-06-01 16:07 +0200
                Re: HTTP POST? Arno Welzel <usenet@arnowelzel.de> - 2019-06-01 20:17 +0200
            Re: HTTP POST? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2019-06-01 18:43 +0200
              Re: HTTP POST? Arno Welzel <usenet@arnowelzel.de> - 2019-06-01 20:19 +0200
                Re: HTTP POST? Arno Welzel <usenet@arnowelzel.de> - 2019-06-01 22:45 +0200
                  Re: HTTP POST? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2019-06-02 05:02 +0200
                    Re: HTTP POST? Arno Welzel <usenet@arnowelzel.de> - 2019-06-02 18:05 +0200
                  Re: HTTP POST? Claus Reibenstein <4spamersonly@kabelmail.de> - 2019-06-02 09:37 +0200
                    Re: HTTP POST? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2019-06-02 13:39 +0200
                      Re: HTTP POST? Arno Welzel <usenet@arnowelzel.de> - 2019-06-02 18:12 +0200
                Re: HTTP POST? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2019-06-02 04:06 +0200
                  Re: HTTP POST? Arno Welzel <usenet@arnowelzel.de> - 2019-06-02 18:22 +0200
        Re: HTTP POST? Jan Novak <repcom@gmail.com> - 2019-06-03 14:54 +0200
    Re: HTTP POST? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2019-06-02 10:44 +0000
      Re: HTTP POST? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2019-06-02 14:00 +0200
      Re: HTTP POST? Stefan Reuther <stefan.news@arcor.de> - 2019-06-02 17:14 +0200
        Re: HTTP POST? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2019-06-02 21:02 +0000
          Re: HTTP POST? Arno Welzel <usenet@arnowelzel.de> - 2019-06-03 00:06 +0200
            Re: HTTP POST? Arno Welzel <usenet@arnowelzel.de> - 2019-06-03 00:47 +0200
              Re: HTTP POST? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2019-06-03 06:06 +0000
                Re: HTTP POST? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2019-06-03 18:43 +0200
          Re: HTTP POST? Claus Reibenstein <4spamersonly@kabelmail.de> - 2019-06-03 12:38 +0200
            Re: HTTP POST? Arno Welzel <usenet@arnowelzel.de> - 2019-06-03 15:51 +0200
              Re: HTTP POST? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2019-06-03 20:26 +0000
                Re: HTTP POST? Arno Welzel <usenet@arnowelzel.de> - 2019-06-04 19:31 +0200
                  Re: HTTP POST? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2019-06-05 06:09 +0000
              Re: HTTP POST? Claus Reibenstein <4spamersonly@kabelmail.de> - 2019-06-04 21:48 +0200
                Re: HTTP POST? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2019-06-05 06:14 +0000
          Re: HTTP POST? Stefan Reuther <stefan.news@arcor.de> - 2019-06-03 18:34 +0200
            Re: HTTP POST? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2019-06-03 20:31 +0000
              Re: HTTP POST? Stefan Reuther <stefan.news@arcor.de> - 2019-06-04 18:09 +0200
                Re: HTTP POST? Manfred Haertel <Manfred.Haertel@rz-online.de> - 2019-06-05 05:50 +0200
                Re: HTTP POST? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2019-06-05 06:30 +0000
                  Re: HTTP POST? Ralph Aichinger <ra@pi.h5.or.at> - 2019-06-05 15:07 +0200
                  Re: HTTP POST? Stefan Reuther <stefan.news@arcor.de> - 2019-06-05 18:09 +0200
                  Re: HTTP POST? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2019-06-05 20:25 +0000
                    Re: HTTP POST? Claus Reibenstein <4spamersonly@kabelmail.de> - 2019-06-06 09:49 +0200
                      Re: HTTP POST? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2019-06-06 08:47 +0000
                    Re: HTTP POST? Arno Welzel <usenet@arnowelzel.de> - 2019-06-08 14:53 +0200
                      Re: HTTP POST? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2019-06-08 19:31 +0000
                  Re: HTTP POST? Arno Welzel <usenet@arnowelzel.de> - 2019-06-08 14:50 +0200
                    Re: HTTP POST? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2019-06-08 19:34 +0000
                      Re: HTTP POST? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2019-06-09 00:45 +0200
                        Re: HTTP POST? Arno Welzel <usenet@arnowelzel.de> - 2019-06-10 17:29 +0200
                      Re: HTTP POST? Stefan Reuther <stefan.news@arcor.de> - 2019-06-09 11:10 +0200
                        Re: HTTP POST? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2019-06-09 12:06 +0000
                          Re: HTTP POST? Stefan Reuther <stefan.news@arcor.de> - 2019-06-10 11:16 +0200
                            Re: HTTP POST? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2019-06-10 09:47 +0000
                              Re: HTTP POST? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2019-06-10 20:35 +0200
                              Re: HTTP POST? Stefan Reuther <stefan.news@arcor.de> - 2019-06-11 17:50 +0200
                                Re: HTTP POST? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2019-06-11 20:02 +0000
                                  Re: HTTP POST? Ralph Aichinger <ra@pi.h5.or.at> - 2019-06-12 07:45 +0200
                                    Re: HTTP POST? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2019-06-12 06:08 +0000
                                      Re: HTTP POST? Ralph Aichinger <ra@pi.h5.or.at> - 2019-06-12 10:16 +0200
                                        Re: HTTP POST? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2019-06-12 09:05 +0000
                                  Re: HTTP POST? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2019-06-12 10:37 +0200
                                  Re: HTTP POST? Stefan Reuther <stefan.news@arcor.de> - 2019-06-12 18:14 +0200
                                    Re: HTTP POST? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2019-06-12 21:28 +0000
                                      Re: HTTP POST? Ralph Aichinger <ra@pi.h5.or.at> - 2019-06-12 23:55 +0200
                                        Re: HTTP POST? Manfred Haertel <Manfred.Haertel@rz-online.de> - 2019-06-13 05:35 +0200
                                          Re: HTTP POST? Ralph Aichinger <ra@pi.h5.or.at> - 2019-06-13 07:40 +0200
                                          Re: HTTP POST? Arno Welzel <usenet@arnowelzel.de> - 2019-06-15 18:33 +0200
                                      Re: HTTP POST? Stefan Reuther <stefan.news@arcor.de> - 2019-06-14 18:08 +0200
                            Re: HTTP POST? Claus Reibenstein <4spamersonly@kabelmail.de> - 2019-06-10 17:37 +0200
                              Re: HTTP POST? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2019-06-10 16:31 +0000
                                Re: HTTP POST? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2019-06-10 21:45 +0200
                                  Re: HTTP POST? Ralph Aichinger <ra@pi.h5.or.at> - 2019-06-10 22:04 +0200
                                    Re: HTTP POST? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2019-06-11 00:23 +0200
                                      Re: HTTP POST? Ralph Aichinger <ra@pi.h5.or.at> - 2019-06-11 00:33 +0200
                                        Re: HTTP POST? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2019-06-11 01:01 +0200
                              Re: HTTP POST? Ralph Aichinger <ra@pi.h5.or.at> - 2019-06-10 20:24 +0200
                              Re: HTTP POST? Arno Welzel <usenet@arnowelzel.de> - 2019-06-11 10:48 +0200
                                Re: HTTP POST? Claus Reibenstein <4spamersonly@kabelmail.de> - 2019-06-11 11:57 +0200

Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →

#5073

From	Jan Novak <repcom@gmail.com>
Date	2019-06-03 14:54 +0200
Message-ID	<qd35ad$spl$1@news.albasani.net>
In reply to	#5046

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

[toc] | [prev] | [next] | [standalone]

#5061

From	Ulli Horlacher <framstag@rus.uni-stuttgart.de>
Date	2019-06-02 10:44 +0000
Message-ID	<qd09a7$8ii$1@news2.informatik.uni-stuttgart.de>
In reply to	#5044

Stefan Ram <ram@zedat.fu-berlin.de> wrote:
> Ulli Horlacher <framstag@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
             
             
-- 
Ullrich Horlacher              Server und Virtualisierung
Rechenzentrum TIK         
Universitaet Stuttgart         E-Mail: horlacher@tik.uni-stuttgart.de
Allmandring 30a                Tel:    ++49-711-68565868
70569 Stuttgart (Germany)      WWW:    http://www.tik.uni-stuttgart.de/

[toc] | [prev] | [next] | [standalone]

#5063

From	Thomas 'PointedEars' Lahn <PointedEars@web.de>
Date	2019-06-02 14:00 +0200
Message-ID	<5475324.o23Uhz9pxI@PointedEars.de>
In reply to	#5061

Ulli Horlacher wrote:

> Stefan Ram <ram@zedat.fu-berlin.de> wrote:
>> Ulli Horlacher <framstag@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.

-- 
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.

[toc] | [prev] | [next] | [standalone]

#5064

From	Stefan Reuther <stefan.news@arcor.de>
Date	2019-06-02 17:14 +0200
Message-ID	<qd105o.15o.1@stefan.msgid.phost.de>
In reply to	#5061

Am 02.06.2019 um 12:44 schrieb Ulli Horlacher:
> Stefan Ram <ram@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

[toc] | [prev] | [next] | [standalone]

#5068

From	Ulli Horlacher <framstag@rus.uni-stuttgart.de>
Date	2019-06-02 21:02 +0000
Message-ID	<qd1dhs$hgf$1@news2.informatik.uni-stuttgart.de>
In reply to	#5064

Stefan Reuther <stefan.news@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.

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

[toc] | [prev] | [next] | [standalone]

#5069

From	Arno Welzel <usenet@arnowelzel.de>
Date	2019-06-03 00:06 +0200
Message-ID	<glivjhFghduU1@mid.individual.net>
In reply to	#5068

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
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#5070

From	Arno Welzel <usenet@arnowelzel.de>
Date	2019-06-03 00:47 +0200
Message-ID	<glj202Fh0k7U1@mid.individual.net>
In reply to	#5069

Arno Welzel:

> 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.

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.


-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#5071

From	Ulli Horlacher <framstag@rus.uni-stuttgart.de>
Date	2019-06-03 06:06 +0000
Message-ID	<qd2dd9$q4j$1@news2.informatik.uni-stuttgart.de>
In reply to	#5070

Arno Welzel <usenet@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?


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

[toc] | [prev] | [next] | [standalone]

#5075

From	Thomas 'PointedEars' Lahn <PointedEars@web.de>
Date	2019-06-03 18:43 +0200
Message-ID	<1898474.8cmVLJjO1I@PointedEars.de>
In reply to	#5071

Ulli Horlacher wrote:

> Arno Welzel <usenet@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.
 
-- 
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.

[toc] | [prev] | [next] | [standalone]

#5072

From	Claus Reibenstein <4spamersonly@kabelmail.de>
Date	2019-06-03 12:38 +0200
Message-ID	<glkbkqFpe7eU1@mid.individual.net>
In reply to	#5068

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

[toc] | [prev] | [next] | [standalone]

#5074

From	Arno Welzel <usenet@arnowelzel.de>
Date	2019-06-03 15:51 +0200
Message-ID	<glkmvpFrpmrU1@mid.individual.net>
In reply to	#5072

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.


-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#5077

From	Ulli Horlacher <framstag@rus.uni-stuttgart.de>
Date	2019-06-03 20:26 +0000
Message-ID	<qd3vp9$77g$1@news2.informatik.uni-stuttgart.de>
In reply to	#5074

Arno Welzel <usenet@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


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

[toc] | [prev] | [next] | [standalone]

#5080

From	Arno Welzel <usenet@arnowelzel.de>
Date	2019-06-04 19:31 +0200
Message-ID	<glno80FhbuuU3@mid.individual.net>
In reply to	#5077

Ulli Horlacher:

> Arno Welzel <usenet@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?

-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#5083

From	Ulli Horlacher <framstag@rus.uni-stuttgart.de>
Date	2019-06-05 06:09 +0000
Message-ID	<qd7mar$5go$1@news2.informatik.uni-stuttgart.de>
In reply to	#5080

Arno Welzel <usenet@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.

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

[toc] | [prev] | [next] | [standalone]

#5081

From	Claus Reibenstein <4spamersonly@kabelmail.de>
Date	2019-06-04 21:48 +0200
Message-ID	<glo08hFj3fsU2@mid.individual.net>
In reply to	#5074

Arno Welzel schrieb am 03.06.2019 um 15:51:

> 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.

Und Du hast dort tatsächlich diese Zeit gemessen?

Gruß
Claus

[toc] | [prev] | [next] | [standalone]

#5084

From	Ulli Horlacher <framstag@rus.uni-stuttgart.de>
Date	2019-06-05 06:14 +0000
Message-ID	<qd7mjc$5go$2@news2.informatik.uni-stuttgart.de>
In reply to	#5081

Claus Reibenstein <4spamersonly@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.

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

[toc] | [prev] | [next] | [standalone]

#5076

From	Stefan Reuther <stefan.news@arcor.de>
Date	2019-06-03 18:34 +0200
Message-ID	<qd3p87.2go.1@stefan.msgid.phost.de>
In reply to	#5068

Am 02.06.2019 um 23:02 schrieb Ulli Horlacher:
> Stefan Reuther <stefan.news@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

[toc] | [prev] | [next] | [standalone]

#5078

From	Ulli Horlacher <framstag@rus.uni-stuttgart.de>
Date	2019-06-03 20:31 +0000
Message-ID	<qd403l$77g$2@news2.informatik.uni-stuttgart.de>
In reply to	#5076

Stefan Reuther <stefan.news@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         
Universitaet Stuttgart         E-Mail: horlacher@tik.uni-stuttgart.de
Allmandring 30a                Tel:    ++49-711-68565868
70569 Stuttgart (Germany)      WWW:    http://www.tik.uni-stuttgart.de/

[toc] | [prev] | [next] | [standalone]

#5079

From	Stefan Reuther <stefan.news@arcor.de>
Date	2019-06-04 18:09 +0200
Message-ID	<qd6c5f.368.1@stefan.msgid.phost.de>
In reply to	#5078

Am 03.06.2019 um 22:31 schrieb Ulli Horlacher:
> Stefan Reuther <stefan.news@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

[toc] | [prev] | [next] | [standalone]

#5082

From	Manfred Haertel <Manfred.Haertel@rz-online.de>
Date	2019-06-05 05:50 +0200
Message-ID	<0qqjsf-f52.ln1@haertel.userfqdn.rhein-zeitung.de>
In reply to	#5079

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.Haertel@rz-online.de
                          http://rz-home.de/mhaertel

[toc] | [prev] | [next] | [standalone]

Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →

csiph-web

HTTP POST?

Contents

#5073

#5061

#5063

#5064

#5068

#5069

#5070

#5071

#5075

#5072

#5074

#5077

#5080

#5083

#5081

#5084

#5076

#5078

#5079

#5082