Fork, pthread et serveur multi-clients

Version imprimable

03/01/2006, 15h10
Pico10

Fork, pthread et serveur multi-clients

Bonjour à tous,

On vient de me donner le code d'un serveur en C pour que je le modifie. Dans l'état actuel des choses, le client se connecte au serveur pour lui envoyer un login et une ip. Pour chaque connexion, le serveur fait un fork pour traiter les données. Le but est maintenant de stocker ce couple (ip,login) dans une table de hachage. J'ai déjà codé les fonctions pour la table de hachage mais il me reste un gros problème à résoudre.

Il y a longtemps que j'avais pas fait de programmation système et donc, dans un élan d'enthousiasme, j'ai rajouté les fonctions ajout_hash dans le traitement... sauf que ma table de hachage est dupliquée pour chaque processus traitant les demandes :(

La seule solution que je vois là serait de faire communiquer les processus qui traitent les connexions avec le processus père. Ainsi, seul le processus père connait l'état de la table de hachage et peut ajouter ou supprimer les données...

Maintenant, il y a peut être d'autres solutions, comme par exemple un second serveur qui se contente de communiquer avec les processus qui traite les connexions pour garder la table de hachage à jour... sachant qu'il faut aussi qu'on puisse accèder au données de la table.

J'ai pensé aux tubes, aux mécanismes IPC mais je ne suis pas vraiment expert dans ce domaine...

Merci pour vos conseils! :)
03/01/2006, 15h47
hegros

Bonjour,

Je comprends pas vraiment ton problème. Ton problème se situe dans le fait que le processus père posséde une table de haschage et que lorsqu'il crée des fils ces derniers possédent une copie ? Si c'est cela pourquoi cela pose t-il problème ? J'avoue ne pas comprendre.
03/01/2006, 16h08
Pico10

Désolé, je me suis mal expliqué. Vu qu'il y a plusieurs connexions qui peuvent arriver, elles sont traités par différents processus. Cependant, les données reçues par le serveur (les couples (login,ip)) doivent être stockées dans la table de hachage du processus père.

En gros, comme c'est là, même si je la passe en paramètre aux processus fils, ils ajoutent la connexion qu'ils viennent de traiter mais à la fin du processus, la table de hachage est redevenue vide puisque le processus fils a travaillé sur sa propre copie...

J'espère avoir été plus clair :)
03/01/2006, 16h33
fearyourself

Pourquoi ne pas utiliser des threads à la place d'un fork... Tu n'aurais plus le même genre de problème...

Jc
03/01/2006, 16h36
hegros

Je sais pas si en rajoutant le qualificatif static de ta table de haschage ( qui je suppose est local à la fonction main) cela permet de la conserver
03/01/2006, 17h30
Pico10

Citation:

Envoyé par hegros

Je sais pas si en rajoutant le qualificatif static de ta table de haschage ( qui je suppose est local à la fonction main) cela permet de la conserver

Non ca ne marche pas. Maintenant je vais essayer les threads comme me le conseille fearyourself. Je vous tiens au courant dés que c'est testé ;)
04/01/2006, 09h36
Pico10

J'ai fait quelques recherches sur les pthreads et ca à l'air plutot pas mal. Par contre, si j'ai bien compris, pour passer des paramètres au threads, il faut passer un pointeur sur une structure, le tout casté en (void *). Et donc, pour les ajouts dans la table de hachage, il faut que j'utilise l'exclusion mutuelle, n'est ce pas?

Merci d'avance! :-)
04/01/2006, 09h41
Médinoc

Oui, tu auras besoin d'exclusion mutuelle, dès que tu as au moins un thread qui doit écrire (car il est imprudent de lire la table pendant qu'elle est modifiée).

Pour cela, soit tu fais du multi-lecteurs/écrivain (les threads lecteurs peuvent lire simultanément) --> pas toujours facile à implémenter, mais plus performant
soit tu fais de l'exclusion mutuelle pure (Les threads ne peuvent plus lirent simultanément) --> moins performant, mais plus simple à implémenter: un simple mutex suffit.
04/01/2006, 14h52
Pico10

Donc en gros c'est quelque chose comme ça qu'il faut que je fasse :

http://fr.wikipedia.org/wiki/Probl%C3%A8me_des_lecteurs_et_des_r%C3%A9dacteurs

Enfin à mon avis, je peux retirer le sémaphore M_Red qui n'a pas un grand intérêt à mon sens...

Merci pous vos conseils :)
05/01/2006, 11h17
Pico10

Bien j'avance dans mes recherches et j'ai différentes questions.

Donc il me semble que dans mon cas, les phreads seraient bien plus pratiques au niveau de la gestion de la table de hachage. Par contre j'ai trouvé le code d'un serveur censé géré le multi-client mais ca n'a pas l'air de fonctionner. Quand je rallonge les temps de traitement, je ne vois qu'un client à la fois... Donc je voulais savoir si c'est possible de gérer du multi-client avec les pthreads?

Sinon, est ce qu'il vaut mieux créer plusieurs threads dés le début qui écoutent tous pour voir s'il y a des connexions ou bien créer un thread par connexion? Il ne devrait pas y avoir un très grand nombre de connexion simultannées.

Merci d'avance!
05/01/2006, 11h22
fearyourself

Citation:

Donc je voulais savoir si c'est possible de gérer du multi-client avec les pthreads?

Bien sûr, la question est de voir comment tu gères les connections, à quel moment est-ce que tu utilises tes mutex/sémaphores pour les zones critiques...

Citation:

Sinon, est ce qu'il vaut mieux créer plusieurs threads dés le début qui écoutent tous pour voir s'il y a des connexions ou bien créer un thread par connexion?

Il vaut mieux (voir c'est la seule solution plausible) avoir un thread qui écoute, lorsqu'il y a une connection, créé un autre thread qui gère la connection.

Jc
05/01/2006, 11h31
Pico10

Ok donc là en gros c'est ce que j'ai mais avec des forks! Plus qu'à modifier ca avec des pthreads!

Au niveau sémaphores, j'en aurais un pour la lecture et un pour l'écriture, c'est pas ce point là qui me pose problème, c'est plutot le fait que plusieurs connexions soient gérées en même temps...
05/01/2006, 11h37
fearyourself

Je ne vois pas vraiment le problème tu as un serveur qui "écoute" pour les connections (si on est en TCP)... Lorsqu'il détecte un nouveau client, il créé un thread qui le gère et se remet à écouter...

La question de gérer plusieurs connections n'est pas vraiment un problème puisqu'il y a une file d'attente pour les connections en attente. Donc même si tu as deux clients qui veulent se connecter en même temps, la file d'attente le gérera correctement... (il faut juste pas qu'il déborde mais même, à ce moment la connection est simplement refusé au niveau du client)

Du coup, si deux clients veulent se connecter en même temps, le serveur voit le premier, créé un thread qui s'occupera du client, et ensuite s'occupera du deuxième. Tout ceci est plus ou moins interne à la gestion de TCP....

Si tu es en UDP, c'est un peu plus compliqué mais pas trop non plus... Comme premier abord, utilise plutôt TCP...

En espérant avoir répondu à la question,
Jc

Ok, sauf que là moi j'avais ce genre de chose avec des fork:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 if ((pid = fork()) == -1) { close(sock_waiting); close(ctrl.cnx_sock); error_detected("fork error", 1); } else if (pid == 0) { close(sock_waiting); handle_client(&ctrl); exit(0); } else close(ctrl.cnx_sock);
Donc je peux plus gérer de la même manière si j'ai bien compris. Parce que si je ferme ctrl.cnx_sock dans le père, ca va le fermer aussi pour le thread non?