Discussion :

[cybersplash]

Bonsoir,

Je suis en train de coder un clone de client et de serveur irc.
Je m'appuie de loin sur le protocole irc.

Le serveur accepte la connection et crée un nouveau processus pour chaque client.
Pour gérer les clients le serveur et tous les fils partage un segment de memoire contenant un tableau de struct user
voila la struct :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
typedef struct {
	int sock;
	char nick[MAXNAME];
	struct sockaddr_in addr;
	socklen_t addr_t;
	int nbChan;
	char chan[MAXCHAN][MAXNAME];
} user;

Le client se connecte au serveur, crée un nouveau processus pour lire sur le socket et ecrit via le pere.

Tout marche bien sauf dans le scénario suivant :

client1 se connecte
client2 se connecte
client3 se connecte

// dans cette phase peut importe l'ordre de connexion au channel
client2 rejoin le channel #chan
client3 rejoin le channel #chan
client1 rejoin le channel #chan

client1 envoi un message sur le channel. Le seul client a voir le message est client1
client3 envoi un message sur le channel tous les clients le recoivent
client2 envoi un message sur le channel les client1 et 2 voient le message

Lors de l'envoi du message du client1 vers les clients 2 et 3 je recoi une erreur du sendto (ou du send) de type EBADF

Le descripteur de socket passé en paramètre est bon il correspond bien a celui des différent clients que je veux contacter.

J'espère avoir été le plus clair possible si ce n'est pas le cas demandez moi

Merci d'avance pour vos réponses et pour votre compréhension si le problème vous semble ridicule :p

[Médinoc]

1. C'est donc le serveur qui forke, pas le client comme ton titre le suggère
2. C'est un problème inhérent aux serveurs-fork, les descripteurs sont dupliqués dans le fork mais pas partagés.
   En fait, je serais plutôt du genre à déconseiller en bloc le serveur-fork s'il y a une relation entre les clients (ce qui est le cas pour un chat) : Un serveur-fork, ça marche bien quand les clients sont indépendants, par exemple pour un serveur Web ou SSH (pour du FTP, ce n'est pas indépendant).

[cybersplash]

J'ai bien vu pendant la phase de dev que le serveur-fork n'est pas pratique.

Mais ce que je ne comprend pas c'est que tu me dis que les descripteurs ne sont pas partagés.

Dis moi si je me trompe mais un descripteur n'est qu'un entier ou y a-t'il un system autre qui est caché ?

Par exemple pour prendre un sujet qui me semble plus simple.

je crée un programme qui crée un shm et un fils. Le fils ouvre un fichier avec open et place l'entier dans le shm le père pourra-t'il lire ou ecrire sur le fichier ?

[Médinoc]

Non, il ne pourra.
Un descripteur est un index dans une table locale au processus.

C'est pour ça que chaque processus possède 0, 1 et 2 en entrée standard/sortie standard/sortie d'erreur, même si tu les ouvres dans trois terminaux/consoles différent(e)s...

Si tu retiriges la sortie standard pour un processus, ça ne change rien aux autres.


D'ailleurs, si les descripteurs étaient globaux, tu imagines le trou de sécurité ? N'importe quel process pourrait écrire sur n'importe quel fichier ouvert par n'importe quel autre, à moins de contrôler les droits à chaque accès au descripteur...

[cybersplash]

Donc pas de solution si ce n'est de réouvrir les socket dans chaque fils ?

[Médinoc]

Il n'existe pas d'équivalent au DuplicateHandle() interprocess sous unixoïde.

Tu ne peux donc pas "réouvrir" les sockets dans les fils, car ils ne seraient pas connectés.
Ce que tu peux essayer de faire, c'est :

• Faire la transmission en passant par le processus maître ou la mémoire partagée, pour dire "hé, tous les clients! envoyez ça!" (bonne chance pour t'assurer que personne ne modifie avant que tous les clients aient envoyé)
• Ou abandonner l'idée du serveur-fork : Tout faire dans le même processus, que ce soit par du multithread ou par l'utilisation de la fonction select() (que je recommande).

[cybersplash]

Merci pour la réponse je pense faire du multithread ce sera la maniere la plus facile a mettre en place vu le code déjà produit.