Discussion :

[giova_fr]

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?

[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

[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

[ced600]

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.

[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

[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?

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.

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

[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

[Bluedeep]

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

Il est rare dans l'absolu d'avoir à utiliser en direct les Sockets, sauf communication avec des automates et autres.