je cherche a réaliser une série d'échanges entre un client et un serveur,
seulement j'ai quelques doutes quant a la méthode a employer...
voici ce que je voudrai faire :
d'un coté le serveur qui exécute une série de tâches les unes après les
autres, de l'autre coté le client qui doit afficher la progression du
travail du serveur, a l'utilisateur.
pour ce faire, je propose d'afficher une progress bar qui avancerai d'un
cran dès que le serveur a fini une tâche et ainsi de suite, jusqu'à la fin
du travail.
le problème est que je ne vois pas comment établir cet échange entre mes
deux appli.
le serveur doit envoyer un message au client a chq fin de tâche ok, mais je
me pose des questions quant a la vitesse d'executions de ses taches...
coté serveur :
pour i allant de 0 a n
{
tache[i];
envoyer_signal();
}
côté client ...???
je vois pas trop quoi mettre pour la reception, il y aura n réceptions, mais
je peux pas mettre n recv dans une boucle de 0 a n... vu que si d'un côté
j'ai une machine super rapide et de l'autre une daube... y'aura un problème
de synchro... ou bien est-ce que la boucle passe a l'itération suivante que
lorsque le signal est bien reçu ??
voici ce que je propose, naïvement :
pour i allant de 0 à n
{
while(control<=0)
{
control=revc(...);
avancer_progress();
};
}
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
François Müller
Bonjour
"Nicolas aunai" @free.fr> wrote in message news:3f1d1166$0$1366$ | je cherche a réaliser une série d'échanges entre un client et un serveur, | seulement j'ai quelques doutes quant a la méthode a employer... | | voici ce que je voudrai faire : | d'un coté le serveur qui exécute une série de tâches les unes après les | autres, de l'autre coté le client qui doit afficher la progression du | travail du serveur, a l'utilisateur.
Pour ce genre d'appli, où la communication peut être non bloquante, un pipe nommé convient biens. Accessoirement dans votre description ("afichage de la progression") c'est le client qui est serveur.
Si votre comm doit être synchrone voir plutôt avec le RPC
F.
Bonjour
"Nicolas aunai" <nicolas.aunai@nospam@free.fr> wrote in message
news:3f1d1166$0$1366$626a54ce@news.free.fr...
| je cherche a réaliser une série d'échanges entre un client et un serveur,
| seulement j'ai quelques doutes quant a la méthode a employer...
|
| voici ce que je voudrai faire :
| d'un coté le serveur qui exécute une série de tâches les unes après les
| autres, de l'autre coté le client qui doit afficher la progression du
| travail du serveur, a l'utilisateur.
Pour ce genre d'appli, où la communication peut être non bloquante, un pipe
nommé convient biens. Accessoirement dans votre description ("afichage de la
progression") c'est le client qui est serveur.
Si votre comm doit être synchrone voir plutôt avec le RPC
"Nicolas aunai" @free.fr> wrote in message news:3f1d1166$0$1366$ | je cherche a réaliser une série d'échanges entre un client et un serveur, | seulement j'ai quelques doutes quant a la méthode a employer... | | voici ce que je voudrai faire : | d'un coté le serveur qui exécute une série de tâches les unes après les | autres, de l'autre coté le client qui doit afficher la progression du | travail du serveur, a l'utilisateur.
Pour ce genre d'appli, où la communication peut être non bloquante, un pipe nommé convient biens. Accessoirement dans votre description ("afichage de la progression") c'est le client qui est serveur.
Si votre comm doit être synchrone voir plutôt avec le RPC
F.
Nicolas aunai
François Müller a écrit:
Pour ce genre d'appli, où la communication peut être non bloquante, un pipe nommé convient biens. Accessoirement dans votre description ("afichage de la progression") c'est le client qui est serveur.
Si votre comm doit être synchrone voir plutôt avec le RPC
hum... pas trop compris... je c pas ce qu'est un 'pipe nommé', et ne suis pas sûr de la signification du terme 'synchrone' pour une communication client/serveur.... :o)
Pour ce genre d'appli, où la communication peut être non bloquante,
un pipe nommé convient biens. Accessoirement dans votre description
("afichage de la progression") c'est le client qui est serveur.
Si votre comm doit être synchrone voir plutôt avec le RPC
hum... pas trop compris... je c pas ce qu'est un 'pipe nommé', et ne suis
pas sûr de la signification du terme 'synchrone' pour une communication
client/serveur.... :o)
Pour ce genre d'appli, où la communication peut être non bloquante, un pipe nommé convient biens. Accessoirement dans votre description ("afichage de la progression") c'est le client qui est serveur.
Si votre comm doit être synchrone voir plutôt avec le RPC
hum... pas trop compris... je c pas ce qu'est un 'pipe nommé', et ne suis pas sûr de la signification du terme 'synchrone' pour une communication client/serveur.... :o)
> hum... pas trop compris... je c pas ce qu'est un 'pipe nommé', et ne suis pas sûr de la signification du terme 'synchrone' pour une communication client/serveur.... :o)
Pourquoi ne pas chercher une définition alors ? pipe nommé == named pipe. Et comme pipe veut dire tuyau en anglais, je pense que tu devines à quoi ça sert...
Synchrone est l'antonyme d'asynchrone. Si tu comprends l'un tu comprends l'autre (les messages doivent être ou non envooyés les uns à la suite des autres)
> hum... pas trop compris... je c pas ce qu'est un 'pipe nommé', et ne suis
pas sûr de la signification du terme 'synchrone' pour une communication
client/serveur.... :o)
Pourquoi ne pas chercher une définition alors ? pipe nommé == named pipe.
Et comme pipe veut dire tuyau en anglais, je pense que tu devines à quoi ça
sert...
Synchrone est l'antonyme d'asynchrone. Si tu comprends l'un tu comprends
l'autre (les messages doivent être ou non envooyés les uns à la suite des
autres)
> hum... pas trop compris... je c pas ce qu'est un 'pipe nommé', et ne suis pas sûr de la signification du terme 'synchrone' pour une communication client/serveur.... :o)
Pourquoi ne pas chercher une définition alors ? pipe nommé == named pipe. Et comme pipe veut dire tuyau en anglais, je pense que tu devines à quoi ça sert...
Synchrone est l'antonyme d'asynchrone. Si tu comprends l'un tu comprends l'autre (les messages doivent être ou non envooyés les uns à la suite des autres)
