c++.de :: Binärdaten über Sockets empfangen?

BlackCubeX Mitglied 16:43:18 23.02.2012 Titel:

Hey,
wie der Titel schon sagt arbeite ich an einem einfachen HTTP 1.0 Client, habe aber Probleme mit Binärdaten. Textdateien lassen sich einfach über

C++:
do { count = recv( sock, buffer, sizeof(buffer), 0); strcat(content, buffer); } while (count > 0);

empfangen.
Wenn ich aber nun z.B. ein PNG anfordere und in eine Datei schreibe, ist diese nicht lesbar.
Kann mir pls jmd helfen?

rüdiger Moderator 17:02:23 23.02.2012 Titel:

Autsch. Dein Code zeigt einfach, dass du Stringhandling in C nicht verstanden hast. In C sind Strings mit 0-terminiert. strcat etc. arbeitet mit Strings. Aber recv liefert keine 0-terminierten Strings! Du bekommst einfach die Daten wie sie empfangen wurden und über den Rückgabewert die Anzahl der Bytes.

Du kannst hier kein strcat nehmen! Aber es ist noch schlimmer. strcat führt keinerlei Überprüfung von Buffergrößen durch. Es wäre also ein leichtes den content Buffer überlaufen zu lassen.

Und strcat ist auch der Grund, warum es mit Binärdaten nicht klappt. Binärdaten können nämlich 0en enthalten.

Ich hoffe, dass das kein Produktivcode werden soll. Nimm dann lieber etwas fertiges (zB libcurl).

BlackCubeX Mitglied 17:30:58 23.02.2012 Titel:

Danke für die Erklärung, das hat mich schon deutlich weiter gebracht.
Nein, das sollte keine Produktivsoftware werden, da würd ich mich ja zum Obst der Woche machn

libcurl hatt ich mich schonmal mit beschäftigt, gefällt mir aber iwie nich so. Was hältst du von libwww?

cooky451 Mitglied 18:52:13 23.02.2012 Titel:

Solange du C nicht verstanden hast hilft dir auch keine lib. Versuche einfach mal das vernünftig zu machen, wenn du C dann kannst, kannst du immer noch libcurl nutzen auf C++ umsteigen.

EOP Mitglied 22:18:36 23.02.2012 Titel:

Statt strcat memcpy benutzen.
Ist aber nix für 'nen Anfänger. Sonst kracht's recht schnell.

BlackCubeX Mitglied 00:44:48 24.02.2012 Titel:

Kannst du bitte erläutern, wie du das mit memcpy machen würdest?

EOP Mitglied 01:07:34 24.02.2012 Titel:

C++:
char *m_data; int m_data_size, m_buf_size;

C++:
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 26 27	bool CCharBuffer::AppendData( char p, int amount ) { if( !p \|\| amount < 0 ) return( false ); size_t uamount = static_cast<size_t> ( amount ); if( m_data_size+amount < m_buf_size ) { memcpy(m_data+m_data_size, p, uamount); m_data[m_data_size+amount] = 0; } else { char tmp = new char[m_data_size+amount+1]; if( !tmp ) { return( false ); } memcpy(tmp, m_data, m_data_size); delete [] m_data; memcpy(tmp+m_data_size, p, uamount); tmp[m_data_size+amount] = 0; m_data = tmp; m_buf_size = m_data_size+amount+1; } m_data_size += amount; return( true ); } // bool CCharBuffer::AppendData( char *p, int amount )

TyRoXx Mitglied 18:08:49 24.02.2012 Titel:

EOP schrieb:

C++:
char *m_data; int m_data_size, m_buf_size;

C++:
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 26 27	bool CCharBuffer::AppendData( char p, int amount ) { if( !p \|\| amount < 0 ) return( false ); size_t uamount = static_cast<size_t> ( amount ); if( m_data_size+amount < m_buf_size ) { memcpy(m_data+m_data_size, p, uamount); m_data[m_data_size+amount] = 0; } else { char tmp = new char[m_data_size+amount+1]; if( !tmp ) { return( false ); } memcpy(tmp, m_data, m_data_size); delete [] m_data; memcpy(tmp+m_data_size, p, uamount); tmp[m_data_size+amount] = 0; m_data = tmp; m_buf_size = m_data_size+amount+1; } m_data_size += amount; return( true ); } // bool CCharBuffer::AppendData( char *p, int amount )

Wo hast du diese Scheiße denn ausgegraben?

EOP Mitglied 21:35:56 24.02.2012 Titel:

TyRoXx schrieb:

EOP schrieb:

C++:
char *m_data; ...

Wo hast du diese Scheiße denn ausgegraben?

Was hast du da dran auszusetzen?

Komm mir jetzt bloß nicht mit vector<char>. Das ist was für Mädchen.
Es ging darum wie man memcpy benutzt und um dem OP zu zeigen, daß man sich Größen und Positionen merken muss.

TyRoXx Mitglied 22:38:46 24.02.2012 Titel:

EOP schrieb:

TyRoXx schrieb:

EOP schrieb:

C++:
char *m_data; ...

Wo hast du diese Scheiße denn ausgegraben?

Was hast du da dran auszusetzen?

Komm mir jetzt bloß nicht mit vector<char>. Das ist was für Mädchen.
Es ging darum wie man memcpy benutzt und um dem OP zu zeigen, daß man sich Größen und Positionen merken muss.

Ich glaube hier geht es um C, also kommt vector nicht direkt in Frage. Das heißt aber nicht, dass man unterirdisches C mit Klassen propagieren muss.

C++:
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 26 27 28 29 30	bool //schon mal was von Ausnahmen gehört? CCharBuffer //eine hässliche Unart ::AppendData( char p, //const fehlt, p ist kein vernünftiger Name int amount ) //warum denn int? { if( !p \|\| amount < 0 ) //assert(..), und warum nicht einfach size_t? return( false ); //überflüssige und falsch gesetzte Klammern size_t uamount = static_cast<size_t> ( amount ); //jetzt auf einmal doch size_t if( m_data_size+amount < m_buf_size ) //das könnte man einfacher haben mit vector<char> { memcpy(m_data+m_data_size, p, uamount); m_data[m_data_size+amount] = 0; //wieso das denn? Müsste die Klasse dann nicht CString heißen? } else { char tmp = new char[m_data_size+amount+1]; //aua if( !tmp ) //new gibt nicht 0 zurück { return( false ); } memcpy(tmp, m_data, m_data_size); delete [] m_data; memcpy(tmp+m_data_size, p, uamount); tmp[m_data_size+amount] = 0; m_data = tmp; m_buf_size = m_data_size+amount+1; //die drei Summanden hatten wir eben schon bei new[] } m_data_size += amount; return( true ); } // bool CCharBuffer::AppendData( char *p, int amount )

EOP Mitglied 23:01:59 24.02.2012 Titel:

Zitat:

int amount ) //warum denn int?

Weil recv einen int liefert.

Zitat:

char *tmp = new char[m_data_size+amount+1]; //aua

Was ist hier denn schon wieder aua?

Zitat:

if( !tmp ) //new gibt nicht 0 zurück

Die Kritik daran hab ich erwartet und akzeptiere ich.

Ansonsten schreibe ich seit über 20 Jahren Programme, die auch ohne exceptions fehlerfrei funktionieren.

Problem war: ich musste in einem download beliebiger Größe nach mehreren Schlüsselwörtern suchen:
- Download nach Schlüsselwort durchsuchen
- wenn Schlüsselwort nicht gefunden, download - (Länge des längsten Schlüsselworts - 1) speichern und weiter

Und wie würde ich einen vector<char> nach Schlüsselwörtern durchsuchen?

TyRoXx Mitglied 23:20:02 24.02.2012 Titel:

EOP schrieb:

Zitat:

int amount ) //warum denn int?

Weil recv einen int liefert.

Was hat recv denn mit CCharBuffer zu tun? Genau, gar nichts!

EOP schrieb:

Zitat:

char *tmp = new char[m_data_size+amount+1]; //aua

Was ist hier denn schon wieder aua?

Dein Steinzeit-Compiler kennt anscheinend vector nicht oder du bist noch verkalkter als jener.

EOP schrieb:

Zitat:

if( !tmp ) //new gibt nicht 0 zurück

Die Kritik daran hab ich erwartet und akzeptiere ich.

.. wenn nackte Tatsachen nichts mehr ausrichten können.

EOP schrieb:

Ansonsten schreibe ich seit über 20 Jahren Programme, die auch ohne exceptions fehlerfrei funktionieren.

Das ist jetzt nicht dein Ernst, oder?

EOP schrieb:

Und wie würde ich einen vector<char> nach Schlüsselwörtern durchsuchen?

Das ist nicht mehr komisch, du kannst aufhören.

EOP Mitglied 23:36:57 24.02.2012 Titel:

Was bist du denn für ein Depp? Nur Gemecker aber nix Konstruktives von dir. Absolut nix.

Zitat:

Und wie würde ich einen vector<char> nach Schlüsselwörtern durchsuchen?

Antworte bitte.

rüdiger Moderator 23:37:21 24.02.2012 Titel:

In C gibt es weder vector<char> noch new char[...]. Also wenn du Fragen zu vector<char> hast, dann stell sie bitte im C++-Forum. Die ganze Diskussion ist sicher wenig hilfreich für den Op.

EOP Mitglied 23:39:26 24.02.2012 Titel:

rüdiger schrieb:

In C gibt es weder vector<char> noch new char[...]. Also wenn du Fragen zu vector<char> hast, dann stell sie bitte im C++-Forum. Die ganze Diskussion ist sicher wenig hilfreich für den Op.

Dann nimm eben malloc und free.

rüdiger Moderator 01:10:26 25.02.2012 Titel:

EOP schrieb:

rüdiger schrieb:

In C gibt es weder vector<char> noch new char[...]. Also wenn du Fragen zu vector<char> hast, dann stell sie bitte im C++-Forum. Die ganze Diskussion ist sicher wenig hilfreich für den Op.

Dann nimm eben malloc und free.

realloc. Aber selbst dann hat dein Code noch die angesprochenen Probleme und vorallem auch eine schlechte Allokierungsstrategie. Sobald du einmal die Kapazität erreicht hast, hast du dann ein realloc pro recv!

EOP Mitglied 02:20:20 25.02.2012 Titel:

rüdiger schrieb:

EOP schrieb:

rüdiger schrieb:

In C gibt es weder vector<char> noch new char[...]. Also wenn du Fragen zu vector<char> hast, dann stell sie bitte im C++-Forum. Die ganze Diskussion ist sicher wenig hilfreich für den Op.

Dann nimm eben malloc und free.

realloc. Aber selbst dann hat dein Code noch die angesprochenen Probleme und vorallem auch eine schlechte Allokierungsstrategie. Sobald du einmal die Kapazität erreicht hast, hast du dann ein realloc pro recv!

Das war ja nur ein Teil einer Klasse um irgendeine binäre Geschichte zu lösen.

Sobald keins der Schlüsselwörter gefunden wurde, wird der Puffer (minus Länge des längsten Schlüsselworts - 1) geschrieben, Rest an den Anfang verschoben und wiederverwendet.
Nix mit ständigem realloc.

Außerdem lese ich nie mehr als der Puffer groß ist. Da gibt's höchstens am Anfang mal ein "realloc".
Würde ich den Puffer von Anfang an mit (Größe x + Länge des längsten Schlüsselworts) allozieren und nur immer Größe x lesen, gäb's eigentlich nie ein realloc.

cooky451 Mitglied 19:52:27 25.02.2012 Titel:

EOP schrieb:

Und wie würde ich einen vector<char> nach Schlüsselwörtern durchsuchen?

Ist das deine Vorstellung von seit 20 Jahren programmieren? :eek:

Egal wie du vorher nach Schlüsselwörtern gesucht hast, mit dem vector wird es letztlich genau so funktionieren.

@TE
Eine einfache Möglichkeit ist, den empfangenen Puffer immer gleich in eine Datei zu schreiben. Dann musst du dich um das malloc/realloc Gefrickel nicht kümmern.

Wutz Mitglied 21:17:37 25.02.2012 Titel:

BlackCubeX schrieb:

Hey,
wie der Titel schon sagt arbeite ich an einem einfachen HTTP 1.0 Client, habe aber Probleme mit Binärdaten. Textdateien lassen sich einfach über

C++:
do { count = recv( sock, buffer, sizeof(buffer), 0); strcat(content, buffer); } while (count > 0);

empfangen.
Wenn ich aber nun z.B. ein PNG anfordere und in eine Datei schreibe, ist diese nicht lesbar.

Wie du schon richtig erkannt hast, kann das für Binärdateien nicht funktionieren, da strcat verwendet wird, was nur Strings richtig verarbeitet.

C++:
1 2 3 4 5 6 7 8	unsigned char buffer[1024],*b=0; size_t p=0; while( (count = recv( sock, buffer, 1024, 0))>0 ) { b=realloc(b,p+count); memcpy(b+p,buffer,count); p+=count; }

EOP Mitglied 22:01:55 25.02.2012 Titel:

cooky451 schrieb:

EOP schrieb:

Und wie würde ich einen vector<char> nach Schlüsselwörtern durchsuchen?

Ist das deine Vorstellung von seit 20 Jahren programmieren? :eek:

Das ist nicht meine Vorstellung sondern die Realität.

Außerdem liebe ich memcpy, memmove, etc. :leak:

BlackCubeX Mitglied 16:49:08 26.02.2012 Titel:

Danke für eure ganzen Antworten, ich finds lustig, wie hier auf die kleinste Frage immer gleich eine riesen Diskussion ausbricht ^^
Sowas wie von Wutz hätte ich eigentlich erwartet, aber das von E0P sirht auch interressant aus und wird bestimmt noc Verwendung finden

Ich hab die Sache inzwischen übrigens einfach mit

C++:
outfile.write(buffer, count);

gelöst

LG
BCX

cooky451 Mitglied 17:00:39 26.02.2012 Titel:

BlackCubeX schrieb:

Danke für eure ganzen Antworten, ich finds lustig, wie hier auf die kleinste Frage immer gleich eine riesen Diskussion ausbricht ^^

Das ist der Sinn eines Forums.

BlackCubeX schrieb:

aber das von E0P sirht auch interressant aus und wird bestimmt noc Verwendung finden

Lieber nicht.

BlackCubeX schrieb:

Ich hab die Sache inzwischen übrigens einfach mit

C++:
outfile.write(buffer, count);

gelöst

Also meine Variante. :cool:

rüdiger Moderator 17:50:07 26.02.2012 Titel:

Wutz schrieb:

C++:
1 2 3 4 5 6 7 8	unsigned char buffer[1024],*b=0; size_t p=0; while( (count = recv( sock, buffer, 1024, 0))>0 ) { b=realloc(b,p+count); memcpy(b+p,buffer,count); p+=count; }

Du verwendest realloc falsch http://www.c-plusplus.de/forum/206606
Außerdem ist ein realloc pro recv keine gute Allokierungsstrategie.

Wutz Mitglied 18:53:16 26.02.2012 Titel:

Ich verwende realloc richtig.
Und deine "Strategie" der Vermeidung von vielen realloc ist subjektiv, scheitert ein realloc mit diesen minimalen Raten irgendwann mal, hast du mit deinem Programm eh ganz andere Probleme.
Deswegen kann man auch statt *b=0 *b=malloc(100000000) verwenden, was aber mit der Frage nichts zu tun hat.

rüdiger Moderator 20:01:08 26.02.2012 Titel:

Wutz schrieb:

Ich verwende realloc richtig.

Nein, siehe Link (3.2). realloc kann NULL zurück liefern und das ist nicht mal so unwahrscheinlich, wenn man größere Daten über http laden will. Dann hast du n Speicherlack, versuchst auf NULL zu kopieren, etc.

Wutz Mitglied 20:19:22 26.02.2012 Titel:

Kannst du lesen? Nein kannst du nicht, zumindest nicht bis zum Ende meines Beitrages.

EOP Mitglied 21:52:30 26.02.2012 Titel:

cooky451 schrieb:

BlackCubeX schrieb:

aber das von E0P sirht auch interressant aus und wird bestimmt noc Verwendung finden

Lieber nicht.

Na was denn? Das ist ordentlich programmiert bis auf den Test, ob tmp NULL ist.

cooky451 Mitglied 22:35:56 26.02.2012 Titel:

EOP schrieb:

Na was denn? Das ist ordentlich programmiert bis auf den Test, ob tmp NULL ist.

Ja.. bis auf:

- Es ist C++ und kein C, und wenn man C++ hat sollte man lieber gleich std::vector<char> nutzen.

Aber nehmen wir mal an es wäre C und du hättest malloc/free statt new/delete genutzt:

- Alles was du empfängst muss mit so einem Puffer sinnloserweise ein Mal mehr kopiert werden.
- p sollte const char* sein. (Oder gleich const void*)
- amount sollte gleich size_t sein.
- Du machst sinnloserweise eine Nullterminierung im Puffer selbst.
- Du könntest gleich auf m_data_size+amount >(=) m_buf_size testen, entsprechend Speicher reservieren und den alten Kram kopieren, dann würdest du einiges an Coderedundanz sparen und das Ganze wäre viel übersichtlicher.
- Du solltest realloc nutzen. ( :o)

)

EOP Mitglied 23:27:17 26.02.2012 Titel:

Das mit const ist ok.

Der Hintergrund wieso ich die ganze Klasse überhaupt geschrieben hatte ist der, daß ich auch "transfer-encoding: chunked" mit binären Daten runterladen und nach Schlüsselworten durchsuchen musste.

Und welchen Vorteil hätte ich wenn ich malloc statt new benutzen würde? Erschließt sich mir nicht so ohne weiteres.

Nullterminierung ist deshalb weil ich je nach übertragenem mime-Typ dann mit strstr suche. (Jetzt nicht auch noch an strstr rummeckern!)

rüdiger Moderator 23:28:58 26.02.2012 Titel:

Wutz schrieb:

Kannst du lesen? Nein kannst du nicht, zumindest nicht bis zum Ende meines Beitrages.

Wer muss denn gleich persönlich werden. Es ist eben nicht unrealistisch das realloc fehlschlägt. Es geht um eine HTTP-Implementierung und da ziehen Leute gerne mal ein DVD-Image oder andere große Dateien die möglicherweise nicht in den Speicher passen. Wenn du gerne Code schreibst, der dir in Fehlersituationen um die Ohren fliegt, dann bitte tu das. Aber das solltest du nicht anderen Leuten empfehlen.

cooky451 Mitglied 00:02:14 27.02.2012 Titel:

EOP schrieb:

Das mit const ist ok.

Was heißt "ok"? Nein, es ist nicht ok. Oder alles ist ok. Jedenfalls hat das const in der Meckerhierarchie keine Sonderstellung.

EOP schrieb:

Der Hintergrund wieso ich die ganze Klasse überhaupt geschrieben hatte ist der, daß ich auch "transfer-encoding: chunked" mit binären Daten runterladen und nach Schlüsselworten durchsuchen musste.

Dafür sieht die Klasse aber nicht gemacht aus.

EOP schrieb:

Und welchen Vorteil hätte ich wenn ich malloc statt new benutzen würde? Erschließt sich mir nicht so ohne weiteres.

Keinen, aber es wäre eben C.

EOP schrieb:

Nullterminierung ist deshalb weil ich je nach übertragenem mime-Typ dann mit strstr suche. (Jetzt nicht auch noch an strstr rummeckern!)

Dann baut man das aber nicht in den Puffer, sondern regelt das von einer anderen Stelle aus. Eine Pufferklasse ist dafür einfach nicht zuständig. (Es sei denn, sie soll einen String darstellen.)

Und strstr ist natürlich auch suboptimal. :o)

EOP Mitglied 00:20:10 27.02.2012 Titel:

cooky451 schrieb:

Und strstr ist natürlich auch suboptimal. :o)

Wusst ich's doch.

Ist ja auch nur AppendData, hat bis dahin nix mit "transfer-encoding: chunked"-auflösen zu tun.

Und eigentlich ging's ja nur darum, dem OP zu zeigen wie man memcpy benutzt.

Wenn C++ C-Funktionen unterstützt und die imho schneller sind, dann benutz ich die eben. Mal ganz abgesehen davon, daß ich mit C angefangen hab und C immer noch cool finde.