Sockets und das HTTP-Protokoll

EOP schrieb:

Entsprechende lib einbinden!
wsock32.lib oder ws2_32.lib - hab vergessen wie die heisst.

Letztere.

Artchi schrieb:

Die Kompressionsrate des JPEGs ist nur zu hoch. Man kann deshalb fast nichts erkennen. Ansonst hat das Bild irgendwie einen gewissen Charme.

Für eine derartige Grafik ist JPEG völlig ungeeignet. Am besten PNG.

Hab nochmal nachgeschaut, es ist schon, wie es sich gehört, ein PNG.

Weiß jemand warum bei mir die recv Funktion nicht ganz geht? Also besser gesagt will ich das das er die While schleife verlässt wenn ein bestimmtes Zeichen im String vorliegt... das letzte Zeichen beim empfangen endet mit "]", dennoch läuft die schleife weiter auch wenn ich (c == ']') in den Funktion schreibe. Die Text Datei wird ohne Zeichen einfach weiter gefüllt da recv nicht gestoppt wird. Weiß jemand woran das liegt oder wie ich am besten aus der while schleife raus komme wenn das letzte zeichen ein "]" ist, so das mein Programm nach empfangen aller Daten weiter laufen kann?

Fake oder Echt

empfängst und sendest du die daten zeichenweise oder als string ?
und normalerweise läuft recv nicht einfach weiter, es sei denn du sendest halt immer wieder was neu oder du hast iwo ein speicher problem, alles in allem wär der entsprechende code ganz interessant

DaRe

PlanloserCoder schrieb:

Weiß jemand warum bei mir die recv Funktion nicht ganz geht?

Also ich hoffe doch mal sehr, dass recv geht. Immerhin ist das keine Funktion die man so am Rande nutzt.

PlanloserCoder schrieb:

Also besser gesagt will ich das das er die While schleife verlässt wenn ein bestimmtes Zeichen im String vorliegt... das letzte Zeichen beim empfangen endet mit "]", dennoch läuft die schleife weiter auch wenn ich (c == ']') in den Funktion schreibe. Die Text Datei wird ohne Zeichen einfach weiter gefüllt da recv nicht gestoppt wird. Weiß jemand woran das liegt oder wie ich am besten aus der while schleife raus komme wenn das letzte zeichen ein "]" ist, so das mein Programm nach empfangen aller Daten weiter laufen kann?

-> Ist der TCP Socket blockierend(bin mir selbst nicht sicher, aber wenn der non-blocking ist, müsste recv einfach durchlaufen und einen Fehler returnen geben, wenn keine Daten anliegen)? Ich geh mal von TCP aus, wenn du dich bei HTTP meldest.

-> Was ist denn die genaue Rückgabe von recv?

-> Unter Linux kannst du recv ebenfalls nicht blockierend einstellen. Ist das MSG_DONTWAIT Flag in recv gesetzt?

Am besten du lässt mal ein bisschen Code sehen, dann kann ich mir auch ein besseres Bild machen.

Skylax

Der Artikel ist zwar jetzt schon ziemlich alt und ich weiß nicht ob das noch jemanden interessiert, aber die letzte Version des Programms (07.cpp, Link im Schlusswort) hat einen Bug im "Chunked download" Teil. Hier wird zunächst die Chunksize mit der GetLine Funktion ausgelesen (welche in den globalBuffer schreibt), um dann mit Recv den html text zu empfangen. Wenn das Ende des Chunks erreicht ist wird mit zweimaligem Aufruf von recv noch das verbleibende CRLF (\r\n) entsorgt (sowie im Artikel beschrieben). Die gemischte Verwendung der lowlevel 'recv' Funktion und high level 'Recv' Funktion ist hier aber problematisch. Ist der Chunk nämlich kleiner als die in GetLine verwendete Puffergröße, so ist das verbleibenden CRLF schon im globalBuffer, die recv löscht dann Zeichen die erst später kommen, während \r\n im globalBuffer verbleibt. Beim nächsten GetLine Aufruf wird dann \r in den sstream geschrieben und die falsche Chunksize ausgelesen, so dass das Programm fälschlicherweise abbricht. Entweder man ersetzt die for-schleife durch Recv(socker, &temp, 2,0) oder man macht es wie folgt:

cout << "Downloading... (Chunked)" << endl;
while(true)
{
    stringstream sstream;
    GetLine(Socket, sstream);
    //weiter Zeile auslesen, falls ein \r\n vorliegt:
    if(sstream.str() == "\r")   
    {
       GetLine(Socket, sstream);
    }
    int chunkSize = -1;
    sstream >> hex >> chunkSize; // Größe des nächsten Parts einlesen
    if(chunkSize <= 0)
    {
       break;
    }
    cout << "Downloading Part (" << chunkSize << " Bytes)... " << endl;
    recvSize = 0; // Vor jeder Schleife wieder auf 0 setzen
    while(recvSize < chunkSize)
    {
          int bytesToRecv = chunkSize - recvSize;
          if((bytesRecv = Recv(Socket, buf, bytesToRecv > sizeof(buf)?sizeof(buf) : bytesToRecv, 0)) <= 0)
          {
              throw CreateSocketError();
          }
          recvSize += bytesRecv;
          fout.write(buf, bytesRecv);
          cout << "\r" << recvSize * 100 / chunkSize << "%" << flush;
     }
     cout << endl;     
}

wobei ich die for-schleife weggelassen und durch einen bedingten GetLine Aufruf ersetzt habe.

huhu,
erstmal vielen Dank für das gute Tutorial hat mir stark weitergeholfen!
Kann es allerdings sein das sich etwas geändert hat?

an dieser Stelle:

std::runtime_error CreateSocketError()
{
    std::ostringstream temp;
#ifdef linux
    temp << "Socket-Fehler #" << errno << ": " << strerror(errno);
#else
    int error = WSAGetLastError();
    temp << "Socket-Fehler #" << error;
    char* msg;
    if(FormatMessage(FORMAT_MESSAGE_ALLOCATE_BUFFER | FORMAT_MESSAGE_FROM_SYSTEM,
                     NULL, error, MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT),
                     reinterpret_cast<char*>(&msg), 0, NULL))
    {
        try
        {
            temp << ": " << msg;
            LocalFree(msg);
        }
        catch(...)
        {
            LocalFree(msg);
            throw;
        }
    }
#endif
    return std::runtime_error(temp.str());
}

Den Fehler:
IntelliSense: Das Argument vom Typ ""char *"" ist mit dem Parameter vom Typ ""LPWSTR"" inkompatibel.

&

Fehler 1 error C2664: 'DWORD FormatMessageW(DWORD,LPCVOID,DWORD,DWORD,LPWSTR,DWORD,va_list *)' : Konvertierung von Argument 5 von 'char *' in 'LPWSTR' nicht möglich

Kann mir da jmd weiterhelfen?

Grüße

unskilled

FormatMessageA statt FormatMessage

Damit behandelst du nur das Symptom, aber nicht die Ursache. Sofern du Visual Studio nutzt, solltest du von Unicode auf Multibyte umstellen. Damit werden automatisch die Funktionen mit Endung A aufgerufen.