Discussion :

[shamsi]

Bonjour à tous,

Après mettre arraché les cheveux pendant quelques heures sur mon programme client/serveur, je viens de m'apercevoir que lors d'un fork() la file descriptor table (FDT) est dupliquée !

Je vous explique un peu le synoptique de mon programme.
En fait dans le processus courant je fais un accept (qui me renvoi un file descriptor (FD) d'un socket d'un client) et après je fais un fork() pour dédié un nouveau processus au client qui vient de se connecter ! Jusque la tout va bien puisque le processus dédié à une copie de la FDT du père et connait donc le FD du socket de son client.
Mais lorsqu'un second client se connecte le même procédé et appliqué et alors le client 2 connait le FD du client 1 (l'entréé dans sa FDT est valide) par contre le client 1 n'a aucune connaissance du FD du client 2...

Je ne doit absolument pas utiliser de Thread (pour un tas de raisons) sinon la tache aurait été simplifiée !

Je ne peux pas partager uniquement l'entier qui represente le numéro de l'entrée dans la FDT puisque qu'il faut qu'il soit vraiment ouvert !

Comment pourrais-je partager la FDT du père avec ses enfants ?

Merci encore

PS : j'espère que j'ai été assez clair... Sinon dites le moi je ferais une autre tentative d'explication. ;-)

[Médinoc]

Tu ne peux, il n'y a rien sous un système unixoïde pour dupliquer un descripteur d'un processus à l'autre.
Une fois les processus séparés, ils sont séparés, point.

Ce que tu peux tenter, c'est de communiquer les données à transmettre d'un processus à l'autre. Mais pas les descripteurs.

[Desboys]

Bonjour,
est-il nécessaire qu'un processus "servant" un client connaissent l'ensemble des autres sessions/sockets des autres clients? Si oui, alors fork() n'est pas la solution. Vous pouvez toutefois utiliser les sockets du domaine Unix pour transférer des descripteurs de fichiers entre processus, mais la mise en oeuvre n'est pas des plus aisées.

En théorie, j'ai l'habitude de fermer les descripteurs non-utiles après un fork(). Ainsi le daemon ferme les sockets clientes après le fork(), et le fils ferme la socket du père.
Ainsi le daemon se contente d'accepter et de fournir un processus dédié pour gérer ses clients, tandis que chaque nouveau processus "fils" va alors "servir" le client.

Cordialement,
S. Desbois

[Médinoc]

Le problème, c'est qu'il s'agit là d'un serveur où les clients communiquent entre eux (typiquement un chat).

C'est le genre de programme où le serveur-fork() est hautement inapproprié en effet, mais le P.O. ne peut pas utiliser le multithreading.

Par contre, shamsi, es-tu autorisé à utiliser la fonction select() ? Ainsi, tu aurais un bon serveur de chat monoprocessus et monotâche, qui ferait tranquillement ce qu'on lui demande...

[shamsi]

Bonjour et merci à tous,

J'ai vu quelques amis a moi aujourd'hui qui m'ont dit la même chose...
Je pense que je vais essayer de mettre en oeuvre la fonction select !
Aurez-vous de plus amples informations ???

Je ne l'ai pas vu dans le cours, mais bon sinon il n'y a pas d'autre choix !

Merci

[inh40]

Je dépoussière un peu ce message, pour obtenir quelques infos.
En fait, moi mon problème est un peu l'inverse de celui ci. Je voudrais que le fils ferme toutes les sockets qu'il a hérité du père.

Comment faire pour connaître cette liste de sockets, et les fermer ?

Merci !

[Médinoc]

Je dirais mémoriser la liste avant le fork dans une structure de données, et tout effacer après le fork() côté fils...