.NET IPC sans médiateur de service

Question

J'ai deux processus indépendants qui utilisent des assemblys .NET comme plugins.Cependant, l’un ou l’autre processus peut être démarré/arrêté à tout moment.Je ne peux pas compter sur un processus particulier comme serveur.En fait, plusieurs copies de l'un des processus peuvent être exécutées, mais une seule de l'autre.

J'ai initialement implémenté une solution basée sur Cet article.Cependant, cela nécessite que celui qui implémente le serveur s'exécute avant le client.

Quelle est la meilleure façon d’implémenter une sorte de notification au serveur lorsque le(s) client(s) s’exécutaient en premier ?

Answer 1

L'utilisation de la mémoire partagée est plus difficile car vous devrez gérer la taille du tampon de mémoire partagée (ou simplement en pré-allouer suffisamment).Vous devrez également gérer manuellement les structures de données que vous y insérez.Une fois que vous l’aurez testé et fonctionnel, il sera plus facile à utiliser et à tester en raison de sa simplicité.

Si vous optez pour la route distante, vous pouvez utiliser IpcChannel au lieu des canaux TCP ou HTTP pour une communication système unique à l'aide de canaux nommés. http://msdn.microsoft.com/en-us/library/4b3scst2.aspx.Le problème avec cette solution est que vous devrez proposer une solution de type registre (soit dans la mémoire partagée, soit dans un autre magasin persistant) avec laquelle les processus peuvent enregistrer leurs points de terminaison.De cette façon, lorsque vous les recherchez, vous pouvez trouver un moyen d'interroger tous les points de terminaison qui s'exécutent sur le système et vous pouvez trouver ce que vous recherchez.Les avantages d'opter pour Remoting sont que la sérialisation et l'appel de méthode sont tous assez simples.De plus, si vous décidez de passer à plusieurs machines sur un réseau, vous pouvez simplement basculer le commutateur pour utiliser les canaux réseau à la place.L'inconvénient est que l'accès à distance peut devenir frustrant à moins que vous ne sépariez clairement les appels « à distance » des appels « locaux ».

Je ne connais pas grand-chose à WCF, mais cela pourrait également valoir la peine d'être étudié.Spider sense dit qu'il a probablement une solution plus élégante à ce problème...peut être.

Alternativement, vous pouvez créer un processus « serveur » distinct de tous les autres processus et qui est lancé (utilisez un système Mutex pour vous assurer que plusieurs ne sont pas lancés) pour servir d'intermédiaire et de centre d'enregistrement pour tous. les autres processus.

Encore une chose à examiner dans le modèle Publish-Subscribe pour les événements (Pub/Sub).Cette technique est utile lorsque vous disposez d'un écouteur lancé avant que la source de l'événement ne soit disponible, mais que vous ne souhaitez pas attendre pour vous inscrire à l'événement.Le processus « serveur » gérera le registre des événements pour relier les éditeurs et les abonnés.

Answer 2

Pourquoi ne pas héberger le serveur et le client des deux côtés, et celui qui apparaît en premier devient le serveur ?Et si le serveur tombe en panne, le client toujours actif change de rôle.

Answer 3

Il existe de nombreuses façons de gérer IPC (.net ou non) et via un tunnel TCP/HTTP est un moyen... mais peut être un très mauvais choix (selon les circonstances et l'environnement).

La mémoire partagée et les canaux nommés sont deux méthodes (et oui, elles peuvent être réalisées en .Net) qui pourraient être de meilleures solutions pour vous.Il existe également la classe IPC dans le .Net Framework... mais personnellement, je ne les aime pas en raison de certains problèmes d'AppDomain...

Answer 4

Je suis d'accord avec Garo.

Utiliser un service pub/sub serait une excellente solution.Cela signifie évidemment que ce service devrait être opérationnel avant l’un ou l’autre des deux autres.

Si vous souhaitez ignorer la pub/sub, vous pouvez simplement implémenter le service dans les deux applications avec des points finaux différents.Lorsque l'une des applications est lancée, elle tente d'accéder à l'autre objet connu via le proxy IPC.Si le proxy échoue, l'autre objet n'est pas opérationnel.

-Scott

Answer 5

J'ai passé 2 jours à parcourir toutes les options disponibles pour l'IPC tout en recherchant un moyen fiable, simple et rapide de faire de l'IPC en duplex intégral. Bibliothèque IPC, que j'ai trouvé sur Codeplex.com, fonctionne jusqu'à présent parfaitement avec toutes les options que j'ai essayées.Le tout avec seulement 7 lignes de code.:D Si quelqu'un tombe sur cela en essayant de trouver un IPC full-duplex, gagnez beaucoup de temps et essayez cette bibliothèque.Récupérez le code source, compilez le data.dll et suivez les exemples donnés.

Hth, circ