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 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →

#5116

From	Ulli Horlacher <framstag@rus.uni-stuttgart.de>
Date	2019-06-12 06:08 +0000
Message-ID	<qdq4t1$v3p$1@news2.informatik.uni-stuttgart.de>
In reply to	#5115

Ralph Aichinger <ra@pi.h5.or.at> wrote:
> Ulli Horlacher <framstag@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.


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

#5117

From	Ralph Aichinger <ra@pi.h5.or.at>
Date	2019-06-12 10:16 +0200
Message-ID	<qdqcc9$bk4$1@pi.h5.or.at>
In reply to	#5116

Ulli Horlacher <framstag@rus.uni-stuttgart.de> wrote:
> Ralph Aichinger <ra@pi.h5.or.at> wrote:
>> Ulli Horlacher <framstag@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)?

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

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

#5119

From	Ulli Horlacher <framstag@rus.uni-stuttgart.de>
Date	2019-06-12 09:05 +0000
Message-ID	<qdqf8g$1vc$1@news2.informatik.uni-stuttgart.de>
In reply to	#5117

Ralph Aichinger <ra@pi.h5.or.at> wrote:
> Ulli Horlacher <framstag@rus.uni-stuttgart.de> wrote:
> > Ralph Aichinger <ra@pi.h5.or.at> wrote:
> >> Ulli Horlacher <framstag@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.



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

#5118

From	Thomas 'PointedEars' Lahn <PointedEars@web.de>
Date	2019-06-12 10:37 +0200
Message-ID	<7615935.T7Z3S40VBb@PointedEars.de>
In reply to	#5114

Ulli Horlacher wrote:

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

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

#5120

From	Stefan Reuther <stefan.news@arcor.de>
Date	2019-06-12 18:14 +0200
Message-ID	<qdrfe7.4t0.1@stefan.msgid.phost.de>
In reply to	#5114

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

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

#5121

From	Ulli Horlacher <framstag@rus.uni-stuttgart.de>
Date	2019-06-12 21:28 +0000
Message-ID	<qdrqq8$cu6$1@news2.informatik.uni-stuttgart.de>
In reply to	#5120

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


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

#5122

From	Ralph Aichinger <ra@pi.h5.or.at>
Date	2019-06-12 23:55 +0200
Message-ID	<qdrscu$iik$1@pi.h5.or.at>
In reply to	#5121

Ulli Horlacher <framstag@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?

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

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

#5123

From	Manfred Haertel <Manfred.Haertel@rz-online.de>
Date	2019-06-13 05:35 +0200
Message-ID	<2ts8tf-ia2.ln1@haertel.userfqdn.rhein-zeitung.de>
In reply to	#5122

Ralph Aichinger schrieb:

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

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

#5124

From	Ralph Aichinger <ra@pi.h5.or.at>
Date	2019-06-13 07:40 +0200
Message-ID	<qdsnkr$96o$1@pi.h5.or.at>
In reply to	#5123

Manfred Haertel <Manfred.Haertel@rz-online.de> wrote:
> Ralph Aichinger schrieb:
> 
>> Ulli Horlacher <framstag@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.

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

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

#5131

From	Arno Welzel <usenet@arnowelzel.de>
Date	2019-06-15 18:33 +0200
Message-ID	<gmkku2Fp8l7U5@mid.individual.net>
In reply to	#5123

Manfred Haertel:

> Ralph Aichinger schrieb:
> 
>> Ulli Horlacher <framstag@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.


-- 
Arno Welzel
https://arnowelzel.de

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

#5130

From	Stefan Reuther <stefan.news@arcor.de>
Date	2019-06-14 18:08 +0200
Message-ID	<qe0nr3.as.1@stefan.msgid.phost.de>
In reply to	#5121

Am 12.06.2019 um 23:28 schrieb Ulli Horlacher:
> Stefan Reuther <stefan.news@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);
            }
        }
    }
}

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

#5102

From	Claus Reibenstein <4spamersonly@kabelmail.de>
Date	2019-06-10 17:37 +0200
Message-ID	<gm7bqoFsrrjU1@mid.individual.net>
In reply to	#5099

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

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

#5103

From	Ulli Horlacher <framstag@rus.uni-stuttgart.de>
Date	2019-06-10 16:31 +0000
Message-ID	<qdm0l9$sm7$1@news2.informatik.uni-stuttgart.de>
In reply to	#5102

Claus Reibenstein <4spamersonly@kabelmail.de> wrote:
> 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.

Das ist UNSINN.
HTTP basiert auf tcp und das ist (im Gegensatz zu udp) ein
verbindungsorientiertes Protokoll.

Das, was du beschreibst, gibt es nicht.


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

#5106

From	Thomas 'PointedEars' Lahn <PointedEars@web.de>
Date	2019-06-10 21:45 +0200
Message-ID	<5261878.DvuYhMxLoT@PointedEars.de>
In reply to	#5103

Ulli Horlacher wrote:

> Claus Reibenstein <4spamersonly@kabelmail.de> wrote:
>> 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.

Nein, HTTP ist vom *ursprünglichen* Design her ein _zustandsloses_ 
(stateless) Protokoll.  („verbindungslos“ wäre „connectionless“; das gibt es 
nicht, weil das ein Widerspruch in sich wäre, siehe unten.)

Dass HTTP “stateless“ ist, ist aber auch nur auf dem Application Layer 
richtig (und gilt deshalb für HTTP-Anwendungen wie REST), und 
uneingeschränkt auch nur bis HTTP/1.0 (RFC 1945).  Denn HTTP/1.1 (RFC 2616 
etc.) führt (AISB) “persistent connections” *per Default* ein (in HTTP/1.0 
musste man das noch explizit per “Connection: keep-alive” wollen), d. h. für 
die Kommunikation mit einem Web-Server wird *einmalig* eine TCP-Verbindung 
aufgebaut, die dann für weitere Requests wiederverwendet werden kann (ausser 
der HTTP-Server sendet das Response-Headerfeld “Connection: close” oder 
beendet von sich aus die Verbindung).

<https://tools.ietf.org/html/rfc2616>
<https://tools.ietf.org/html/rfc7230#appendix-A.1.2>

Beispiel für eine Verbindung mit *zwei* HTTP-Requests (kann man leicht 
selbst ausprobieren; die Zeilen, die auf HTTP/1.1 enden, und das Ctrl+C, 
habe ich von Hand eingegeben – normalerweise sendet ersteres ein Web-
Browser):

| $ telnet www.google.com http
| Trying 172.217.168.4...
| Connected to www.google.com.
| Escape character is '^]'.
| HEAD / HTTP/1.1
| 
| HTTP/1.1 200 OK
| Date: Mon, 10 Jun 2019 19:29:18 GMT
| Expires: -1
| Cache-Control: private, max-age=0
| Content-Type: text/html; charset=ISO-8859-1
| P3P: CP="This is not a P3P policy! See g.co/p3phelp for more info."
| Server: gws
| X-XSS-Protection: 0
| X-Frame-Options: SAMEORIGIN
| Set-Cookie: 1P_JAR=2019-06-10-19; expires=Wed, 10-Jul-2019 19:29:18 GMT; 
| path=/; domain=.google.com
| Set-Cookie: NID=185=ZYFYsEIbFedPlgQ6s6yCsvli-
| 
MY5zXqcwVZFte9blbT8qvCVMWywX8G6YzFhrjUGp5GClqD_RaMmXYZTfn4Kmf4GtRkK7XAyu8O8CHBNj-
| jfSN44b0aYFiAHzx_gP9cMm-isNNiV8jt62jpFeV1GMmV2xhMMFyiPJSZBbZ7DLtw; 
| expires=Tue, 10-Dec-2019 19:29:18 GMT; path=/; domain=.google.com; 
HttpOnly
| Transfer-Encoding: chunked
| Accept-Ranges: none
| Vary: Accept-Encoding
| 
| HEAD /groups HTTP/1.1
| 
| HTTP/1.1 302 Found
| Location: https://groups.google.com/
| Cache-Control: private
| Content-Type: text/html; charset=UTF-8
| X-Content-Type-Options: nosniff
| Date: Mon, 10 Jun 2019 19:29:23 GMT
| Server: sffe
| Content-Length: 223
| X-XSS-Protection: 0
| 
| ^C
| Connection closed by foreign host.
| $
`----

Deshalb schrieb ich ja, dass die Behauptung, für weitere Requests gäbe es 
einen weiteren Overhead, heutzutage in der Regel Unsinn ist.

Die Anzahl der Verbindungen, die ein Web-Browser bzw. dessen HTTP-Client 
offenhält, ist auch AFAIK keine Begrenzung bezogen auf alle TCP-
Verbindungen, sondern auf alle Verbindungen zu *einem* HTTP-Server oder
-Proxy:

<https://tools.ietf.org/html/rfc2616#section-8.1.4>
<https://en.wikipedia.org/wiki/HTTP_persistent_connection#Use_in_web_browsers>

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

Nicht im allgemeinen, sondern nur hauptsächlich.

> HTTP basiert auf tcp

Nur ursprünglich (und es heisst _TCP_).

> und das ist (im Gegensatz zu udp) ein verbindungsorientiertes Protokoll.

Es gibt auch HTTP über _UDP_ (z. B. manchmal für Streaming und Downloads) 
und mit HTTP/3 (zuvor “HTTP-over-QUIC”) wird nur noch UDP verwendet werden:

<https://thenewstack.io/http-3-replaces-tcp-with-udp-to-boost-network-speed-reliability/>

(vom 16. Januar 2019)

> Das, was du beschreibst, gibt es nicht.

Es gibt jedenfalls keine „verbindungslosen“ Netzwerkprotokolle, denn der 
Zweck eines Netzwerkprotokolls ist ja gerade der Verbindungsaufbau für die 
Herstellung der Kommunikation.

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

#5107

From	Ralph Aichinger <ra@pi.h5.or.at>
Date	2019-06-10 22:04 +0200
Message-ID	<qdmd56$ou3$1@pi.h5.or.at>
In reply to	#5106

Thomas 'PointedEars' Lahn <PointedEars@web.de> wrote:
> Es gibt jedenfalls keine „verbindungslosen“ Netzwerkprotokolle, denn der 
> Zweck eines Netzwerkprotokolls ist ja gerade der Verbindungsaufbau für die 
> Herstellung der Kommunikation.

Naja, siehst du auch Protokolle wie LLDP wo eine Seite ein 
einzelnes Frame an eine Broadcast-Adresse schickt
und die zweite Seite nur horcht (oder auch grade nicht) als
"Verbindungen" an?

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

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

#5108

From	Thomas 'PointedEars' Lahn <PointedEars@web.de>
Date	2019-06-11 00:23 +0200
Message-ID	<5502381.lOV4Wx5bFT@PointedEars.de>
In reply to	#5107

Ralph Aichinger wrote:

> Thomas 'PointedEars' Lahn <PointedEars@web.de> wrote:
>> Es gibt jedenfalls keine „verbindungslosen“ Netzwerkprotokolle, denn der
>> Zweck eines Netzwerkprotokolls ist ja gerade der Verbindungsaufbau für
>> die Herstellung der Kommunikation.
> 
> Naja, siehst du auch Protokolle wie LLDP wo eine Seite ein
> einzelnes Frame an eine Broadcast-Adresse schickt
> und die zweite Seite nur horcht (oder auch grade nicht) als
> "Verbindungen" an?

<hint-hint-hint>

LLDP steht für “*Link* Layer Discovery Protocol”.

</hint-hint-hint>

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

#5109

From	Ralph Aichinger <ra@pi.h5.or.at>
Date	2019-06-11 00:33 +0200
Message-ID	<qdmlr1$2hc$1@pi.h5.or.at>
In reply to	#5108

Thomas 'PointedEars' Lahn <PointedEars@web.de> wrote:
> Ralph Aichinger wrote:
> 
>> Thomas 'PointedEars' Lahn <PointedEars@web.de> wrote:
>>> Es gibt jedenfalls keine „verbindungslosen“ Netzwerkprotokolle, denn der
>>> Zweck eines Netzwerkprotokolls ist ja gerade der Verbindungsaufbau für
>>> die Herstellung der Kommunikation.
>> 
>> Naja, siehst du auch Protokolle wie LLDP wo eine Seite ein
>> einzelnes Frame an eine Broadcast-Adresse schickt
>> und die zweite Seite nur horcht (oder auch grade nicht) als
>> "Verbindungen" an?
> 
> <hint-hint-hint>
> 
> LLDP steht für “*Link* Layer Discovery Protocol”.

Was willst du damit sagen? Du hast oben geschrieben,
daß es "jedenfalls keine verbindungslosen Netzwerkprotokolle"
gibt. Ist LLDP für dich kein Netzwerkprotokoll? Oder worauf
spielst du genau an?

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

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

#5110

From	Thomas 'PointedEars' Lahn <PointedEars@web.de>
Date	2019-06-11 01:01 +0200
Message-ID	<4479210.31r3eYUQgx@PointedEars.de>
In reply to	#5109

Ralph Aichinger wrote:

> Thomas 'PointedEars' Lahn <PointedEars@web.de> wrote:
>> Ralph Aichinger wrote:
>>> Thomas 'PointedEars' Lahn <PointedEars@web.de> wrote:
>>>> Es gibt jedenfalls keine „verbindungslosen“ Netzwerkprotokolle, denn
>>>> der Zweck eines Netzwerkprotokolls ist ja gerade der Verbindungsaufbau
>>>> für die Herstellung der Kommunikation.
>>> Naja, siehst du auch Protokolle wie LLDP wo eine Seite ein
>>> einzelnes Frame an eine Broadcast-Adresse schickt
>>> und die zweite Seite nur horcht (oder auch grade nicht) als
>>> "Verbindungen" an?
>> <hint-hint-hint>
>> 
>> LLDP steht für “*Link* Layer Discovery Protocol”.
> 
> Was willst du damit sagen? Du hast oben geschrieben,
> daß es "jedenfalls keine verbindungslosen Netzwerkprotokolle"
> gibt. Ist LLDP für dich kein Netzwerkprotokoll? Oder worauf
> spielst du genau an?

“link” ist Englisch für „Verbindung“.

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

#5104

From	Ralph Aichinger <ra@pi.h5.or.at>
Date	2019-06-10 20:24 +0200
Message-ID	<qdm78g$k6h$1@pi.h5.or.at>
In reply to	#5102

Claus Reibenstein <4spamersonly@kabelmail.de> wrote:
> HTTP ist nach meinen Informationen ein verbindungsloses Protokoll.
> Heißt: Es wird überhaupt keine Verbindung aufgebaut. Vielmehr schickt

Deine Informationen sind falsch.

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

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

#5111

From	Arno Welzel <usenet@arnowelzel.de>
Date	2019-06-11 10:48 +0200
Message-ID	<gm986dFam2cU4@mid.individual.net>
In reply to	#5102

Claus Reibenstein:

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

Aus Anwendungssicht, ja.

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


-- 
Arno Welzel
https://arnowelzel.de

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

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

csiph-web

HTTP POST?

Contents

#5116

#5117

#5119

#5118

#5120

#5121

#5122

#5123

#5124

#5131

#5130

#5102

#5103

#5106

#5107

#5108

#5109

#5110

#5104

#5111