Discussion :

[sp2308]

Bonjour

Je developpe une appli qui a besoin d une dll pour tourner.
J aimerai rendre cette dll accessible sur le net afin de ne pas avoir à la distribuer.
Pour info je passe à la dll un tableau de decimal, un decimal et elle retourne un entier.

Est-ce à dire que je dois developper un 'web service'?
Dans ce cas, existe t il un nombre limite de connexion simultanées avant de 'saturer' ce web service, d ailleurs y a t il une limite d appel simultané pour une dll ?

Merci de vos lumieres.
stephane

[lemoussel]

Cet article devrait t'aider : Routing Basics in ASP.NET Web API

[Pol63]

J aimerai rendre cette dll accessible sur le net afin de ne pas avoir à la distribuer.

pourquoi ?

Pour info je passe à la dll un tableau de decimal, un decimal et elle retourne un entier.
Est-ce à dire que je dois developper un 'web service'?

c'est une possibilité, il y a des tas de moyens de le faire, certains plus simples que d'autres
si tu as un serveur et que tu ne connais pas de technos web tu peux faire un exe avec du tcp/ip pur ou du wcf

Dans ce cas, existe t il un nombre limite de connexion simultanées avant de 'saturer' ce web service, d ailleurs y a t il une limite d appel simultané pour une dll ?

j'aurais tendance à dire 65k mais ca doit être "illimité" sinon ca serait mal fait ^^
tu peux fermer la connexion juste après avoir reçu la réponse et la réouvrir si tu as une nouvel appel à faire
et sur une dll il n'y a pas de limite de connexion vu que ca n'existe pas, une dll est utilisé ou non mais pas connectée

[sp2308]

merci pour ces réponses.

Pourqoui ne pas distribuer ma dll : Je fais un petit robot de trading. La dll etant le 'coeur' du systeme et souhaitant le proteger, j'ai decidé que chaque robot devra s identifier pour etre sur de n avoir à faire qu a des robots enregistrés. Donc le robot envoit son id avec les infos necessaires au calcul. La dll retourne une chaine codée par les infos uniques à ce robot qui decodera, des reception, la chaine et agira en fonction. La chaine de codage etant determinée à l enregistrement en fonction des divers parametres d installation...Ainsi, même si un robot enregistré utilise une autre installation que celle de son enregistrement, il ne pourra pas decoder ou aura des informations erronées et ferta planter le systeme...

Sinon je suis ouvert à toute les technologies (pour peu que je trouve des tutos), le but etant de pouvoir communiquer de façon robuste, le coeur etant sur un VPS, les robots etant sur des postes individuels....

[Pragmateek]

Utiliser un web-service est en effet ce qu'il y a de plus sûr, et comme l'a indiqué lemoussel tu peux utiliser Web API, plus simple que WCF et suffisant à priori dans ton cas (HTTP).

Cependant il n'y a pas de free-lunch, c'est sûr mais :
- lent comparé à une DLL locale,
- cela oblige tes utilisateurs à toujours être connectés à internet,
- tu risques de payer cher ton hébergement si tu as besoin de nombreuses ressources de calcul,
- si tu ne dimensionnes pas bien ton hébergement alors ta QoS sera fortement dégradée.
Le 2ème point n'est pas un problème si c'est pour un automate puisque de toute façon il faut que l'utilisateur soit connecté pour recevoir les ticks et passer ses ordres.

Tu peux envisager d'autres outils :
- l'obfuscation pour assurer la confidentialité du code,
- une activation via une licence,
- la customisation/watermarking de chaque DLL qui te permet d'identifier chaque utilisateur : cela n'empêche pas le partage mais le décourage fortement puisque l'utilisateur partagera ses informations,
- un mix entre service-web et local : tu interroges le serveur à intervalles réguliers pour vérifier que l'utilisation est légitime et le reste du temps tu te contentes d'exécution locale.

[Pol63]

à part peut etre l'https je ne vois pas ce qui pourrait sécuriser l'accès
un programme est décompilable, et on pourrait doit hacker le dialogue

[sp2308]

à part peut etre l'https je ne vois pas ce qui pourrait sécuriser l'accès
un programme est décompilable, et on pourrait doit hacker le dialogue

Je suis ok, c est decompilable mais...

Imaginons un simple soft qui se borne à calcluer a * b
J ajoute un c que je recupere online apres l envoi d infos qui permettent de s identifier (ex login et pass)

Je retourne C en fonction des infos d identification envoyées.C est crypté avec les infos qui ont été transmises à l install(ex serie disque, user windows etc)

Le soft decrypte la chaine reçu et fait a * b * c

Si c est pas un nombre ça plante et si c est pas le bon nombre ça donne un resultat erroné. Du coup une simple webrequest suffit...

Non ?

[Pragmateek]

à part peut etre l'https je ne vois pas ce qui pourrait sécuriser l'accès
un programme est décompilable, et on pourrait doit hacker le dialogue

Le programme est décompilable mais va t'amuser à lire du code obfusqué
C'est strictement illisible et à moins que sp2308 ait trouvé la martingale (ce que je lui souhaite ) personne ne fera l'effort de le désobfusquer.

Donc pour moi le problème de confidentialité n'existe probablement pas.

Donc ne reste à régler que le problème de partage : un petit malin fait tourner ta DLL via un forum par exemple.

Ce à quoi je pensais :
- tu dois être capable d'identifier l'utilisateur courant de ta DLL, via une clé de licence stockée en local typiquement que tu délivres à l'achat,
- côté serveur tu vérifies que cette clé n'est utilisée que depuis cette machine là (tu peux checker la config, l'adresse MAC...),
- dans le cas contraire tu avertis l'utilisateur et si ça continue tu bloques le compte.
Comme ça l'utilisateur n'a aucun intérêt à partager ton produit.

Là où ça peut devenir un peu plus subtil c'est si l'utilisateur héberge son code utilisant ta DLL sur des machines virtuelles dans le cloud, parce que là la config peut changer, la MAC encore plus, d'un instant (ou presque) à l'autre.

Si ta DLL est gratuite alors tu n'as plus de problème de partage, sauf si tu veux imposer certaines limites.

[sp2308]

merci pour toutes ces remarques.
je vais me creuser la tête...