J'ai utilisé l'IPC dans du code Win32 il y a un certain temps - sections critiques, événements et sémaphores.
Comment se passe la scène dans l'environnement .NET ? Existe-t-il un tutoriel expliquant toutes les options disponibles, quand les utiliser et pourquoi ?
Les travaux les plus récents de Microsoft en matière d'IPC sont les suivants Fondation Windows Communication . En fait, il n'y a rien de nouveau dans le niveau inférieur (tcp, upd, named pipes etc) mais WCF simplifie grandement le développement IPC.
Ressource utile :
et bien sûr MSDN sur WCF
En dehors de l'évident (WCF), il existe une liaison ZeroMQ pour C#/CLR qui est assez bonne :
http://www.zeromq.org/bindings:clr
Effectue des IPC orientés message, des pubs/subs et diverses autres stratégies avec beaucoup moins de code et de configuration que WCF.
Il est également au moins un ordre de grandeur plus rapide que n'importe quelle autre solution et présente une latence moindre si vous avez besoin de communications à faible latence.
En ce qui concerne les sémaphores, les verrous, les mutex, etc. Si vous partagez en communiquant plutôt que de communiquer en partageant, vous aurez beaucoup moins d'ennuis que dans le paradigme traditionnel.
"partager en communiquant plutôt que communiquer en partageant". Cette phrase devrait être récitée tous les jours par tous ceux qui font de la programmation concurrente.
Pour moi, cela signifie qu'au lieu de partager des ressources et de laisser chaque programme essayer de les réclamer à volonté, vous devriez faire en sorte que les programmes communiquent directement entre eux grâce à l'IPC. Dans le premier scénario, vos programmes "communiquent" en verrouillant une ressource partagée. Dans le second, ils communiquent par le biais d'un protocole pour coordonner l'utilisation de la ressource partagée.
J'ai tendance à utiliser des tuyaux nommés ou des sockets Unix (selon que je vise MS.NET ou Mono - j'ai une classe qui fait abstraction de tout cela) car c'est facile à utiliser, portable, et me permet d'interagir facilement avec du code non géré. Ceci étant dit, si vous ne traitez que du code géré, optez pour WCF ou remoting - ce dernier si vous avez besoin du support Mono, puisque leur support WCF n'est tout simplement pas encore là.
Bien que cela ait pu être le cas en septembre 2008 (lorsque ce commentaire a été fait), nous sommes en 2011 et WCF sur Mono est assez mature maintenant. Voir le Page sur le développement Mono WCF et jugez par vous-même.
Je recommanderais d'utiliser Memory Mapped Files si vous avez besoin d'utiliser le domaine de la machine et non la communication par le réseau. Voir le lien suivant.
http://techmikael.blogspot.com/2010/02/blazing-fast-ipc-in-net-4-wcf-vs.html
On dirait que vous vous intéressez aux techniques de synchronisation plutôt qu'à la communication. Si c'est le cas, vous pourriez commencer par aquí ou peut-être ce plus un aperçu concis .
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
1 votes
Que devez-vous faire ? Si vous devez synchroniser l'accès à une ressource externe, vous pouvez utiliser un Mutex pour mettre en œuvre la synchronisation interprocessus.
12 votes
+1. Merci mon Dieu. C'est la première fois que je vois des questions avec une saveur "Meilleures pratiques" qui ne sont pas marquées comme non constructives/hors sujet [que je n'ai jamais vu] ! !!