programation et principe sur socket et queue de messages IPC
3 réponses
projlin
Bonjour,
Dans le cadre d'un projet client serveur, j'utilise les queues de
message (IPC).
Je voudrais faire un portage sur le syst=E8me des socket...
Mes interrogations et blocages sont les suivant.
Dans mon projet actuel j'ai 2 queues de messages.
1) Queue de commande :
Pleins de clients envois des commandes au serveur.
Des processus clients =E9crivent dans la queue de commande, et seul le
serveur fait la lecture
2) Queue de retour - r=E9veil :
Seul le serveur =E9crit dans cette queue de message.
Pleins de clients se mette en attente de leur r=E9ponses.
L'avantage est que je n'aie que 2 queues de messages.
La premi=E8re je re=E7ois des commandes.
La secondes, j'envoi une info au client pour le r=E9veiller.
Petite pr=E9cision IMPORTANTE.
Les clients sont nombreux, et mobile...
Je m'explique un client, souvent se forke se met en sommeil et fait
bosser sont fils.
Puis le fils moeurs, le p=E8re r=E9cup=E8re la main, travaille a nouveau
et peut recommencer le coup du fork.
Donc si chacun des fils du fils, doit ouvrir =E0 chaque fois un nouveaux
socket cela risque d'=EAtre lourd,
Voir m=EAme non fonctionnel car parfois j'ai le fonctionnement suivant
:
Le client fork et sont fils travailles, puis envois une commande au
serveur par la queue de commande.
Puis le fils m=9Curs, le p=E8re r=E9cup=E8re la main, et ... attend la
r=E9ponse du serveur sur la queue de retour.
Donc il faut que tous les processus utilisent le m=EAme canal...
Des id=E9es ?
Merci a tous. Si par malheur je ne suis pas dans le bon groupe, merci
de m'indiquer le plus appropri=E9s.
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
Pascal Bourguignon
writes:
Bonjour,
Dans le cadre d'un projet client serveur, j'utilise les queues de message (IPC). Je voudrais faire un portage sur le système des socket...
Mes interrogations et blocages sont les suivant.
Dans mon projet actuel j'ai 2 queues de messages.
1) Queue de commande : Pleins de clients envois des commandes au serveur. Des processus clients écrivent dans la queue de commande, et seul le serveur fait la lecture
2) Queue de retour - réveil : Seul le serveur écrit dans cette queue de message. Pleins de clients se mette en attente de leur réponses.
L'avantage est que je n'aie que 2 queues de messages. La première je reçois des commandes. La secondes, j'envoi une info au client pour le réveiller.
Petite précision IMPORTANTE. Les clients sont nombreux, et mobile... Je m'explique un client, souvent se forke se met en sommeil et fait bosser sont fils. Puis le fils moeurs, le père récupère la main, travaille a nouveau et peut recommencer le coup du fork.
Donc si chacun des fils du fils, doit ouvrir à chaque fois un nouveaux socket cela risque d'être lourd, Voir même non fonctionnel car parfois j'ai le fonctionnement suivant :
Le client fork et sont fils travailles, puis envois une commande au serveur par la queue de commande. Puis le fils murs, le père récupère la main, et ... attend la réponse du serveur sur la queue de retour.
Donc il faut que tous les processus utilisent le même canal...
Les sockets seront point-à-point, mais les file-descripteurs sont partagés entre un père et un fils après un fork, s'il sont créés avant le fork par le père.
De plus, des processus peuvent se "faire suivre" un file descriptor sur un certain nombre de système unix (ce n'est pas un API POSIX, mais un ioctl spécifique). Mais d'après ta description, ce ne sera même pas utile.
"Indentation! -- I will show you how to indent when I indent your skull!"
projlin@hotmail.com writes:
Bonjour,
Dans le cadre d'un projet client serveur, j'utilise les queues de
message (IPC).
Je voudrais faire un portage sur le système des socket...
Mes interrogations et blocages sont les suivant.
Dans mon projet actuel j'ai 2 queues de messages.
1) Queue de commande :
Pleins de clients envois des commandes au serveur.
Des processus clients écrivent dans la queue de commande, et seul le
serveur fait la lecture
2) Queue de retour - réveil :
Seul le serveur écrit dans cette queue de message.
Pleins de clients se mette en attente de leur réponses.
L'avantage est que je n'aie que 2 queues de messages.
La première je reçois des commandes.
La secondes, j'envoi une info au client pour le réveiller.
Petite précision IMPORTANTE.
Les clients sont nombreux, et mobile...
Je m'explique un client, souvent se forke se met en sommeil et fait
bosser sont fils.
Puis le fils moeurs, le père récupère la main, travaille a nouveau
et peut recommencer le coup du fork.
Donc si chacun des fils du fils, doit ouvrir à chaque fois un nouveaux
socket cela risque d'être lourd,
Voir même non fonctionnel car parfois j'ai le fonctionnement suivant
:
Le client fork et sont fils travailles, puis envois une commande au
serveur par la queue de commande.
Puis le fils murs, le père récupère la main, et ... attend la
réponse du serveur sur la queue de retour.
Donc il faut que tous les processus utilisent le même canal...
Les sockets seront point-à-point, mais les file-descripteurs sont
partagés entre un père et un fils après un fork, s'il sont créés avant
le fork par le père.
De plus, des processus peuvent se "faire suivre" un file descriptor
sur un certain nombre de système unix (ce n'est pas un API POSIX, mais
un ioctl spécifique). Mais d'après ta description, ce ne sera même
pas utile.
Dans le cadre d'un projet client serveur, j'utilise les queues de message (IPC). Je voudrais faire un portage sur le système des socket...
Mes interrogations et blocages sont les suivant.
Dans mon projet actuel j'ai 2 queues de messages.
1) Queue de commande : Pleins de clients envois des commandes au serveur. Des processus clients écrivent dans la queue de commande, et seul le serveur fait la lecture
2) Queue de retour - réveil : Seul le serveur écrit dans cette queue de message. Pleins de clients se mette en attente de leur réponses.
L'avantage est que je n'aie que 2 queues de messages. La première je reçois des commandes. La secondes, j'envoi une info au client pour le réveiller.
Petite précision IMPORTANTE. Les clients sont nombreux, et mobile... Je m'explique un client, souvent se forke se met en sommeil et fait bosser sont fils. Puis le fils moeurs, le père récupère la main, travaille a nouveau et peut recommencer le coup du fork.
Donc si chacun des fils du fils, doit ouvrir à chaque fois un nouveaux socket cela risque d'être lourd, Voir même non fonctionnel car parfois j'ai le fonctionnement suivant :
Le client fork et sont fils travailles, puis envois une commande au serveur par la queue de commande. Puis le fils murs, le père récupère la main, et ... attend la réponse du serveur sur la queue de retour.
Donc il faut que tous les processus utilisent le même canal...
Les sockets seront point-à-point, mais les file-descripteurs sont partagés entre un père et un fils après un fork, s'il sont créés avant le fork par le père.
De plus, des processus peuvent se "faire suivre" un file descriptor sur un certain nombre de système unix (ce n'est pas un API POSIX, mais un ioctl spécifique). Mais d'après ta description, ce ne sera même pas utile.
"Indentation! -- I will show you how to indent when I indent your skull!"
Nicolas George
Pascal Bourguignon wrote in message :
De plus, des processus peuvent se "faire suivre" un file descriptor sur un certain nombre de système unix (ce n'est pas un API POSIX, mais un ioctl spécifique).
SCM_RIGHTS est dans Single Unix, quand même, donc c'est censé être assez standard. J'ai écrit une bibliothèque qui implémente une interface simplifiée, elle doit être sur ma page web. Aux dernières nouvelles, elle marche au moins sous Linux, OpenBSD, FreeBSD et Solaris.
Pascal Bourguignon wrote in message
<87lkz3f13z.fsf@thalassa.informatimago.com>:
De plus, des processus peuvent se "faire suivre" un file descriptor
sur un certain nombre de système unix (ce n'est pas un API POSIX, mais
un ioctl spécifique).
SCM_RIGHTS est dans Single Unix, quand même, donc c'est censé être assez
standard. J'ai écrit une bibliothèque qui implémente une interface
simplifiée, elle doit être sur ma page web. Aux dernières nouvelles, elle
marche au moins sous Linux, OpenBSD, FreeBSD et Solaris.
De plus, des processus peuvent se "faire suivre" un file descriptor sur un certain nombre de système unix (ce n'est pas un API POSIX, mais un ioctl spécifique).
SCM_RIGHTS est dans Single Unix, quand même, donc c'est censé être assez standard. J'ai écrit une bibliothèque qui implémente une interface simplifiée, elle doit être sur ma page web. Aux dernières nouvelles, elle marche au moins sous Linux, OpenBSD, FreeBSD et Solaris.
projlin
hello et merci...
Les sockets seront point-à-point... c'est a dire ? que le serveurs si il a 60 clients doit avoir un socket
sur chaque clients ouvert ?? plusieurs processus ne peuvent pas ecrire dans un seul socket ?
et quand le client creer lui aussi un fils ?? a nouveau ouvrir un nouveau socket ?? et comment le serveur est au courant alors ?
hello et merci...
Les sockets seront point-à-point...
c'est a dire ? que le serveurs si il a 60 clients doit avoir un socket
sur chaque clients ouvert ??
plusieurs processus ne peuvent pas ecrire dans un seul socket ?
et quand le client creer lui aussi un fils ??
a nouveau ouvrir un nouveau socket ?? et comment le serveur est au
courant alors ?
