Structure contenant une socket

Bonjour,

J'ai un soucis lorsque je fais un write() vers une socket qui est contenue dans une structure qui elle est placée dans une file de messages ...

illustration:

Coté Client:
- Un fork() permettant la réception des messages envoyés par le serveur est lancé
- Envoie des requêtes (qui sont ajoutées dans une file de messages coté serveur).

Coté Serveur:
- Des fork() pour accepter les clients sont lancé (quand le premier client est accepté, un autre fork() qui est unique est lancé et permet de gère la file de messages).

-On récupère les requêtes envoyées par les clients dans la structure et on y ajoute leurs SOCKET, une fois cela fais on place la structure dans la file de messages.

structure:
la structure:

Code:

---

1 2 3 4 5 6

typedef struct TRT TRT struct TRT{ ... SOCKET csock };

---

-Le fork() qui traite la file de messages notifie les clients une fois leurs requêtes traité

Problème:
-Quand le fork() qui traite la file de messages notifie les clients seul le premier client est notifié via un write(trt.csock,...); pourtant toutes les requêtes sont traité et dans la partie du code ou se trouve les write(), les printf() de debug sont bien affiché, et quand j'affiche la SOCKET contenu dans ma structure j'ai le même résultat lorsque j'affiche la SOCKET que après avoir accepte le client.

note: j'ai remarqué que si je lance le fork() qui gère la file de messages avant d'accepter les clients, même le premier client n'est plus notifier via sa SOCKET et pourtant les requêtes de ma structure sont bien géré.

Bien à vous!

(Désolé des fautes d’orthographes restante, je ne suis pas très fort pour ça).

Gérer un serveur avec des forks ? J'avais jamais vu ça encore... C'est une contrainte imposée ? Si ce n'est pas le cas, je te recommande très fortement de regarder pthread.

Citation:

---

Envoyé par imperio

Gérer un serveur avec des forks ? J'avais jamais vu ça encore... C'est une contrainte imposée ? Si ce n'est pas le cas, je te recommande très fortement de regarder pthread.

---

Aujourd'hui, oui. Jusqu'à une époque récente (par rapport à l'âge du système, et même à Linux qui va sur ses 24 ans tout de même), il n'y avait rien de normalisé de ce côté-là sous UNIX. Par conséquent, on forkait (même si clone() sous Linux permettait de faire les choses plus finement) et, par conséquent, on essayait de limiter le nombre de processus fils, voire même de les éliminer complètement quand il était envisageable de tout faire dans une même boucle principale (par exemple, un petit serveur de chat limité à quelques personnes). Algorithmiquement, c'est quand même intéressant d'être capable d'implémenter soi-même du multitâche quand le système ne propose pas de quoi le faire (notamment dans les systèmes embarqués et les petits micro-contrôleurs).

Puisque les pthreads sont normalisés et proprement implémentés, ce n'est plus la peine de s'en passer, bien sûr. C'est plus facile à gérer, ça permet de tuer un client en particulier sans casser tout le serveur et ça protège aussi celui-ci en cas de de segfault. Par contre, ça n'est vrai que jusqu'à une certaine limite. Dès qu'il s'agit de monter en charge et d'être rapide en servant des milliers de clients à la fois, créer au moins un thread par connexion active risque de commencer à être très couteux.

@Obsidian: Merci beaucoup pour ces éclaircissements !