Problem mit recv und endlos schleife

DaRe

Joar, ist ein wenig müsig sich da einzulesen.

Wenn du den Client nicht auch selbst programmierst, dann füge lieber noch eine "Date: " Angabe(beim Response) ein. Ich glaube, da hat mein Firefox bei meiner Serverantwort ein bissel gemeckert.

Tuxist

nimmt langsam form an

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <ctype.h>
#include <time.h>
#include <unistd.h>
#include <sys/types.h> 
#include <sys/socket.h>
#include <netinet/in.h>
#include <pthread.h>

#include "schnack.h"

#define buffersize 256

char *Schnack::Data=NULL;

void Schnack::sendHttp(int sock,const char *data){
  int n;
  char *tmp=(char*)malloc(strlen(data)+255);
  sprintf(tmp,"HTTP/1.1 200 OK\n Server: schack(Unix)\nContent-Length:"
              "%d\nConnection: close\nContent-Type: text/html\n\n\n%s",(int)strlen(data)+1,data);
  n = write(sock,tmp,strlen(tmp));
  if (n < 0){
    perror("ERROR writing to socket");
  }
  free(tmp);
}

void *Schnack::Httpd(void *httpsocket){
  intptr_t n=*(intptr_t*)httpsocket;
  char buffer[buffersize];
  int r=0;
  int i=1;
  while((r=recv(n, buffer, buffersize-1,0))>=0){
    i=(i+strlen(buffer));
    Data=(char*)realloc(Data,i);
    buffer[r]='\0';
    strcat(Data,buffer);
  }
  return 0;
}

void *Schnack::Parser(void *httpsocket){
  intptr_t n=*(intptr_t*)httpsocket;
  while(Data!=0){
    ((Schnack *)n)->sendHttp(n,Data);
  }
  pthread_exit(0);
}

Schnack::Schnack(int port){
  int sockfd;
  socklen_t clilen;
  struct sockaddr_in serv_addr, cli_addr; 
  sockfd = socket(AF_INET, SOCK_STREAM, 0);
  if (sockfd < 0){
    perror("ERROR opening socket");
    exit(1);
  }
  bzero((char *) &serv_addr, sizeof(serv_addr));
  serv_addr.sin_family = AF_INET;
  serv_addr.sin_addr.s_addr = INADDR_ANY;
  serv_addr.sin_port = htons(port);
  if (bind(sockfd, (struct sockaddr *) &serv_addr,sizeof(serv_addr)) < 0){ 
    perror("ERROR on binding");
    exit(1);
  }
  listen(sockfd,5);   
  clilen = sizeof(cli_addr); 
  while(1){
    Data=0;
    pthread_t cthread ,dthread;
    int newsockfd;
    newsockfd = accept(sockfd, (struct sockaddr *) &cli_addr, &clilen);
    if (newsockfd < 0){
      perror("ERROR on accept");
      exit(1);
    }
    pthread_create(&dthread, NULL, Schnack::Httpd,(void*)&newsockfd);
    pthread_create(&cthread, NULL, Schnack::Parser,(void*)&newsockfd);
    pthread_join(cthread, NULL); 
    close(newsockfd);
  }
  close(sockfd);
}

int main(int argc, char *argv[]){
    if (argc < 2){
      fprintf(stderr,"ERROR, no port provided\n");
      exit(1);
    }
    Schnack(atoi(argv[1]));
    return 0; 
}

314159265358979

Tuxist schrieb:

nimmt langsam form an

So hässlichen Code hab ich schon lange nicht mehr gesehen.

Tuxist

eine sehr präzise aussage muss ich schon sagen.

DaRe

Ich persönlich bin noch recht gut mit c unterwegs. Mit deinem Code komm ich zurecht, obwohl ich C++ nur halbherzig programmiere.

Ich glaube, dass ist in etwa seine Kritik. Du benutzt ne Mischung von C und C++... C deßhalb, weil ich dachte das in C++ nicht mehr gemalloced wird.

Oder hab ich jetzt noch was derb fatales übersehen?

Tuxist

man kann auch new und delete nehmen aber um realloc kommt nicht rum zu in verbindung mit char*, zum dem habe ich mir angewöhnt die Vorteile beider sprachen zu nutzen. Klassen und Templates von C++ und den Rest von C. Spart rechenzeit und ist trotzdem sehr übersichtlich und über new und delete lässt sich drüber streiten.

Ich programmiere fast ausschließlich in C++ und finde den Code auch grausam. Wenn man C++ nutzt, dann sollte man auch die entsprechenden Mittel einsetzen, die es einem bietet.

Das fängt schon bei diesem hässlichen Makro an. Makros sollte man übrigens immer in Großbuchstaben schreiben, damit man nicht wohlmöglich irgendwann mal ein int buffersize; in int 256; ersetzt bekommt...

Und durch weitere Abstraktionen, etc. hätte man sicher auch noch das ein odere andere close in einem Destruktor packen können. Netter Nebeneffekt: Die Verbindung wird definitiv geschlossen.

Tuxist schrieb:

man kann auch new und delete nehmen aber um realloc kommt nicht rum zu in verbindung mit char*, zum dem habe ich mir angewöhnt die Vorteile beider sprachen zu nutzen. Klassen und Templates von C++ und den Rest von C. Spart rechenzeit und ist trotzdem sehr übersichtlich und über new und delete lässt sich drüber streiten.

Man kann auch std::string nehmen und spart sich beides.

Im übrigen glaube ich nicht, dass dein Programm so performancekritisch ist, dass du überhaupt einen Unterschied merken würdest. Tatsächlich würdest du sogar noch schneller mit deinem Programm voran kommen und hättest dann Zeit dort zu optimieren wo es tatsächlich eng wird.

314159265358979

Tuxist schrieb:

Spart rechenzeit

Wohl kaum. Selbst wenn, du würdest es nicht mal merken.

Tuxist schrieb:

und ist trotzdem sehr übersichtlich

Dein Code ist das hässlichste Stück Scheiße, das ich seit Wochen gesehen habe. Sogar die schlechtesten Anfänger schreiben schöneren Code, wenn sie nicht gerade ein J.W. Buch haben.

Tuxist schrieb:

und über new und delete lässt sich drüber streiten.

Du hast new + delete nicht verstanden.

So viel Mist in einem Satz, Gratz!

Tuxist

sdfsdfsdf:

mit dem Marco haste recht habe ich übersehen und close kann man auch Deconstructor
paltzieren . Aber std::string mit C funktionen ist ein Interessantes Konstrukt. Ahja der kernel und die glibc sind in c geschrieben

314159265358979:
New ist vergleichbar mit Malloc.
delete ist vergleichbar mit free.

Schau mal GCC nach dar wird die das auffallen es nur kürzer weil der Rückgabe type entsprechend zurückgegeben wird

314159265358979

Tuxist schrieb:

Deconstructor

Es heißt Destruktor.

Tuxist schrieb:

Ahja der kernel und die glibc sind in c geschrieben

Zusammenhang zum Thread = 0.

Tuxist schrieb:

New ist vergleichbar mit Malloc.
delete ist vergleichbar mit free.

Nein. new ruft Konstruktoren auf, delete Destruktoren.

Tuxist schrieb:

Schau mal GCC nach

Ich brauche nichts nachsehen, ich weiß es besser als du.

Tuxist schrieb:

dar wird die das auffallen es nur kürzer weil der Rückgabe type entsprechend zurückgegeben wird

Siehe oben. Du hast new und delete nicht verstanden.

P.S.: Und schreib bitte Deutsch, es fällt mir unglaublich schwer, deine Posts zu entziffern.

Der Kernel operiert auch auf Hardware Ebene und muss zudem mit stark begrenzten Ressourcen auskommen. Das heißt nicht, dass es nicht auch in C++ möglich wäre, aber es macht einfach nicht viel Sinn.

Und das die C Bibliothek in C geschrieben ist. Tja, muss wohl was damit zu tun haben, dass es eine C und keine C++ Bibliothek ist (die C++ Bibliothek ist in C++ geschrieben).

Sind also alles keine Argumente dagegen. Ganz im Gegenteil. Viele Fehler im Kernel, etc. hätte man mit C++ verhindern können - man hatte aber einfach keine Wahl. Du hast aber die Wahl!

Tuxist

Nein. new ruft Konstruktoren auf, delete Destruktoren.

ja wenn man ein klasse verwendet:

Bezogen auf eine Klasse stimmt das, aber es ist auch new int oder new char[255] möglich und in diesem Fall wir es nur gewrapped.

Natürlich ist auch eine

Class class = new Class(); möglich hier wird die klasse mit einem Zeiger Initialisiert. Den man natürlich auch wieder löschen kann.

new reserviert Speicher und Delete gibt ihn wieder frei. Eigentlich ganz einfach.

Mit std::string kannst du auf diesen ganzen quatsch verzichten. Die C Funktionen brauchst du dann gar nicht mehr. Mit Ausnahme der Socket-Funktionen, aber dafür hat std::string die Funktion c_str und alles ist gut.

In C++ könnte man dann noch Smart Pointer verwenden, und braucht sich um das delete nicht mal mehr kümmern. Das Programm ist dadurch um einiges robuster und sicherer! Und das ist nicht zuletzt gerade bei einem Webserver wichtig, der ja möglichst immer erreichbar sein soll.

Aber mach mal wie du denkst. Irgendwann wirst du an einem Punkt sein, wo du merkst, das etwas schief läuft. Viel Spaß beim Suchen wünsch ich dir schon mal. Vielleicht denkst du dann ja nochmal an uns.

Tuxist

c_str gibt einen const char * zurück. Ist bißchen blöd wenn man reinschreiben muss :-p.

Tuxist schrieb:

c_str gibt einen const char * zurück. Ist bißchen blöd wenn man reinschreiben muss :-p.

std::vector<char> und dann ggf. in std::string. Glaub mir, du kannst dir das Leben so viel einfacher machen.

Wobei das natürlich nur geht, wenn nichts angehängt, etc. wird. In dem Fall kann man zur Not auch einen temporären char * verwenden und ihn einfach wieder in ein std::string umwandeln. Geht auch und ist um einiges schmerzfreier.

314159265358979

Tuxist schrieb:

aber es ist auch new int oder new char[255] möglich und in diesem Fall wir es nur gewrapped.

new benutzt man mit primitiven Typen so gut wie nie, mit Arrays schon gar nicht. Und dass da irgendwas gewrapped wird, steht nirgens im Standard.

Tuxist schrieb:

c_str gibt einen const char * zurück. Ist bißchen blöd wenn man reinschreiben muss :-p.

&str[0]

Wieder ist das Problem nicht C++, sondern deine Ahnunglosigkeit.

sdfsdfsdf schrieb:

std::vector<char> und dann ggf. in std::string.

Schwachsinn.

@Tuxist: An deiner Stelle würde ich ganz schnell leise sein und vielleicht diesen komischen 314159265358979 bitten, den Code zu verbessern. Das hier führt zu nichts.

std::string getHttp(int sock)
{
	std::string data;
	std::vector<char> buffer(BUF_SIZE);

	while (recv(sock, &buffer[0], BUF_SIZE, 0) > 0)
		data += std::string(buffer.begin(), buffer.end());

	close(sock); 

	return data;
}

Ungetestet.

314159265358979 schrieb:

Tuxist schrieb:

c_str gibt einen const char * zurück. Ist bißchen blöd wenn man reinschreiben muss :-p.
&str[0]

Schwachsinn.

314159265358979

sdfsdfsdf schrieb:

data += std::string(buffer.begin(), buffer.end());

Schwachsinn, eine sinnlose Kopie.

Und wie würdest du es lösen? Stattdessen std::vector vergrößern und recv die neue Adresse übergeben?

Das Ergebnis ist nicht viel anders, aber umständlicher. Ich bin trotzdem gespannt