Discussion :

[aragog]

Bonsoir.

Je travaille actuellement sur un projet de codage du protocole TFTP.
Le but du jeu ici étant d'autoriser les lectures/écritures sur un hôte distant depuis un client.

Que se passe-t-il quand deux clients veulent lire le même fichier ? Rien. Maintenant et j'en arrive à ma question, que se passe-t-il quand deux clients veulent accéder (concurremment forcément) à un fichier dont l'un en écriture ? Si on a de la chance rien, mais on sent déjà qu'on est mal parti avec ce genre de réponse.

Par conséquent, y aurait-il un moyen astucieux de tester si un fichier est déjà ouvert ? Je ne viens pas ici, bien sûr, les mains vides, et ai déjà fais des recherches mais rien de bien convaincant.

Cependant, je possède bien une idée : stocker les fichiers ouverts dans une table, en synchronisant les accès.

Malheureusement c'est lourd, et si la synchro est mal faite, je ne fais que rajouter de la complexité à la complexité.

Pour conclure, pourriez-vous m'apporter quelques éléments de réponse s.v.p ? Merci d'avance.

[Neckara]

Bonjour,

Il te suffit de créer un fichier temporaire où tu effectueras les écriture pour un client puis, une fois l'écriture terminée, tu renommes le fichier original ( monFichier.back par exemple) et tu renomme ton fichier "temporaire" avec le nom du fichier original (monFichier.txt par exemple).

Ainsi si tu as besoin de récupérer l'ancien fichier pour X raisons en cas de problèmes, tu pourras

[Bktero]

Si A fait son fichier temporaire, que B fait son fichier temporaire, que A fait sa copie, que B fait sa copie, alors B a gagné et A a perdu ?

[Metalman]

En même temps... TFTP... pas sûr que le protocole assure une quelconque gestion de la concurrence en écriture de fichiers...
Ca doit être le genre de trucs "dépendant de l'implémentation".

[gangsoleil]

Bonjour,

Il n'existe pas de regle unique pour les ouvertures multiples de fichier.

Sur Unix/Linux, la regle est que c'est le dernier qui ecrit qui gagne.

Sur Windows, il en est de meme.

Apres, rien n'empeche l'editeur du document de faire des verifications, mais cela suppose un unique endroit pour tous les locks, ce qui n'est pas forcement facile a trouver.

[Neckara]

Si A fait son fichier temporaire, que B fait son fichier temporaire, que A fait sa copie, que B fait sa copie, alors B a gagné et A a perdu ?

On ne copie pas, on renomme, c'est bien plus rapide.

Comme on conserve les anciennes versions (après, on peut déterminer un nombre maximum de version, un temps de conservation, ...), A peut toujours récupérer son ancienne version et reproposer sa propre version.

Après, que voudrais-tu faire dans ce cas-là?
Même si on boque les écritures concurrantes, un utilisateurs peut toujours préparer sa propre version et la soumettre dès qu'il a le droit d'écrire, le resultat sera le même.
Après il faut un gestionnaire de version, pas un FTP.

[kwariz]

Bonjour,

si tu veux implémenter un serveur tftp c'est pas si compliqué que ça, enfin tu gères le niveau de complication que tu désires.
Tes clients envoient soit une demande le lecture soit une demande d'écriture. Tu dois de toute façon garder une liste d'opérations en cours et donc tu sais si une demande particulière peu ou non être satisfaite. Si tu ne peux la satisfaire tu envoies un message d'erreur.
Ensuite c'est toi qui vois comment gérer ça. Imagine que deux clients sont en train de lire un fichier, puis un troisième client demande d'écrire ce même fichier.
On peut imaginer que :
* soit tu envoies une erreur (error code 2 = access violation ???) à celui qui veut écrire tant qu'il y a des lecteurs -> gestion simplifiée
* soit tu écris le fichier dans un endroit temporaire en attendant qu'il n'y ait plus de lecteurs puis tu écrases le fichier d'origine en refusant tout nouvel accès en lecture ou écriture tant que l'écriture n'est pas terminée -> gestion plus complexe

[Bktero]

Je ne sais pas que ce que je voudrais faire justement......

J'ai dit "copie" pour schématiser

Je pose simplement la question de l'accès concurrent. Je pense qu'il y a une différence entre dire : "le dernier qui écrit a gagné en sachant qu'il écrase les modifications de quelqu'un d'autre" et "le dernier qui écrit a gagné sans rien savoir". Mais je crois que Metalman puis kwariz donnent la réponse : c'est au choix de l'implémentation si le protocole ne spécifie pas ce point.

@gangsoleil : sous Windows, tu peux écrire un fichier alors que quelqu'un l'a déjà ouvert en écriture ? Il me semblait que non justement :s

[Médinoc]

^L'implémentation par défaut de fopen() sous Windows ouvre sans aucune protection; la version fopen_s() pose un verrou lecteurs/écrivain sur le fichier.

[Bktero]

Merci pour cette précision !

[aragog]

Bonjour,

merci pour toutes ces réponses, c'est vraiment intéressant.

Je pense que la solution de Kwariz est la plus abordable (en prenant pour le moment, le cas trivial).
Sinon en effet la RFC ne donne pas plus d'explications que ça sur ce sujet (et sur pas mal d'autres au passage, mais qu'importe).

Merci encore à tous, je vous tiens au courant.

[gangsoleil]

@gangsoleil : sous Windows, tu peux écrire un fichier alors que quelqu'un l'a déjà ouvert en écriture. Il me semblait que non justement :s

Oui, j'ai fait le texte avec notepad ou wordpad, je ne sais plus : le dernier qui ecrit a raison.
Par contre, avec deux instances de gvim, l'editeur te previent que ce meme fichier est deja ouvert.

[aragog]

J'ai finalement opté pour une table de hachage.
Les accès à la table sont synchronisés à l'aide d'un sémaphore et pour chaque nom de fichier, je retiens s'il est ouvert en lecture ou en écriture. Après chaque requête, on enlève le fichier de la table.

Au final, si le fichier est ouvert en lecture et que la requête est un paquet de demande en lecture, ok, sinon, envoie d'une erreur (ACCESS_DENIED).
Sinon si le fichier est ouvert en écriture, on ne peut rien garantir ainsi il y a envoi systématique d'une erreur (toujours la même).

Voilà, je dois avouer que l'idée des fichiers temporaires me plaît assez alors je vais voir si c'est applicable sans trop de complications.

[aragog]

Me suis rabattu sur des threads avec un pthread_mutex_t pour la synchronisation.

Encore merci pour toutes vos idées, c'était vraiment intéressant.

Bonne journée.