votre avis (inter process)

Version imprimable

29/01/2008, 13h36
giova_fr

votre avis (inter process)

Bonjour à tous.
Je suis en train de developper une sorte de "Download Accelerator" FlashGet, etc..

J'aimerai avoir votre avis concernant la partie inter processus, car j'ai trouvé plein de solutions sur le net, et je me tatte pour faire mon choix.

D'un coté, j'ai une javascript dans une page html local qui instancie un objet dans une dll de classe c#. Ca me permet donc de récupérer l'url du lien cliqué dans IE pour la donner à ma dll.

Pour ce qui est de la durée de vie de cet objet, ca equivaux à l'execution de mon javascript (quand la methode de la dll rend la main).

En parallel, comme pour flasget et compagnie, je veux faire une appli, à la base sans fenetre, ni bouton dans la barre des tache, juste une notifyicon.

L'idée : ma dll récupere l'url, et la retransmet à mon executable permanent (celui avec le notifyicon).

_______________________________________________
Le debat :
J'ai trouvé plusieurs technologies sur les forums et codes source :
-L'appel de l'api windows => me parrait trop compliqué pour le besoin si simple
-les Dynamic Data Exchange => tres flou pour moi pour l'instant
-le Net Remote avec utilisation de canaux => me parrait trop lourd
-La classe Process => ah !

Je me dis que la derniere solution a l'air ideale : je fais en sorte que mon executable ne soit instanciable qu'une fois (par sécurité), ma dll recherche dans les process si mon exe est deja lancé, si non, elle le lance avec l'url comme argument, sinon... bah je ne sais pas trop encore comment balancer l'info, je pense qu'un message windows serait bien mais ne vois pas trop comment faire.
__________________________________________________
Question :
Quelle techno vous semble la plus adaptée?
Avez vous des conseils à me donner sur les pieges à éviter?
29/01/2008, 14h30
ced600

J'ai pas compris certaine de tes phrases.
Mais bon la communication entre différente process, il y a plusieurs méthode :
- Création et destruction de fichier texte dans un répertoire locale.
- Passage des paramètre par création et destruction de clé dans la BDR.
- Ouverture de port en lecture et ecriture pour les deux applications, et à l'aide d'un protocole donnée, échange d'information entre les deux applications. (Ma solution préféré, la plus propre, celle que l'on peut le mieux sécurisé, mais pas la plus simple à mettre en oeuvre).

Après il doit y avoir d'autre moyen.

Lancer ton processus par ta dll : Tu ne feras pas comme flasget qui peut être ouvert avant la récupération du liens. Cela dépend donc de ce que tu veux faire.

Je pense que les concepteur de flashget ont mis en place une solution proche de ma troisième proposition :D
29/01/2008, 14h52
theMonz31

salut

tu peux aussi passer par tes mecanismes de partage de mémoire pour faire communiquer les deux éléments

Pour la solution TCP/IP ou Remoting, c'est pas mal..

La solution par "pipe" (tube de communication) peut fonctionner egalement

Le partage par fichier revient au partage mémoire avec des problématiques de synchronisation entre les 2 applications (problème d'écriture si fichier ouvert, etc...)

The Monz, Toulouse
29/01/2008, 14h56
ced600

Citation:

tu peux aussi passer par tes mecanismes de partage de mémoire pour faire communiquer les deux éléments

Très bonne solution si les données échangé ont un volume faible.
Du genre : Je suis ready, je ne suis pas ready, ou l'url de la cible à télécharger.
29/01/2008, 15h09
theMonz31

et si tu veux faire du partage de mémoire, tu peux aller

Ici

(il y a un lien dans le 1er post avec un Zip à telecharger qui te permet
de faire ta memory shared facilement )

Seul inconvénient (mais c'est logique) , tu n'as pas la possibilité d'etre notifié
quand une mise à jour à eu lieu :)

Maintenant, tu pourrais fusionner Shared Memory et TCP/IP (avec les listeners, c'est facile à faire) , pour que sur reception d'une trame, tu saches qu'une nouvelle donnée a été mise à jour :) (et ainsi, tu notifies via le reseau, et tu partages les données via shared Memory :)... (ce qui limite la taille des echanges reseaux.... mais cela fonctionnera au niveau local... Shared memory ne peux pas etre utiliser en interprocess intermachine :(

The Monz, Toulouse
29/01/2008, 15h14
giova_fr

En effet, je voudrai que mon executable puisse se lancer indépendamment de la dll, ne serait ce que pour pouvoir offrir une Dlg qui permette de configurer le soft, ou lancer manuellement un téléchargement...

Partager la mémoire ne risque t'il pas de poser probleme par rapport à ca?

Citation:

Ouverture de port en lecture et ecriture pour les deux applications, et à l'aide d'un protocole donnée, échange d'information entre les deux applications.

Citation:

La solution par "pipe" (tube de communication) peut fonctionner egalement

Etes vous en train de parler d'un NetStream?
ou peut etre de l'IPC (Inter Processus Communication) offert (si j'ai bien compris) par le Net Remoting?

Je manque totalement d'expérience la dessus, quelques mots clés seraient les bienvenus, apres je me débrouille avec le MSDN...

Merci pour vos réponses en tout cas
29/01/2008, 15h17
ced600

ouvrir des ports TCP pour communiquer avec une application, en 1.1 j'ai fait cela avec les classes socket.
Maintenant je ne sais aps où elles sont rangés dans les versions récentes de .net
29/01/2008, 15h25
Bluedeep

Citation:

Envoyé par giova_fr

ou peut etre de l'IPC (Inter Processus Communication) offert (si j'ai bien compris) par le Net Remoting?

Le Remoting est une des implémentations de l'IPC sous Windows.

L'IPC regroupe :

- le DDE (c'est vieux ....) & RDDE
- la mémoire partagée (cf. File Mapping).
- le RPC (Remote Procedure Call).
- les Pipe (anonymes et nommés)
- les MailSlots
- les MessageQueue (MSMQ).
- en .Net, le Remoting (qui utilise aussi le RPC).
- les Sockets (qui peuvent être utilisés par le RPC et le Remoting).
- COM/DCOM (un cas particulier de RPC).
- sans oublier le SOAP (qui n'est au final qu'un cas particulier d'usage des sockets, s'apparentant au RPC)

En .Net 3.0, tu as aussi WCF (un surensemble du Remoting, qui inclus en plus la plupart des technos précitées).

(et j'en oublie surement)

Bref, tu as le choix :D

Il est rare dans l'absolu d'avoir à utiliser en direct les Sockets, sauf communication avec des automates et autres.
29/01/2008, 19h42
giova_fr
ok, merci pour toutes vos précisions.

Je vais me pencher sur le MessageQueue qui semble bien coller à mes besoins:
- Besoin: Petite info à transiter
- Besoin: Pas de contrainte coté temps de réponse
- En cas de plantage/crash durant la procédure, ne polue pas (contrairement à l'utilisation de fichiers ou de la BDR)
- Semble tres instructif pour un gros débutant comme moi
- Technologie qui n'est pas près de disparaitre sous windows, utilisée par "toutes" les applis => enseignement "rentable"
30/01/2008, 10h48
Bluedeep

Citation:

Envoyé par giova_fr

ok, merci pour toutes vos précisions.

Je vais me pencher sur le MessageQueue qui semble bien coller à mes besoins:

C'est un bon choix, mais, attention, il nécessite un service qui n'est pas installé par défait sur les stations clientes (ceci dit, l'installation optionnel se fait depuis le CP sans avoir à mettre le CD de Windows).