[HaBo]

Extinction · 20.11.10, 18:33

Hallo!
Ich habe mir ein kleines Downloadprogramm unter Windows geschrieben. Es läd soweit so gut auch die Dateien runter, aber nicht korrekt. Etwa jede 100'te Adresse (laut XVI32) ist eine Hexadezimalzahl zu viel in meiner Datei. Datendateien werden dadurch natürlich unbrauchbar. :/
Mein GET-String sieht so aus:

Code:

GET //sprache/trennen/bilder/test.gif HTTP/1.0

From: Testclient@test.de

User-Agent: Testtool/1.0

Host: www.prepolino.ch

Die Downloadschleife sieht wie folgt aus:

Code:

double c; bool ok=false;
        ofstream out;
        out.open(target.c_str());
        while ((bytesReceived = (sockdl.recv(Buffer, RCVBUFSIZE))) != 0)
        {
            for (int i=0; i<bytesReceived; i++)
            {
                if (ok) out << Buffer[i];
                if (i>3 && Buffer[i-3]=='\015' && Buffer[i-2]=='\012'
                        && Buffer[i-1]=='\015' && Buffer[i]     =='\012') ok=true;
                c++;
            }
        }
        out.close();
        if (verbose_level>=3)cout << "Downloaded " << (c/1024)/1024 << "MB successfully!\n";

Irgendwo dort muss der Wurm liegen. Denn selbst wenn ich den Buffer auf >1MB einstelle, die while Schleife also nur einmal durchläuft, bekomme ich zu viele Daten.:/

Edit: Habe die fiktiven Daten im GET Request durch die Passenden zum meinem nächsten Post ersetzt.

**CDW** · 20.11.10, 20:26

RECV kann nicht nur 0 zurückgeben, sondern auch -1 (im Fehlerfall)

Edit: könntest Du vielleicht ein Beispiel posten (Originaldatei und eine "falsch" übertragene) ?

Anzeige

- Anzeige -

GrafZahl · 20.11.10, 21:14

wäre es http 1.1 würde ich mal auf chunked transfer-coding orakeln, aber bei 1.0? ...

kannst du mal bitte den antwort header posten?

Extinction · 21.11.10, 11:52

@CDW
Ähm, ja, das ist bislang noch nicht berücksichtigt. ^^
Aber ich glaube eher nicht, dass es daran liegt, weil ich den Receive Buffer einfach so groß gewählt habe, dass bei einem Mal alle Daten ankommen. Die überzähligen Bytes sind aber mittend im Buffer.
Beispiel ist im Anhang als *.zip. Habo konvertiert scheinbar automatisch nach *.jpg, waren aber *.gif's. Habe jetzt außerdem ein paar andere Server probiert, das mit 100'te Adresse kommt nicht mehr ganz hin, siehe Anhang.

@GrafZahl
Hmmm... Hast vieleicht Recht. Wieso schickt der Server mir denn HTTP 1.1 zurück, wenn ich 1.0 requeste?

Hier der Header:

Code:

HTTP/1.1 200 OK

Date: Sun, 21 Nov 2010 10:19:16 GMT

Server: Apache/2.2.3 (Debian) mod_ssl/2.2.3 OpenSSL/0.9.8c

Last-Modified: Wed, 31 Dec 2003 16:08:43 GMT

ETag: "585196-5810-f3edf8c0"

Accept-Ranges: bytes

Content-Length: 22544

Connection: close

Content-Type: image/gif

Werd mich dann mal bzgl. chunked transfer-coding schlau machen.
Edit: Es fehlt aber das "Transfer-Encoding: chunked" im Header. Also ist es scheinbar nicht chunked. :/

GrafZahl · 21.11.10, 12:30

*g* hätte mir eigentlich schon beim lesen des quelltextes auffallen müssen ...

ofstream behandelt dateien per default als textdateien ...
probier mal folgendes:

Code:

out.open(target.c_str());

wird zu

Code:

out.open(target.c_str(), ios_base::out | ios_base::binary);

**CDW** · 21.11.10, 12:57

Jep. GrafZahl hat recht.
Die Testdaten haben "interessante" Unterschiede - alle 0xA des Originals sind durch 0xD, 0xA ersetzt worden (also "\n" durch "\r \n" )
Original:

Code:

00000040: 8de7 face f7fe 0f0c 0a87 c4a2 f188 4c2a

nach der Übertragung:

Code:

00000040: 8de7 face f7fe 0f0c 0d0a 87c4 a2f1 884c

Und das ist bei binären Daten nun mal fatal

Ersetze ich die "0d 0a" durch "0a", erhalte ich wieder ein "anzeigbares" GIF Bild

Extinction · 21.11.10, 13:12

Ouch, das hätte ich wissen müssen. >.<
Afaik passiert das unter Linux aber nicht.

Jedenfalls funktioniert es jetzt, danke.

Anzeige

- Anzeige -

20.11.10, 18:33	#1 (permalink)
Extinction Registriert seit: 02.01.07 Likes: 0	[c++] Dateidownload liefert zu große Dateien! Anzeige Hallo! Ich habe mir ein kleines Downloadprogramm unter Windows geschrieben. Es läd soweit so gut auch die Dateien runter, aber nicht korrekt. Etwa jede 100'te Adresse (laut XVI32) ist eine Hexadezimalzahl zu viel in meiner Datei. Datendateien werden dadurch natürlich unbrauchbar. :/ Mein GET-String sieht so aus: Code: GET //sprache/trennen/bilder/test.gif HTTP/1.0 From: Testclient@test.de User-Agent: Testtool/1.0 Host: www.prepolino.ch Die Downloadschleife sieht wie folgt aus: Code: double c; bool ok=false; ofstream out; out.open(target.c_str()); while ((bytesReceived = (sockdl.recv(Buffer, RCVBUFSIZE))) != 0) { for (int i=0; i<bytesReceived; i++) { if (ok) out << Buffer[i]; if (i>3 && Buffer[i-3]=='\015' && Buffer[i-2]=='\012' && Buffer[i-1]=='\015' && Buffer[i] =='\012') ok=true; c++; } } out.close(); if (verbose_level>=3)cout << "Downloaded " << (c/1024)/1024 << "MB successfully!\n"; Irgendwo dort muss der Wurm liegen. Denn selbst wenn ich den Buffer auf >1MB einstelle, die while Schleife also nur einmal durchläuft, bekomme ich zu viele Daten.:/ Edit: Habe die fiktiven Daten im GET Request durch die Passenden zum meinem nächsten Post ersetzt. Geändert von Extinction (21.11.10 um 12:07 Uhr)

20.11.10, 20:26	#2 (permalink)
CDW Moderator Registriert seit: 20.07.05 Likes: 202	RECV kann nicht nur 0 zurückgeben, sondern auch -1 (im Fehlerfall) Edit: könntest Du vielleicht ein Beispiel posten (Originaldatei und eine "falsch" übertragene) ? __________________ Noch mal, für alle Pseudo-Geeks: 1+1=0. -> 10 wäre Überlauf! Selig, wer nichts zu sagen hat und trotzdem schweigt.

20.11.10, 21:14	#3 (permalink)
GrafZahl Member of Honour Registriert seit: 28.05.10 Likes: 210	wäre es http 1.1 würde ich mal auf chunked transfer-coding orakeln, aber bei 1.0? ... kannst du mal bitte den antwort header posten? __________________ Code: :(){ :\|:& };: Veritas Aequitas

21.11.10, 12:30	#5 (permalink)
GrafZahl Member of Honour Registriert seit: 28.05.10 Likes: 210	g hätte mir eigentlich schon beim lesen des quelltextes auffallen müssen ... ofstream behandelt dateien per default als textdateien ... probier mal folgendes: Code: out.open(target.c_str()); wird zu Code: out.open(target.c_str(), ios_base::out \| ios_base::binary); __________________ Code: :(){ :\|:& };: Veritas Aequitas

21.11.10, 12:57	#6 (permalink)
CDW Moderator Registriert seit: 20.07.05 Likes: 202	Jep. GrafZahl hat recht. Die Testdaten haben "interessante" Unterschiede - alle 0xA des Originals sind durch 0xD, 0xA ersetzt worden (also "\n" durch "\r \n" ) Original: Code: 00000040: 8de7 face f7fe 0f0c 0a87 c4a2 f188 4c2a nach der Übertragung: Code: 00000040: 8de7 face f7fe 0f0c 0d0a 87c4 a2f1 884c Und das ist bei binären Daten nun mal fatal Ersetze ich die "0d 0a" durch "0a", erhalte ich wieder ein "anzeigbares" GIF Bild __________________ Noch mal, für alle Pseudo-Geeks: 1+1=0. -> 10 wäre Überlauf! Selig, wer nichts zu sagen hat und trotzdem schweigt.

21.11.10, 13:12	#7 (permalink)
Extinction Themenstarter Registriert seit: 02.01.07 Likes: 0	Ouch, das hätte ich wissen müssen. >.< Afaik passiert das unter Linux aber nicht. Jedenfalls funktioniert es jetzt, danke.

Themen-Optionen
Druckbare Version zeigen Jemanden per E-Mail auf dieses Thema hinweisen
Ansicht
Linear-Darstellung Zur Hybrid-Darstellung wechseln Zur Baum-Darstellung wechseln

[HaBo]

[c++] Dateidownload liefert zu große Dateien!