Net::HTTP interner Puffer (Fragen zu Perl-Modulen)

[thread]16090[/thread]

Net::HTTP interner Puffer

Leser: 17

Articles: hide open all | hide show old branches

+15 replies
rosti

2011-03-19 23:01
User since
2011-03-19
3472 Artikel
BenutzerIn
Hallo liebe Gemeinde,

bischen Code:
Code: (dl )

1 2 3 4 5 6 7

my $i = 0; while(my $n = $nh->read_entity_body(my $record, 794)){ my($ts, $url, $hugo, $ref) = unpack "NZ255Z35Z500", $record; print "$n $ts $url\n"; last if ++$i == 3; last unless $n; }
Es müssen bei jedem Durchlauf exakt 794 Byte aus dem Socket gelesen werden, damit die Schablone in der unpack()-Funktion passt. Das Problem: read_entity_body liest ab dem zweiten Durchlauf nur 74 Byte, dann wieder 794. ($i ist nur zum Abkürzen)

In der Beschreibung zu Net:HTTP habe ich gelesen, dass intern gepuffert wird. Wie kann ich das abschalten? Ich verwende HTTP/1.0, ein Transfer-Encoding findet nicht statt, die Response kommt am Stück.

Die Response selbst ist ok, mit IO::Socket::INET werden die Records unzerknittert wieder hergestellt. Aus verschiedenen Gründen möchte ich jedoch Net::HTTP verwenden. Whats wrong?

Vielen Dank und Grüße,
Rolf
Last edited: 2011-03-20 00:34:11 +0100 (CET)
- +14 replies
- murphy
  
  2011-03-20 15:04
  User since
  2004-07-19
  1776 Artikel
  HausmeisterIn
  Ich glaube, die Pufferung kann man in diesem Falle nicht abstellen. Für den Fall, dass einzelne Records nicht auf einmal gelesen werden können, wäre es möglich, dass man den Körper mit einer Schleife einlesen muss, etwa so (ungestestet):
  
  Code (perl): (dl )
  
  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
  
  use 5.012; use warnings; use Errno qw/EINTR EAGAIN/; # ... initialization stuff ... RECORD_LOOP: while (1) { my $record = ""; READ_LOOP: while (length($record) < 794) { my $_; given ($nh->read_entity(my $chunk, 794 - length($record))) { last RECORD_LOOP when ($_ == 0 and length($record) == 0); next READ_LOOP when ($_ ~~ [ undef, -1 ] and $! ~~ [ EINTR, EAGAIN ]); die "I/O error: $!" when ([ undef, -1 ]); die "Unexpected end of file" when (0); default { $record .= $chunk; } } } # ... record processing ... }
  
  When C++ is your hammer, every problem looks like your thumb.
  - +13 replies
  - rosti
    
    2011-03-20 18:40
    
    User since
    2011-03-19
    3472 Artikel
    BenutzerIn
    
    Vielen Dank für Deine Mühe!
    
    Leider kann ich aufgrund meiner Perlversion den Code nicht testen. Soviel ich das Protocol HTTP/1.0 verstanden habe, gibt es kein Transfer-Encoding, kein chunked und die Response kommt am Stück. Im Request sende ich ein Connection: Close Header und kann die Response mit IO::Socket::INET einwandfrei lesen (anderes Script).
    
    In Summa bin ich am Überlegen, ob es vielleicht doch besser ist, ein eigenes kleines Modul zu schreiben, etwa Net::HTTP10 (nur HTTP/1.0) und ein eigenes Objekt erstellen dem eine Callbackfunktion mitgegeben wird, die exact 794 Bytes aus dem Socket liest (oder auch eine andere Anzahl an Bytes, je nach Verwendung, es geht um die Übertragung Binärer Sequenzen per HTTP).
    
    Was hältst Du (Ihr) von dieser Idee?
    
    Viele Grüße,
    Rolf
    - +12 replies
    - murphy
      
      2011-03-20 22:28
      
      User since
      2004-07-19
      1776 Artikel
      HausmeisterIn
      
      2011-03-20T17:40:29 rosti
      [...]
      Leider kann ich aufgrund meiner Perlversion den Code nicht testen.
      
      Du kannst den Code ja in etwas funktional Äquivalentes umschreiben, was kein given und when verwendet, dann sollte es auch mit älteren Perlversionen laufen.
      
      Quote
      [...]
      In Summa bin ich am Überlegen, ob es vielleicht doch besser ist, ein eigenes kleines Modul zu schreiben, etwa Net::HTTP10 (nur HTTP/1.0) und ein eigenes Objekt erstellen dem eine Callbackfunktion mitgegeben wird, die exact 794 Bytes aus dem Socket liest
      [...]
      
      Da HTTP/1.0 in der Tat noch sehr einfach gestrickt ist, dürfte es kein allzu großer Aufwand sein, eine eigene Clientimplementation dafür zu bauen. Andererseits ist es trotz allem unnötiger Aufwand, da es solchen Code ja schon gibt.
      
      Wenn Dir mein Ansatz nicht gefällt, dann solltest Du vielleicht darüber nachdenken, nicht so eine niedrige Abstraktionsebene wie Net::HTTP zu verwenden, sondern gleich etwas wie LWP zu benutzen — damit reduziert sich das absetzen einer einfachen GET-Anfrage auf einen einzigen Befehl, wohingegen der Aufwand, HTTP/1.0 selbst zu implementieren mit Sicherheit noch größer ist, als der meinen Lösungsansatz zu verwenden und auf Perl 5.8.x zu portieren.
      When C++ is your hammer, every problem looks like your thumb.
      - +11 replies
      - rosti
        
        2011-03-21 10:00
        
        User since
        2011-03-19
        3472 Artikel
        BenutzerIn
        
        hi Murphy,
        
        vielen Dank für Dein Feedback!
        
        Meine Client-Server-Anwendung, an der ich schon länger schreibe, erfordert es, dass kein TE (chunked) stattfindet. In Net::HTTP kann ich das abstellen, indem ich HTTP/1.0 einstelle, da habe ich jedoch das Problem mit dem internen Buffer. Mit LWP::UserAgent habe ich :content_cb getestet, da findet jedoch ein TE statt und die Response ist chunked, ich habe in LWP keine Möglichkeit gefunden, das TE abzustellen (oder ich bin blind *G).
        
        Indes, mein neues Modul Net::HTTP10 ist so gut wie fertig, Synopsis:
        
        Code (perl): (dl )
        
        1 2 3 4 5 6
        
        my $s = Net::HTTP10->new($sockattr, $headers) or die "Kein Socket"; #print dump $s, "\n"; $s->request; my($code, $mess, $href) = $s->read_headers or die; printf "Status: %s Mesg: %s \nHeaders: %s\n", $code, $mess, dump $href; #$s->body_callback;
        
        printf:
        
        Code: (dl )
        
        1 2 3 4 5 6 7
        
        Status: 200 Mesg: OK Headers: { Connection => "close", "Content-Type" => "application/octet-stream", Date => "Mon, 21 Mar 2011 08:57:09 GMT", Server => "Apache/2.2.14 (Win32) PHP/5.3.0", }
        
        Die an ($s->body_callback) angebundene callback()-Funktion liest direkt aus dem Socket die Byte-Sequenzen und ist benutzerspezifisch anzupassen. Hier ist die API ziemlich offen, aber ich sehe keine andere Möglichkeit, in meinen Tests läuft es wie geschmiert ;)
        
        Edit: Es läuft sauber ;)
        
        Viele Grüße,
        Rolf
        
        modedit Editiert von pq: code--tags um dumper-ausgabe hinzugefügt
        Last edited: 2011-03-21 11:29:02 +0100 (CET)
        
        +3 replies
        
        Linuxer
        
        2011-03-21 10:53
        
        User since
        2006-01-27
        3890 Artikel
        HausmeisterIn
        
        Steh grad auf dem Schlauch. Wofür steht das "TE"?
        meine Beiträge: I.d.R. alle Angaben ohne Gewähr und auf Linux abgestimmt!
        Die Sprache heisst Perl, nicht PERL. - Bitte Crossposts als solche kenntlich machen!
        
        +2 replies
        
        rosti
        
        2011-03-21 11:28
        
        User since
        2011-03-19
        3472 Artikel
        BenutzerIn
        
        2011-03-21T09:53:10 Linuxer
        Steh grad auf dem Schlauch. Wofür steht das "TE"?
        
        Sorry, it stands for: Transfer-Encoding
        
        Das ist ein Request-Header, der dem Server mitteilt, ob die Response z.B. chunked erfolgt, oder ob gzip. Ab HTTP/1.1
        
        Edit: mein neues Modul hat nur 117 Zeilen, gerne würde ich es hier mal vorstellen zur Diskussion.
        
        --Rolf
        Last edited: 2011-03-21 11:44:58 +0100 (CET)
        
        bianca
        
        2011-03-21 11:50
        
        User since
        2009-09-13
        7016 Artikel
        BenutzerIn
        
        2011-03-21T10:28:57 rosti
        Edit: mein neues Modul hat nur 117 Zeilen, gerne würde ich es hier mal vorstellen zur Diskussion.
        
        Mach das. Setze es bitte in Code- und More-Tags.
        10 print "Hallo"
        20 goto 10
        
        +7 replies
        
        murphy
        
        2011-03-21 14:30
        
        User since
        2004-07-19
        1776 Artikel
        HausmeisterIn
        
        2011-03-21T09:00:16 rosti
        [...]
        Meine Client-Server-Anwendung, an der ich schon länger schreibe, erfordert es, dass kein TE (chunked) stattfindet.
        [...]
        
        Aus purer Neugier wüsste ich ja gerne, warum Deine Anwendung das eigentlich erfordert.
        
        Meine naive Vorstellung ist, dass es der Anwendung doch reichlich egal sein könnte, wie das Übertragungsformat aussah, solange sich die HTTP-Bibliothek korrekt um diese Protokolldetails kümmert und einen Datenblock abliefert, der weiterverarbeitet werden kann.
        
        Ansonsten kann ich nur sagen: Schön, dass Du Dein Problem mit einem eigenen Modul lösen konntest :-)
        When C++ is your hammer, every problem looks like your thumb.
        
        +6 replies
        
        rosti
        
        2011-03-21 16:31
        
        User since
        2011-03-19
        3472 Artikel
        BenutzerIn
        
        2011-03-21T13:30:21 murphy
        2011-03-21T09:00:16 rosti
        [...]
        Meine Client-Server-Anwendung, an der ich schon länger schreibe, erfordert es, dass kein TE (chunked) stattfindet.
        [...]
        
        Aus purer Neugier wüsste ich ja gerne, warum Deine Anwendung das eigentlich erfordert.
        
        Meine naive Vorstellung ist, dass es der Anwendung doch reichlich egal sein könnte, wie das Übertragungsformat aussah, solange sich die HTTP-Bibliothek korrekt um diese Protokolldetails kümmert und einen Datenblock abliefert, der weiterverarbeitet werden kann.
        
        Hi,
        
        da muss ich mal ein bischen weiter ausholen, evntl. ist das auch von allg. Interesse.
        
        In meiner Client-Server-Anwendung, die im Wesentlichen aus UserAgent und serverseitigen Script besteht, geht es um die Übertragung binärer Strukturen, kurz Binaries, vom Webserver zum UA und umgekehrt. Die Binaries können alles Mögliche sein, MP3s, proprietäre DB-Dumps, Multipart-Messages (as bin), Dateien, Binärsequenzen oder auch Text, was auch immer. Übertragen werden Rohdaten, Bytes, unabhängig von Inhalten und auch unabhängig von jedwelchen Zeichenkodierungen.
        
        Da Binärsequenzen aus einem Handle gelesen werden (Strings sind dafür ungeeignet), ist es wichtig, einmal serverseitig STDIN frei zu haben von irgendwelchen Parametern. Das serverseitige Script liest die Bin bytegenau aus STDIN und bekommt per Custom-HTTP-Header mitgeteilt, was es damit machen soll.
        
        Anererseits, in der Übertragung vom Server zum UA, wird die Binary aus einem Socket gelesen, nachdem der Request rausgegangen ist. Von daher muss die Response 'am Stück' kommen, damit bytegenau gelesen werden kann.
        
        Mit TE: chunked würde das nicht funktionieren, ebensowenig mit gzip o.a. Compess'Dings. Sofern es nur um text/html geht, ist chunking ok, der Browser setzt den Inhalt als String zusammen und gut. Ein gewöhnlicher Browser setzt aus TE: chunked auch ein image/gif wieder zusammen, aber er wird es als String behandeln, behaupte ich mal *g (was evntl. zu prüfen wäre).
        
        Wenn ich darf, stelle ich mein Net::HTTP10 heute abend mal ein und stelle mich gerne weiterer Diskussionen. Es ist schon möglich, dass es sich hierbei um eine Spezialanwendung handelt, jedoch, ich habe mir das in den Kopf gesetzt, es so zu machen.
        
        Anwendungsbeispiele: Serverseitiger Tabellendump, die Records werden über eine pack()-Schablone gejagt und alles zusammen über HTTP übertragen. Ein spezieller UA entpackt die Records, schreibt die Daten in Dateien oder in die lokale DB.
        
        Mein CMS (für meine HP) bekommt Einzelseiten auch als binär serialisierte Objekte und baut die an der entsprechenden Stelle ein.
        
        Edit: Einher geht das mit eigenen Algorithmen für Serialze, Deserialize
        
        Viele Grüße an alle,
        Rolf
        
        Noch ein Edit: Weiter oben habe ich Mist verzählt.
        Transfer-Encoding ist natürlich ein Response Header und nicht im Request.
        
        Es gibt einen Request-Header (HTTP/1.0 und 1.1)
        Accept-Encoding: gzip,deflate
        
        Worauf der Webserver möglicherweise mit dem Header
        Content-Encoding: gzip
        
        antwortet und den Content gezippt ausliefert (falls der Server das unterstützt).
        
        Last edited: 2011-03-21 18:32:32 +0100 (CET)
        
        topeg
        
        2011-03-21 21:26
        
        User since
        2006-07-10
        2611 Artikel
        BenutzerIn
        
        Man kann bei LWP::UserAgent den Header explizit setzen:
        
        Code (perl): (dl )
        
        1 2 3 4 5 6
        
        .. my $service="http://www.test.org"; my $header=HTTP::Headers->new('Accept-Encoding'=>'deflate'); my $req=HTTP::Request('GET',$service,$header); my $res=$lwp_user_agent->request($req); ...
        
        +4 replies
        
        murphy
        
        2011-03-22 16:01
        
        User since
        2004-07-19
        1776 Artikel
        HausmeisterIn
        
        Ich verstehe das Problem immer noch nicht. Ob der Server die Daten irgendwie seltsam kodiert überträgt ist doch vollkommen irrelevant, solange die Clientbibliothek diese Kodierung versteht und die Rohdaten wieder auspacken kann!
        
        Was spricht dagegen, das ganze auf der Clientseite zum Beispiel so zu machen (ungetestet):
        
        Code (perl): (dl )
        
        1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
        
        use 5.010; use strict; use warnings; use LWP; my $agent = LWP::UserAgent->new(); my $response = $agent->get('http://example.com/foo/bar'); if ($response->is_success) { for my $chunk ($response->decoded_content(charset => 'none') =~ m/.{794}/g) { # ... process $chunk of binary data ... } } else { die 'Network protocol error: ' . $response->status_line; }
        
        When C++ is your hammer, every problem looks like your thumb.
        
        +3 replies
        
        rosti
        
        2011-03-22 16:22
        
        User since
        2011-03-19
        3472 Artikel
        BenutzerIn
        
        hi,
        
        Transfer-Encoding: chunked
        
        ist das Problem. Der Webserver ermittelt die Content-Length der zu schickenden Response und teilt die dann auf in chunks (Schokoladenstückchen *g). UA-seitig kommen dann in hex die Längenangaben, wie lang ein Stückchen ist und dann das Stückchen selbst usw. und ein Trailer; damit kann der UA das wieder zusammensetzen.
        
        Zum Übertragen von Binary-Sequenzen ist das jedoch nicht brauchbar, da müssen exakt eine bestimmte Anzahl an bytes gelesen werden, was am besten gleich aus dem Socket-Handle gemacht wird. LWP ist ok, Hut ab vor der Arbeit, die da drinsteckt. Aber hier bei mir gehts nicht um Texte sondern um Bytes, womit ich möglicherweise im Abseits stehe, aber ich bin stur ;)
        
        Z.Z. habe ich zwei Anwendungen für meine Website: Download der Log-Tabelle und Download der Mailbox, beide Tabellen werden aus MySQL gelesen und als Binary zu einem eigens geschriebenen UA übertragen. Die Logtabelle kommt in die lokale DB und aus der Mailbox werden RFC-gerechte Mail-Dateien erzeugt (d.h., die liegen schon RFC-gerecht in MySQL).
        
        Eine andere Anwendung ist das "Rippen" eines MP3-Streams (Internet-Radio mitschneiden)...
        
        Ergo: Fallback zu HTTP/1.0, kein TE anfordern und beim Empfang vor Allem nicht puffern, dann gehts.
        
        --Rolf
        
        +2 replies
        
        murphy
        
        2011-03-22 18:28
        
        User since
        2004-07-19
        1776 Artikel
        HausmeisterIn
        
        2011-03-22T15:22:09 rosti
        [...]
        Transfer-Encoding: chunked
        
        ist das Problem.
        [...]
        Zum Übertragen von Binary-Sequenzen ist das jedoch nicht brauchbar, da müssen exakt eine bestimmte Anzahl an bytes gelesen werden, was am besten gleich aus dem Socket-Handle gemacht wird.
        [...]
        
        Ich sehe immer noch kein Problem: Auch Binärdaten können in Blöcken übertragen und hinterher wieder zusammengesetzt werden. LWP nimmt Dir diese Arbeit ab und liefert Dir einen dekodierten Datenblock, in dem all die Protokolldetails wie Blockkodierung oder Kompression bereits wieder rückgängig gemacht wurden.
        
        Das ist auch der Grund, warum ich in meinem letzten Beispiel
        
        Code (perl): (dl )
        
        $response->decoded_content(charset => 'none')
        
        aufrufe: decoded_content um die Transportkodierungen aufzulösen und charset => 'none' um keine Textdekodierung durchzuführen sondern einen Binärstring zu bekommen.
        When C++ is your hammer, every problem looks like your thumb.
        
        rosti
        
        2011-03-22 18:45
        
        User since
        2011-03-19
        3472 Artikel
        BenutzerIn
        
        2011-03-22T17:28:30 murphy
        
        Das ist auch der Grund, warum ich in meinem letzten Beispiel
        
        Code (perl): (dl )
        
        $response->decoded_content(charset => 'none')
        
        aufrufe: decoded_content um die Transportkodierungen aufzulösen und charset => 'none' um keine Textdekodierung durchzuführen sondern einen Binärstring zu bekommen.
        
        Ja, so langsam verstehe ich... btw., decoded_content() wird mit meiner etwas ältlichen libwww nicht unterstützt, da brauche ich ein Update.
        
        Es ist überhaupt rührend, wie Ihr Euch um mich bemüht, ein herzliches Dankeschön sei an dieser Stelle mal gesagt!!!
        
        Es ist wirklich besser, an dieser Stelle ausgereifte Libs zu verwenden und das HTTProtocol scheint nur auf den ersten Blick einfach, was es tatsächlich gar nicht ist.
        
        --Rolf

View all threads created 2011-03-19 23:01.