Sockets et pthreads

Salux,

J'ai une application qui fait un traitement assez long et, en parallele je devrais avoir une partie qui receptionne des "requetes" permettant notamment de savoir où ça en est.
Il s'avere que je ne puisse peut etre pas utiliser les Fifos alors j'ai pensé aux sockets (domaine Unix).
Je prefererais eviter aussi les sockets non bloquantes, du coup on se retrouve forcement avec un schema multi-thread, ou multi-process

J'étais en train de jeter un oeil sur les threads et je ne vois pas vraiment de mecanisme permettant de stopper proprement l'eventuel thread (qui serait bloqué par accept())
Dans ces cas là, la seule solution serait fork+signal ?

Mercix

Une solution consisterait à définir un message de fin. Lorsque le dit thread reçoit ce message, il arrête tout et se termine.

Et apres tu te retrouves a faire un serveur concurrent que tu quittes en gérant le signal sigint.
mais sinon le fameux "quit" quand tu veux quitter!

Citation:

---

Envoyé par Gruik

Salux,

J'ai une application qui fait un traitement assez long et, en parallele je devrais avoir une partie qui receptionne des "requetes" permettant notamment de savoir où ça en est.
Il s'avere que je ne puisse peut etre pas utiliser les Fifos alors j'ai pensé aux sockets (domaine Unix).
Je prefererais eviter aussi les sockets non bloquantes, du coup on se retrouve forcement avec un schema multi-thread, ou multi-process

J'étais en train de jeter un oeil sur les threads et je ne vois pas vraiment de mecanisme permettant de stopper proprement l'eventuel thread (qui serait bloqué par accept())
Dans ces cas là, la seule solution serait fork+signal ?

Mercix

---

Attends.. Quel est le problème exact :

tu voudrais que pendant que ton appli (traitement long) tourne, une partie de cette appli reçoive des requêtes ? ou envoie des statuts ? et les recevoir avec une autre appli ?

Si tu veux pouvoir terminer proprement un thread qui ne fait que de l'attente de connexion (type accept()) en boucle, je ne vois pas trente-six solutions propres :
Pour moi, tu dois ajouter un second socket pour ce thread, et écouter avec select().
Une tentative de connexion (ou un envoi de données si le socket de contrôle est déjà connecté) sur ce socket et hop! Tu peux quitter ton thread proprement.

De plus, ce second socket peut être juste un socket local, sans port fixe, connu seulement de ton application : Elle peut se connecter dessus en interne, par exemple en cas de réception d'un ordre d'arrêt sur un autre socket.

Citation:

---

Envoyé par stephl

Une solution consisterait à définir un message de fin. Lorsque le dit thread reçoit ce message, il arrête tout et se termine.

---

Oui mais le "thread" serait bloqué par une fonction bloquante

Citation:

---

Attends.. Quel est le problème exact :

tu voudrais que pendant que ton appli (traitement long) tourne, une partie de cette appli reçoive des requêtes ?

---

c'est bien ça

Citation:

---

ou envoie des statuts ? et les recevoir avec une autre appli ?

---

bein elle recevrait des requetes en renverrait une reponse

Citation:

---

Si tu veux pouvoir terminer proprement un thread qui ne fait que de l'attente de connexion (type accept()) en boucle, je ne vois pas trente-six solutions propres :
Pour moi, tu dois ajouter un second socket pour ce thread, et écouter avec select().
Une tentative de connexion (ou un envoi de données si le socket de contrôle est déjà connecté) sur ce socket et hop! Tu peux quitter ton thread proprement.

De plus, ce second socket peut être juste un socket local, sans port fixe, connu seulement de ton application : Elle peut se connecter dessus en interne, par exemple en cas de réception d'un ordre d'arrêt sur un autre socket.

---

D'accord merci
C'est vrai j'avais deja entendu parlé de select, je vais me renseigner dessus

OK alors pas besoin de multithread, mais (si elle doit ET recevoir ET émettre) effectivement 2 sockets. Socket de réception en asynchrone.

Et en plus (j'ai fait ça dans des serveurs de données), si tu veux juste dire que le traitement est pas fini, un timer qui déclenche l'écriture de "Working..", ou bien directement un appel à une fonction qui va écrire "Working on xxxx".

En fait, c'est une structure de base client serveur, avec reception des 2 côtés en asynchrone.

Et sinon, j'ai une autre idée (bête...) mais :

si c'est juste pour savoir un truc comme ça, pourquoi simplement ne pas mettre un timer dans l'aplli "surveillante", et toutes les X secondes aller vérifier un fichier où simplement tu écrirais "Je travaille sur ...." ou "j'ai fini".. ?

Citation:

---

Envoyé par Gruik

Oui mais le "thread" serait bloqué par une fonction bloquante

---

C'est justement à cela que sert le message de fin. Le thread (#1) en question est à l'écoute (listen()) et accepte les connexions. Lorsque l'on souhaite arrêter ce thread (qui bloque sur un accept() s'il n'y a plus de message), le thread #2 qui aura été lancé au préalable, envoie sur le port écouté par le thread #1 le message de fin. Ainsi, le thread #1 se débloque (accept() retourne), reconnaît le message de fin, ferme sa socket et se termine.

Citation:

---

Envoyé par souviron34

OK alors pas besoin de multithread, mais (si elle doit ET recevoir ET émettre) effectivement 2 sockets. Socket de réception en asynchrone.

Et en plus (j'ai fait ça dans des serveurs de données), si tu veux juste dire que le traitement est pas fini, un timer qui déclenche l'écriture de "Working..", ou bien directement un appel à une fonction qui va écrire "Working on xxxx".

En fait, c'est une structure de base client serveur, avec reception des 2 côtés en asynchrone.

---

Bein les sockets sont deja bidirectionnelles ;)

Citation:

---

Et sinon, j'ai une autre idée (bête...) mais :

si c'est juste pour savoir un truc comme ça, pourquoi simplement ne pas mettre un timer dans l'aplli "surveillante", et toutes les X secondes aller vérifier un fichier où simplement tu écrirais "Je travaille sur ...." ou "j'ai fini".. ?

---

J'y ai pensé mais ça me semblait pas terrible

Citation:

---

C'est justement à cela que sert le message de fin. Le thread (#1) en question est à l'écoute (listen()) et accepte les connexions. Lorsque l'on souhaite arrêter ce thread (qui bloque sur un accept() s'il n'y a plus de message), le thread #2 qui aura été lancé au préalable, envoie sur le port écouté par le thread #1 le message de fin. Ainsi, le thread #1 se débloque (accept() retourne), reconnaît le message de fin, ferme sa socket et se termine.

---

Ahhh mais c'est bien sur ^^
Si le thread est bloqué par une attente de connexion, suffit que le thread principal s'y connecte lui meme et envoie un message particulier de terminaison...

Groovy

Mais pour reconnaitre le message de fin, il faut que le thread qui fait le accept() fasse un recv() en plus sur le socket qu'il vient d'accepter...

Citation:

---

Envoyé par Médinoc

Mais pour reconnaitre le message de fin, il faut que le thread qui fait le accept() fasse un recv() en plus sur le socket qu'il vient d'accepter...

---

Ca tombe sous le sens; je n'ai pas décrit toutes les étapes mais juste la trame générale à suivre.

Oui, of course qu'il fera un recv juste apres

Mais si le client n'envoit rien, le thread du accept() restera bloqué sur le recv() et ne pourra plus rien accepter d'autre.

Sauf bien sûr en utilisant select()...

Avec select(), on peut choisir de mettre toute la communication réseau dans le même thread, et par exemple lancer les opérations longues dans des threads à part (ou UN thread (ou encore un pool de threads) avec une file d'attente)...

Effectivement :/
Enfin ça complique qd meme pas mal, avoir 2 connexions
Mais ya pas le choix

Au fait pour le file descriptor de communication entre le thread principal et le thread gerant les requetes, ne serait il pas plus simple d'utiliser une pipe?

Citation:

---

Envoyé par Gruik

Bein les sockets sont deja bidirectionnelles ;)

---

OUI mais tu peux pas être à la fois asynchrone et synchrone. Et pour écrire faut être synchrone.. Et en plus si tu utilises le même, tu sera réveillé chaque fois que tu écris, même en auto ..

Donc moi quand je fais ça j'en prends 2 : 1 en écoute et un en écriture pour le client et le serveur.

Citation:

---

Envoyé par Gruik

J'y ai pensé mais ça me semblait pas terrible

---

Tout dépend de l'appli. Mais si le but est strictement juste de dire "j'en suis là", pourquoi faire compliqué alors qu'on peut faire simple ??

Citation:

---

Envoyé par souviron34

OUI mais tu peux pas être à la fois asynchrone et synchrone. Et pour écrire faut être synchrone.. Et en plus si tu utilises le même, tu sera réveillé chaque fois que tu écris, même en auto ..

Donc moi quand je fais ça j'en prends 2 : 1 en écoute et un en écriture pour le client et le serveur.

---

oki

Citation:

---

Tout dépend de l'appli. Mais si le but est strictement juste de dire "j'en suis là", pourquoi faire compliqué alors qu'on peut faire simple ??

---

Non ce n'est pas que ça

Citation:

---

Envoyé par Médinoc

Mais si le client n'envoit rien, le thread du accept() restera bloqué sur le recv() et ne pourra plus rien accepter d'autre.

Sauf bien sûr en utilisant select()...

---

Pas besoin d'utiliser select(). Le thread #2 se connecte sur le port écouté par le thread #1 (thread que l'on souhaite arrêter). Le thread #1 est donc débloqué (accept() retourne). Le thread #1 fait appel à recv() pour recevoir le message de fin envoyé par le thread #2. Ainsi, le thread #1 peut se terminer. Cette solution fonctionne très bien, je l'ai déjà implémentée avec sucès sur un petit projet clients-serveur.

Le problème, c'est que le thread #1 ne sait pas si le client vient du thread #2 ou d'un autre processus tant que recv() n'a pas retourné.

Donc, le thread #1 doit obligatoirement faire le recv().
Résultat, si un client extérieur se connecte puis n'envoit rien du tout, le serveur reste bloqué sur le recv() en attendant que le client envoie.

Résultat, si je fais un client qui se connecte puis plus rien, j'ai lancé une attaque Denial of Service sur le serveur de Gruik à peu de frais...

Citation:

---

Envoyé par Médinoc

Le problème, c'est que le thread #1 ne sait pas si le client vient du thread #2 ou d'un autre processus tant que recv() n'a pas retourné.

Donc, le thread #1 doit obligatoirement faire le recv().
Résultat, si un client extérieur se connecte puis n'envoit rien du tout, le serveur reste bloqué sur le recv() en attendant que le client envoie.

Résultat, si je fais un client qui se connecte puis plus rien, j'ai lancé une attaque Denial of Service sur le serveur de Gruik à peu de frais...

---

Et alors? Ce problème existe de toute façon, même en dehors de la question d'arrêter proprement le thread#1.

Ben non : Si le thread 1 ne fait pas lui-même le recv(), ou s'il utilise select(), il ne sera pas bloqué par un seul client.

On peut considérer que les "clients" ne seront jamais autre chose que des applications internes, et yaurait pas lieu d'etablir une vraie robustesse à ce niveau là

Citation:

---

Envoyé par Médinoc

Ben non : Si le thread 1 ne fait pas lui-même le recv(), ou s'il utilise select(), il ne sera pas bloqué par un seul client.

---

Je ne saisis pas. Il faut bien que quelqu'un le fasse ce recv()?!?! En outre, select() permet juste de savoir si accept() retournera, non? Cela ne garantit pas que recv() retournera aussi.

perdu, ça teste pour les deux si on lui passe les deux sockets (ou beaucoup plus)

Citation:

---

Envoyé par Médinoc

perdu, ça teste pour les deux si on lui passe les deux sockets (ou beaucoup plus)

---

Désolé mais je ne comprends toujours pas votre explication. Vous utilisez select() sur 2 sockets: la #1 qui sert à la communication avec les clients et la #2 qui permet d'envoyer des messages de contrôle. Si lors d'un select(), seule la socket #1 est identifiée dans le paramètre readfs de select(), alors vous allez faire un accept() puis un recv(), et donc vous êtes confronté au même problème, à savoir que le client peut ne pas envoyer de données.

Ben non : Si la #1 est "identifiée dans le paramètre readfs de select()", alors on fait juste le accept() et on l'ajoute aux prochains select()...

Citation:

---

Envoyé par Médinoc

Ben non : Si la #1 est "identifiée dans le paramètre readfs de select()", alors on fait juste le accept() et on l'ajoute aux prochains select()...

---

D'accord, et donc au prochain select(), si la socket #1 est identifiée dans readfs, alors cela signifie que recv() ne bloquera pas, c'est bien cela?

Pas la socket #1 : La socket retournée par accept().

Citation:

---

Envoyé par Médinoc

Pas la socket #1 : La socket retournée par accept().

---

Oui, c'est juste. OK, merci pour l'explication. J'ai saisi maintenant.