[C/WIN32] PROXY AVEC THREAD

Commentaire de psyphi le 18/04/2006 23:26:20

Merci de ton aide :D
>Comment se fait-il que sizeof(host) renvoie 4 ?
>Tu peux m'expliquer un peu plus cet histoire de prototype?
>Toujours pas d'idées quant a mon histore de buffer2?

Commentaire de psyphi le 18/04/2006 23:37:11

Oki merci bien, au fond ca semble logique en plus.
Sinon pourquoi 4 octets pour un pointeur?

Commentaire de psyphi le 18/04/2006 23:55:03

Ouki, c'est en fonction du bus d'adresse du processeur 2^32 = 4294967296 adresses possibles. Il faut donc une capacité de 4 octets (32bits) [Tout ca pour un processeur 32bits] c'est là encore logique ;-) merci BruNews de m'avoir éclairé.

Commentaire de psyphi le 22/04/2006 18:08:38

Merci de t'interessé à ma source.
Question débordement je ne pense pas, car dans quand je reçois les données avec la fonction recv(), le troisième argument sert à définir la longueur maximal du message reçu en octet, donc si je définit comme longueur maximale la taille de mon tampon, je ne pense pas qu'il y ait de problème.
Pour la taille des buffers par contre je ne sais pas trop qu'elle est la meilleur taille à utiliser pour des transferts de données, on m'a dit sur un forum d'utiliser des buffers de 4ko ou 16ko, si qqun à des propositions avec explications je suis preneur.
Peut être qu'il y a encore des erreurs dans la reception des requêtes, il faudrait peut être que je rajoute un filtre spéciale, car on n'est pas à l'abris que quelqu'un forge sa propre requête avec des commandes fallacieuses.

Commentaire de psyphi le 24/04/2006 00:29:51

J'ai corrigé l'erreur du multithreading, c bon.

Commentaire de bipbip45 le 24/04/2006 20:43:17

Je ne connais pas calloc. Dans la mesure où c'est équivalent à malloc, je pense qu'il conviendrait de vérifier le code de retour de cette fonction avant de considérer le pointeur comme alloué:
    if(buf==NULL) {
        desallocation des autres buffers et fermeture des fd
        return EXIT_FAILURE;
    }

    suite du code

Par ailleurs, juste histoire de simplifier le code, tu aurais peut-être pu utiliser snprintf plutot que de multiplier l'emploi de strncat.

Dans tous les cas, merci pour ton code.

Commentaire de bipbip45 le 30/04/2006 18:51:18

En fait snprintf te permet de formater une chaîne de caractères de la même manière que printf, mais au lieu que ce soit vers la sortie standard de l'exécutable, c'est dans un buffer délimité en taille (afin de se prémunir des buffer overflow comme strncat).
Voici son prototype:
int snprintf (char *str, size_t size, const char  *format, ...)
Pour plus d'info sur snprintf, un page de manuel en français se trouve à l'URL : http://dpobel.free.fr/man/html/affiche_man.php/3369/man/snprintf/

Voici un exemple de remplacement de deux strncat par un snprintf:
strncat(httpRequest, header, strlen(header));       strncat(httpRequest, "\r\n", 2);

snprintf(httpRequest,sizeof(httpRequest),"%s\r\n",header);

Néanmoins cela nécessiterait que tu revoies toute la gestion de ton buffer httpRequest; car au lieu d'ajouter en fin de buffer comme le fait strncat, snprintf repart du début du buffer.
Cela aurait pu simplifier l'écriture de la fonction "build_post_request". En effet, ce que tu réalises avec l'appel à moulte strncat (un strcat s'est perdu dans la fonction par ailleurs), aurait pu être remplacer par un unique snprintf.

En terme de performances, il faut voir que chaque appel de fonction implique de placer dans la pile les arguments et donc une consommation de mémoire ce qui est assez critique pour un serveur.

Voilà, ce n'était par pour pinailler mais juste pour apporter une briquette à ton édifice.

Commentaire de bipbip45 le 02/05/2006 17:06:01

J'ai commencé à lire ton code un peu plus dans le détail et voici quelques éléments qui 'mont surpris en dehors de ceux précités:
> on trouve dans le code, par exemple en ligne 97-98  beaucoup de boucles du type:
               while(buffer[i]!='car')
                   i++;
Il se peut que le proxy recoive des paquets malformés voire forgés. Dans ce cas, et sans limite d'indice, il y a de grande chance qu'à force d'incrémenter i, on obtienne une erreur de segmentation due à une lecture arbitraire sur une zone mémoire interdite. (idem ligne 15-116,134-138,164-168,...)

> la fonction get_header_if_exist renvoie un code de retour de type short qui n'est pas exploité lors des appels dans la fonction parse_http_request.

> dans la fonction get_content_lenth : dans le cas ou tu recois un paquet malforme ou le champ "Content" comprend plus de 10 caracteres, ton buffer vas exploser ce qui entrainera au mieux une erreur de segmentation et au pire l'écrasement des données suivantes dans la pile. Peut etre vaudrait-il mieux realiser le calloc un fois que tu sais combien il faut allouer (size-i+1 je crois). De plus, une fois que size est calcule, c'est que ContentLength termine par '\0' (sinon strlen echoue) et donc on pourrait directement ecrire size=atoi(ContentLength+(i+1)).

>lorsque tu emploies la fonction strstr, je pense qu'il faudrait se méfier; en effet en lisant la documentation de strstr(), si la fonction ne trouve pas la sous-chaine, elle renvoie NULL. Je pense que, en ligne 134 par exemple, il faudrait faire une verfication de buffer avant d'effectuer buffer[i] en sortie de strstr.

Voila, j'espere ne pas d'embeter avec ces commentaires; n'hesite pas a me le dire si c est le cas et je me rendrai silencieux.

Commentaire de bipbip45 le 03/05/2006 17:12:41

J'ai enfin fini de lire le code (pas encore exécuté car suis sous Linux). Et voici quelques autres commentaires:

> en mode thread, il me semble que lorsqu'un thread, réalise un exit, c'est l'ensemble des threads et donc ton programme qui réalise un exit. En conséquence, je pense que tu devrais éviter de faire des appels à exit(1) (en ligne 204, 282 ...) lorsqu'une erreur est rencontrée. Mieux vaut propager l'erreur vers les fonctions appelantes avec return EXIT_FAILURE, qui, si c'est la fonction principale du thread mettra fin à celui-ci.

> la fonction proxy() est critique: en effet dans cette fonction, tu alloues l'ensemble des buffers ... Je pense qu'il faudrait réaliser la désallocation de l'ensemble des buffers avant de faire return, qu'un erreur se soit produite ou non. Donc tous les appels à calloc() qui ont eu lieu dans cette fonction ou dans les fonctions appellées (ex: port (l387) ou hostname alloué par gethost() ...)

> fonction send (ex: l.441, l.449): il se peut que send ne parviennent pas à transmettre une requete. C'est pouquoi cette fonction a une code de retour correspondant au nombre de caractères écrits dans la socket. Il convient donc à mon avis de l'exploiter.

> closesocket (l.502, l.516): ici tu fais un close(socket_client) en cas d'erreur. Je pense que c'est un lapsus et qu'il s'agit de socket_local. En effet, socket_local n'existe qu'après l'appel accept (l.512).

> l.529 et l.541 return EXIT_FAILURE: tu as oublié de fermer les sockets avant de sortir.

> enfin je ne connais pas l'API des threads windows mais la version POSIX indique qu'il faut explicitement les détacher si on se moque de leur code de retour car dans le cas contraire, on risque une fuite de ressource. Ici tu ne le fais pas (cf man pthread_join,pthread_detach).

Bon courage pour tes partiels.

Commentaire de xav987 le 08/02/2007 09:49:16

Il y a un petit bug qui fait que certains compilo retournent une erreur. CodeBock, qui est moins rigoureux, ne signale rien :
Dans ta fonction proxy() tu fais un "buffer2[size]='\0';", donc tu ecrases le dernier octet du buffer2. Sa provoque un stack arround.
Moi j'ai mis "buffer2[KB_SIZE*4+1]" dans la declaration de buffer2 et "sizeof(buffer2)-1" dans la declaration de "size", comme ça on reste dans des echanges de 4096 octet.
Sinon, sur certains site (genre Wikipedia), j'ai un message d'erreur avec la fonction send() et la page ne s'affiche pas, j'ai pas encore trouvé la raison.

A part ça, magnifique programme, difficilement lisible, je trouve, mais qui me servira beaucoup ! 9* =)

Commentaire de xav987 le 08/02/2007 11:13:52

Pour l'erreur du Wiki, j'ai trouvé à quoi elle est liée :
Quand on affiche la page du Wiki et qu'on la ferme avant qu'elle ne soit pas totalement apparut, il genere une erreur dans la fonction send(). Sa ne le fait que pour le Wiki, je ne sait pas pourquoi.

Sous CodeBlock, sa continue de tourné, mais sous d'autre compilo, il genere une erreur a cause du free(port). En effet juste avant tu as "port = "80"" donc tu libere un espace qui n'a pas été aloué dynamiquement.
Tu as le meme probleme avec le "free(httpRequest);" qu'on retrouve assez souvent alors qu'il n'a pas encore été declaré...
J'ai remplacé "port = "80"" par "strcpy(port, "80");" et sa passe sans probleme.

Pour la lisibilité, c'est surtout une question de gout personnel. Je n'aime pas mais certains doivent apprecier ta façon de presenter ton code, c'etait juste une petite remarque et pas du tout un reproche, et ce n'est valable que pour moi.

Commentaire de psyphi le 08/02/2007 11:55:51

Tu compiles avec quel compilateur et quelle version?

Commentaire de psyphi le 08/02/2007 20:44:35

Ok bon là j'ai essayé de compiler avec Visual Studio 2005, j'ai eu pas mal d'erreurs, j'en ai corrigé pas mal, dès que tout est propre je poste le .zip

Commentaire de victorcoasne le 11/07/2007 23:22:53

Essaye ebay.fr et tu vas rire ;)