Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
[Tout langage] Quelle est la meilleure méthode d'échange d'objets entre process ?
Bonjour,
Tout est dans le titre ou presque.
En fait, je voudrais afficher un même objet dans plusieurs applications et s'il est modifié, toutes les applications sont informée, bien sûr.
Autre chose, toutes les applis sont en local.
Je sais qu'il existe .NET Remoting qui me permettrait même d'accèder à mon objet d'une autre machine, mais cette fonctionnalité ne m'intéresse pas.
Connaissez-vous d'autres solutions ?
merci
Si tout se passe en local et qu'il faille préserver les modifications dans le temps, je me demande si une simple sérialisation sous forme de fichier n'est pas le plus simple
Salut.
Tu as deux solutions à mon avis :
Soit tu fait avec le remoting, bien qu'il soit surtout conseillé pour des app distantes, il fera exactement ce que tu veux. Personnellement, je te conseil cette solution, c'est celle que je mettrai en place.
Sinon tu peux utiliser les sockets en implémentant ton propre protocole d'avertissement des modifications.
La méthode de neguib ne me parait pas adapter dans la mesure ou tu veux que les modifications soit répercuter directement et que tes apps tournent simultanément.
Sinon, si toutes tes applications sont des application .NET, il existe une autre solution un peu barbare:
Tu pars de l'idée de neguib: sérialisation dans un fichier XML
Ensuite, dans chacune de tes applications, tu met en place un FileWatcher sur ce fichier XML.
J'avais prévenu, c'est pas propre mais ca peut marcher
A la base, dans .NET, le remoting est fait pour ça. Tu ne veux pas l'utiliser, soit, mais ne veux tu pas nous dire pourquoi ? Le savoir permettrait d'éviter de te proposer des solutions ayant les mêmes inconvénients.
A part ça, je vois deux optiques :
- Sérialiser tes informations, les transmettre par un canal quelconques (fichier, socket, pipe, mémoire partagée,...) et les désérialiser de l'autre côté. C'est un peu équivalent au Remoting.NET en MarshalByValue.
- Utiliser un proxy et mettre au point un portocole de communication te permettant de faire croire que l'objet est transmis, alors qu'il réside encore physiquement dans le programme initial. Plutôt que de faire à la main, il y a pour ça des bibliothèque telles que Corba, COM (avec une passerelle vers .NET avec tlbimp/tlbexp) et le Remoting.NET en MarshalByRef
Salut !!Envoyé par fregolo52
Mes petits camarades ont raison, le remoting est le plus propre et le plus évolutif (possibilité de communication entre différentes machines).
Celà dis, si tu cherche un maximum de performance (à savoir un accés direct à une mémoire partagée entre process) il faut utiliser du p/invoke.
J'ai eu la même problématique il y a quelque temps et j'ai trouvé 2 excellents articles :
http://www.codeproject.com/dotnet/globalcache.asp
http://www.codeproject.com/csharp/csthreadmsg.asp
J'ai également d'autres sources mais je ne trouve plus les url correspondantes, si ça t'interesse contacte moi par MP.
A+
J'ai eu du mal à comprendre cette phrase, car je ne voyais pas le lien entre p/invoke et échange inter process. En fait, le p/invoke est ici juste le moyen de donner accès à des API permettant de mettre en place cet échange.
J'ai survolé le 1er article, et il semble que le problème principal qu'il veuille résoudre est celui de la performance. Sachant qu'on peut customiser dans le Remoting.NET la couche de transfert d'info, je partirais plutôt dans cette direction si c'était le seul problème qui m'empêchait d'utiliser .NET. Il me semble d'ailleur que .NET2.0 propose une couche mono machine bien plus performante que TCP pour ça (l'article date d'avant .NET2.0). Mais je n'ai pas ma doc sous la main pour vérifier.
Ca me parraissait clair pourtant, ce que je voulais dire, c'est qu'il n'existe pas (à ma connaissance) de moyen de faire du partage de mémoire inter process directement avec le Framework dotnet. Les solutions que je propose imposent de recourir aux Api windows et donc au p/invoke.
Que je sache, tout ce qui est remoting, implique la sérialisation des données, le transferts via une couche réseau (même au sein de la même machine) puis la déserialisation de ces données dans un autre processus.
Il y a traitement, il y a transport et il y a copie des données. Ca ne peut pas être aussi rapide que le 'shared memory'.
Si tu as une source ça m'interesse car j'ai un peu le même style de problème dans une de mes applis et si il y a moyen de rester en remoting avec des performance acceptables... je suis preneur.
Merci pour toutes ces informations.
Je vais me documenter sur vos propositions. (je débute en .NET)
En réalité mon chef veut éviter qu'un firewall mette une alerte. Mon appli est destinée au grand public, et si je me fait couper le port (utilisé par .NET Remoting), mon appli ne marchera plus.
Alors la seule solution, reste l'appel à l'API windows, pour réserver une zone mémoire et fournir le handle aux différents process partageant la ressource, ensuite tu serialize l'objet dans la dite zone en Shared memory, et les autres la deserialize. Tu peux meme ensuite utiliser la file de messages Windows et les messages personnalisés (WM_USER) pour indiquer que modification de l'objet il y a eu, ou tu fait un thread qui surveille tout changement dans la zone mémoire, sur chaque process (mais alors là pour le partage des verrous de sécurité jte souhaite bien du plaisir)
De toute facon il te faudra au moins simuler des verrous d'accès car si l'objet initial est changé au moment ou les autres le lisent ca va pas le faire
Mais ca reste de très loin, la méthode la plus rapide qui soit, et surtout qui passe au travers des firewall sans problème puisque tu n'utilise rien, pas de pipe, pas de socket, pas de fichiers ni rien, juste une zone mémoire que tu peux éventuellement verrrouillée à la création, si t'aime pas t'embeter avec les lock/unlock ... de l'api de gestion mémoire
BREF p/invoke est ton amis
bon courage .
le seul souci dans le cas du choix P/Invoke c'est que l'appli n'est plus portable sous un autre environnementAlors la seule solution, reste l'appel à l'API windows, pour réserver une zone mémoire et fournir le handle aux différents process partageant la ressource, ensuite tu serialize l'objet dans la dite zone en Shared memory, et les autres la deserialize. Tu peux meme ensuite utiliser la file de messages Windows et les messages personnalisés (WM_USER) pour indiquer que modification de l'objet il y a eu, ou tu fait un thread qui surveille tout changement dans la zone mémoire, sur chaque process (mais alors là pour le partage des verrous de sécurité jte souhaite bien du plaisir
De toute facon il te faudra au moins simuler des verrous d'accès car si l'objet initial est changé au moment ou les autres le lisent ca va pas le faire
Mais ca reste de très loin, la méthode la plus rapide qui soit, et surtout qui passe au travers des firewall sans problème puisque tu n'utilise rien, pas de pipe, pas de socket, pas de fichiers ni rien, juste une zone mémoire que tu peux éventuellement verrrouillée à la création, si t'aime pas t'embeter avec les lock/unlock ... de l'api de gestion mémoire
BREF p/invoke est ton amis
bon courage .; voir si le cahier des charges de notre questionneur le permet
Dans la mesure ou les directives conditionnelles sont possibles, il peut toujours écrire le code différemment grace aux conditionnelles, selon l'environnement cible. Maintenant c'est vrai qu'a ce régime là autant écrire du code non managé avec des directives de compilations partout pour la portabilité, comme je l'ai deja fait mais j'avoue, c'est horrible.
et après il ouvre grand le gaz et se met la tete dans le four.
Avec des idées comme ça on va directement à la catastrophe ...
Je voit pas l'intéret d'utiliser le P/Invoke alors que l'équivalent existe en dotnet ...
Répondre avec citation
Partager