J´ai un devoir systeme a faire pour bientot en cour...
Si quelqu´un peut m´apporter ses idées et reflexion sur le probleme on n´importe quoi d´autre, ca serait simpa... (bonne connaissance des fonctions systemes Linux necessaires (en gros moins de 16 ans s´abstenir de dire des conneries...))

voici le sujet en super-resumé:
Bon on doit faire un serveur qui contient plein de fichier textes consultables par des clients.
Les client peuvent non seulement (apres s´etre connetés au serveur bien sur) lire, ou modifier les fichier (ajout , suppression)

Ce que je pense faire :
Le serveur doit etre divisé en 2 parti (par un fork() ) :
la premiere gere les problemes de priorité producteur consomateur (par exemple si un client li, et bien personne peut ecrire, par contre si qql veux lire, pas de blem... --> sauf que , si y a toujours des lecteur, personne pourra jamais ecrire... Bref je sais pas trop comment gerer ca : ) )

puis il envoit les ordres qu´il a recu des client au serveur secondaire qui les traitent...

les 2 parties communicant par un pitit PIPE annonyme...

Le premier serveur gerant un nombre maxi de client grace a des semaphores...

Si qql sais comment resoudre le probleme des priorités avec de transmettre au second serveur bin c´est cool, il peut m´aider : )
Si vous avez pas tout compris et bin demandez moi : )
Merci

Pour ton probleme de fichiers partages (lecture/ecriture),

quand le fichier est lu, il est bloque en ecriture. si une demande decriture est faite tu duplique le fichier et tu aiguilles tes ecritures sur ce fichier. Quand le lecteur a fini son vieux fichier tu le delete ()si tu deuxieme fichier est libre en lecture.

PB : bah, c pas tres economique en resource tout ca : )

J´ai pas tout bien compris....

Pour moi il n´y a que 2 acteur presents:
Client
Serveur

Je ne vois pas pourquoi tu split ton serveur en 2.
Cela a mon avis va complexifier ton programme . ..

Mais :

Il me semble que tu peux avoir plusieurs clients en lecture et ( pour simplifier ) 1 seul en ecriture.
Pour ceux qui travauillent en lecture c´est trivial.
Pour celui ( unique pour simplifier toujours ) qui travail en ecriture, tu lui refile une copie du fichier a travailler. Une fois ces modification terminée il valide ou non ses modifications. Tu peux alors prevenir les lecteurs que des modifs ont ete faites sur le fichier qu´ils visualisent. A leur charge de vouloir re-loader le fichier ou non.

Ceci m´ammene a une conclusion:
Tu dois connaitre pour chaque fichier :
Qui fait de la lecture.
Y a il un acces en ecriture.

Si l´on veut compliquer un peut plus l´affaire :
Plusieur ecriture en meme temps !
La il faut absolument versionner les fichier.
Chaque fichier pris en ecriture doit etre relaché avec un numero de version superieur.
Si le meme fichier a ete pris 2 fois en ecriture : tu sers au 2 le meme fichier. Lors de la relache de fichier il faut alors signaler qu´il y a 2 instances du meme fichier. Tu doit conserver ces 2 fichiers modifiés en parrallele et proposer a tes utilisateur de faire un "merge" de ces 2 instances de fichiers pour revenir sur un fichier unique ! ( Tu peux tenter d´automatiser l´affaire mais c´est souvent tres delicat et une intervention humaine est neccessaire).

La methode de comunication entre le client et le serveur :
Tu a choisi des pipe OK, mais personnelement je prendrais une solution a base de socket pasque comme cela, ton serveur peux etre sur une machine et ton client sur une autre !

Bin c´est dans l´ennoncé qu´il nous demande de diviser en 2 partie : )
mais j´ai depuis resolu pas mal de probleme : )
Pour les Pipes, il n´etait bien sur pas question de les mettre entre les client et le serveur mais entre les 2 parti du serveur : )
On doit pas se servir des sockets vu que c´est pas un tp reseau : )
donc les clients seront sur le meme poste... c´est moins bien c´est clair...
Merci encore : )