j'ai un projet à faire en C. Le but est de créer un jeu de voiture
multi-joueurs asynchrone. Voici en gros le principe:
- Un programme maitre crée un tube nommé.
- Plusieurs autres programmes (les joueurs) communiquent avec le mettre
par le biais de ce tube nommé.
- Ces programmes envoie les positions de leur voiture respective au
programme maitre.
On me demande dans les points à respecter dans le projet de * garantir
l'atomicité des écritures dans le tube maitre * et voilà je ne
comprends pas trop ce point et donc aucune idée pour implémenter ceci.
Si quelqu'un pouvait m'éclairer sur ce point !
Merci d'avance.
(le sujet du projet se trouve ici pour plus de détails
http://mat.free.free.fr/sujet.pdf )
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
David LE BOURGEOIS
Bonjour,
Bonsoir.
On me demande dans les points à respecter dans le projet de * garantir l'atomicité des écritures dans le tube maitre * et voilà je ne comprends pas trop ce point et donc aucune idée pour implémenter ceci.
Si quelqu'un pouvait m'éclairer sur ce point !
Grossièrement, durant une procédure atomique, il est impossible d'interrompre son déroulement afin d'exécuter d'autres instructions que celles contenu dans la-dite procédure. Par exemple, l'atomicité des appels systèmes sur certains périphériques garanti leur fonctionnement.
Donc, dans le cas présent, si un client écrit dans le tube maître, aucun nouveau client (y compris le premier) ne doit pouvoir écrire pendant la première opération. Utilisation d'un verrou ?
Merci d'avance.
De rien, et bon courage pour la réalisation.
-- David LE BOURGEOIS
Bonjour,
Bonsoir.
On me demande dans les points à respecter dans le projet de * garantir
l'atomicité des écritures dans le tube maitre * et voilà je ne comprends
pas trop ce point et donc aucune idée pour implémenter ceci.
Si quelqu'un pouvait m'éclairer sur ce point !
Grossièrement, durant une procédure atomique, il est impossible
d'interrompre son déroulement afin d'exécuter d'autres instructions que
celles contenu dans la-dite procédure.
Par exemple, l'atomicité des appels systèmes sur certains périphériques
garanti leur fonctionnement.
Donc, dans le cas présent, si un client écrit dans le tube maître,
aucun nouveau client (y compris le premier) ne doit pouvoir écrire
pendant la première opération.
Utilisation d'un verrou ?
On me demande dans les points à respecter dans le projet de * garantir l'atomicité des écritures dans le tube maitre * et voilà je ne comprends pas trop ce point et donc aucune idée pour implémenter ceci.
Si quelqu'un pouvait m'éclairer sur ce point !
Grossièrement, durant une procédure atomique, il est impossible d'interrompre son déroulement afin d'exécuter d'autres instructions que celles contenu dans la-dite procédure. Par exemple, l'atomicité des appels systèmes sur certains périphériques garanti leur fonctionnement.
Donc, dans le cas présent, si un client écrit dans le tube maître, aucun nouveau client (y compris le premier) ne doit pouvoir écrire pendant la première opération. Utilisation d'un verrou ?
Merci d'avance.
De rien, et bon courage pour la réalisation.
-- David LE BOURGEOIS
Laurent Wacrenier
David LE BOURGEOIS écrit:
Donc, dans le cas présent, si un client écrit dans le tube maître, aucun nouveau client (y compris le premier) ne doit pouvoir écrire pendant la première opération. Utilisation d'un verrou ?
Si les données à écrire font moins de PIPE_BUF octets, l'écriture est atomique (PIPE_BUF vaut au moins _POSIX_PIPE_BUF = 512 octets)
Il suffit de concevoir le protocole pour que les données fassent moins de 512 octets pour que le programme fonctionne sur tous les systèmes POSIX.
David LE BOURGEOIS <david.lebourgeois-nospam@free.fr> écrit:
Donc, dans le cas présent, si un client écrit dans le tube maître,
aucun nouveau client (y compris le premier) ne doit pouvoir écrire
pendant la première opération.
Utilisation d'un verrou ?
Si les données à écrire font moins de PIPE_BUF octets, l'écriture est
atomique (PIPE_BUF vaut au moins _POSIX_PIPE_BUF = 512 octets)
Il suffit de concevoir le protocole pour que les données fassent moins
de 512 octets pour que le programme fonctionne sur tous les systèmes
POSIX.
Donc, dans le cas présent, si un client écrit dans le tube maître, aucun nouveau client (y compris le premier) ne doit pouvoir écrire pendant la première opération. Utilisation d'un verrou ?
Si les données à écrire font moins de PIPE_BUF octets, l'écriture est atomique (PIPE_BUF vaut au moins _POSIX_PIPE_BUF = 512 octets)
Il suffit de concevoir le protocole pour que les données fassent moins de 512 octets pour que le programme fonctionne sur tous les systèmes POSIX.
Erwann ABALEA
Bonsoir,
On Thu, 8 Jan 2004, David LE BOURGEOIS wrote:
On me demande dans les points à respecter dans le projet de * garantir l'atomicité des écritures dans le tube maitre * et voilà je ne comprends pas trop ce point et donc aucune idée pour implémenter ceci.
Si quelqu'un pouvait m'éclairer sur ce point !
Grossièrement, durant une procédure atomique, il est impossible d'interrompre son déroulement afin d'exécuter d'autres instructions que celles contenu dans la-dite procédure. Par exemple, l'atomicité des appels systèmes sur certains périphériques garanti leur fonctionnement.
Stricto sensu, j'aurais ajouté une autre contrainte pour garantir l'atomicité: garantir que l'écriture d'est entièrement déroulée ou pas du tout. Mais c'est un poil plus difficile (on ne peut pas savoir quelle place reste libre dans le buffer noyau du tube nommé, si celui-ci n'est pas lu aussi vite de l'autre côté).
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- Existe-t-il un numéro vert oû ceux qui débuttent sur les forums du web peuvent poser des questions ? Ce forum de conseils est très bien, mais il serait bon de pouvoir discuter de vive voix avec des conaisseurs. -+-Le Guide du Neuneu d'Usenet: Le club des connaisseurs de neuneux -+-
Bonsoir,
On Thu, 8 Jan 2004, David LE BOURGEOIS wrote:
On me demande dans les points à respecter dans le projet de * garantir
l'atomicité des écritures dans le tube maitre * et voilà je ne comprends
pas trop ce point et donc aucune idée pour implémenter ceci.
Si quelqu'un pouvait m'éclairer sur ce point !
Grossièrement, durant une procédure atomique, il est impossible
d'interrompre son déroulement afin d'exécuter d'autres instructions que
celles contenu dans la-dite procédure.
Par exemple, l'atomicité des appels systèmes sur certains périphériques
garanti leur fonctionnement.
Stricto sensu, j'aurais ajouté une autre contrainte pour garantir
l'atomicité: garantir que l'écriture d'est entièrement déroulée ou pas du
tout. Mais c'est un poil plus difficile (on ne peut pas savoir quelle
place reste libre dans le buffer noyau du tube nommé, si celui-ci n'est
pas lu aussi vite de l'autre côté).
--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
Existe-t-il un numéro vert oû ceux qui débuttent sur les forums du web
peuvent poser des questions ? Ce forum de conseils est très bien, mais
il serait bon de pouvoir discuter de vive voix avec des conaisseurs.
-+-Le Guide du Neuneu d'Usenet: Le club des connaisseurs de neuneux -+-
On me demande dans les points à respecter dans le projet de * garantir l'atomicité des écritures dans le tube maitre * et voilà je ne comprends pas trop ce point et donc aucune idée pour implémenter ceci.
Si quelqu'un pouvait m'éclairer sur ce point !
Grossièrement, durant une procédure atomique, il est impossible d'interrompre son déroulement afin d'exécuter d'autres instructions que celles contenu dans la-dite procédure. Par exemple, l'atomicité des appels systèmes sur certains périphériques garanti leur fonctionnement.
Stricto sensu, j'aurais ajouté une autre contrainte pour garantir l'atomicité: garantir que l'écriture d'est entièrement déroulée ou pas du tout. Mais c'est un poil plus difficile (on ne peut pas savoir quelle place reste libre dans le buffer noyau du tube nommé, si celui-ci n'est pas lu aussi vite de l'autre côté).
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- Existe-t-il un numéro vert oû ceux qui débuttent sur les forums du web peuvent poser des questions ? Ce forum de conseils est très bien, mais il serait bon de pouvoir discuter de vive voix avec des conaisseurs. -+-Le Guide du Neuneu d'Usenet: Le club des connaisseurs de neuneux -+-
Mat Free
Stricto sensu, j'aurais ajouté une autre contrainte pour garantir l'atomicité: garantir que l'écriture d'est entièrement déroulée ou pas du tout. Mais c'est un poil plus difficile (on ne peut pas savoir quelle place reste libre dans le buffer noyau du tube nommé, si celui-ci n'est pas lu aussi vite de l'autre côté).
Si j'ai bien compris toutes les documentations que j'ai lues, ceci n'est pas un problème car lors d'une écriture avec write (l'écriture étant bloquante), la fonction write ne retourne une valeur que quand les n caractères à ecrire ont été ecris dans le tube.
De plus, le protocole étant concus pour que tous les paquets envoyés soient de la meme taille, il de devrait pas y avoir de risque qu'un consommateur lise une partie des données ecrite par le write.
Enfin c'est ce que je crois avoir compris.
Vous confirmez ?
Merci pour vos réponses
Stricto sensu, j'aurais ajouté une autre contrainte pour garantir
l'atomicité: garantir que l'écriture d'est entièrement déroulée ou pas du
tout. Mais c'est un poil plus difficile (on ne peut pas savoir quelle
place reste libre dans le buffer noyau du tube nommé, si celui-ci n'est
pas lu aussi vite de l'autre côté).
Si j'ai bien compris toutes les documentations que j'ai lues, ceci
n'est pas un problème car lors d'une écriture avec write (l'écriture
étant bloquante), la fonction write ne retourne une valeur que quand
les n caractères à ecrire ont été ecris dans le tube.
De plus, le protocole étant concus pour que tous les paquets envoyés
soient de la meme taille, il de devrait pas y avoir de risque qu'un
consommateur lise une partie des données ecrite par le write.
Stricto sensu, j'aurais ajouté une autre contrainte pour garantir l'atomicité: garantir que l'écriture d'est entièrement déroulée ou pas du tout. Mais c'est un poil plus difficile (on ne peut pas savoir quelle place reste libre dans le buffer noyau du tube nommé, si celui-ci n'est pas lu aussi vite de l'autre côté).
Si j'ai bien compris toutes les documentations que j'ai lues, ceci n'est pas un problème car lors d'une écriture avec write (l'écriture étant bloquante), la fonction write ne retourne une valeur que quand les n caractères à ecrire ont été ecris dans le tube.
De plus, le protocole étant concus pour que tous les paquets envoyés soient de la meme taille, il de devrait pas y avoir de risque qu'un consommateur lise une partie des données ecrite par le write.
Enfin c'est ce que je crois avoir compris.
Vous confirmez ?
Merci pour vos réponses
Erwann ABALEA
On Mon, 12 Jan 2004, Mat Free wrote:
Stricto sensu, j'aurais ajouté une autre contrainte pour garantir l'atomicité: garantir que l'écriture d'est entièrement déroulée ou pas du tout. Mais c'est un poil plus difficile (on ne peut pas savoir quelle place reste libre dans le buffer noyau du tube nommé, si celui-ci n'est pas lu aussi vite de l'autre côté).
Si j'ai bien compris toutes les documentations que j'ai lues, ceci n'est pas un problème car lors d'une écriture avec write (l'écriture étant bloquante), la fonction write ne retourne une valeur que quand les n caractères à ecrire ont été ecris dans le tube.
Oui si: - l'écriture est bien bloquante (ou si on gère correctement les valeurs de errno) - on écrit tout en une seule fois, et pas par petits bouts
De plus, le protocole étant concus pour que tous les paquets envoyés soient de la meme taille, il de devrait pas y avoir de risque qu'un consommateur lise une partie des données ecrite par le write.
Si, si le consommateur ne tente pas de lire la même quantité. Il peut décider de lire par petits bouts.
Mais ça donne déjà quelques pistes à l'OP pour faire son exercice.
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- E> desole mais je n est pas trop l habitude des groupes de discutions Leçon n° 1 : on répond en haut et on vire le message auquel on répond Cette suppression facilite grandement la lecture !!! -+- DrN in <http://neuneu.mine.nu> : Le Neuneu par l'exemple -+-
On Mon, 12 Jan 2004, Mat Free wrote:
Stricto sensu, j'aurais ajouté une autre contrainte pour garantir
l'atomicité: garantir que l'écriture d'est entièrement déroulée ou pas du
tout. Mais c'est un poil plus difficile (on ne peut pas savoir quelle
place reste libre dans le buffer noyau du tube nommé, si celui-ci n'est
pas lu aussi vite de l'autre côté).
Si j'ai bien compris toutes les documentations que j'ai lues, ceci
n'est pas un problème car lors d'une écriture avec write (l'écriture
étant bloquante), la fonction write ne retourne une valeur que quand
les n caractères à ecrire ont été ecris dans le tube.
Oui si:
- l'écriture est bien bloquante (ou si on gère correctement les valeurs
de errno)
- on écrit tout en une seule fois, et pas par petits bouts
De plus, le protocole étant concus pour que tous les paquets envoyés
soient de la meme taille, il de devrait pas y avoir de risque qu'un
consommateur lise une partie des données ecrite par le write.
Si, si le consommateur ne tente pas de lire la même quantité. Il peut
décider de lire par petits bouts.
Mais ça donne déjà quelques pistes à l'OP pour faire son exercice.
--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
E> desole mais je n est pas trop l habitude des groupes de discutions
Leçon n° 1 : on répond en haut et on vire le message auquel on répond
Cette suppression facilite grandement la lecture !!!
-+- DrN in <http://neuneu.mine.nu> : Le Neuneu par l'exemple -+-
Stricto sensu, j'aurais ajouté une autre contrainte pour garantir l'atomicité: garantir que l'écriture d'est entièrement déroulée ou pas du tout. Mais c'est un poil plus difficile (on ne peut pas savoir quelle place reste libre dans le buffer noyau du tube nommé, si celui-ci n'est pas lu aussi vite de l'autre côté).
Si j'ai bien compris toutes les documentations que j'ai lues, ceci n'est pas un problème car lors d'une écriture avec write (l'écriture étant bloquante), la fonction write ne retourne une valeur que quand les n caractères à ecrire ont été ecris dans le tube.
Oui si: - l'écriture est bien bloquante (ou si on gère correctement les valeurs de errno) - on écrit tout en une seule fois, et pas par petits bouts
De plus, le protocole étant concus pour que tous les paquets envoyés soient de la meme taille, il de devrait pas y avoir de risque qu'un consommateur lise une partie des données ecrite par le write.
Si, si le consommateur ne tente pas de lire la même quantité. Il peut décider de lire par petits bouts.
Mais ça donne déjà quelques pistes à l'OP pour faire son exercice.
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- E> desole mais je n est pas trop l habitude des groupes de discutions Leçon n° 1 : on répond en haut et on vire le message auquel on répond Cette suppression facilite grandement la lecture !!! -+- DrN in <http://neuneu.mine.nu> : Le Neuneu par l'exemple -+-
