Discussion :

[bootix]

Bonjour, je ne souhaite pas un laius sur sa definition technique et sa mise en oeuvre (que je connais ) mais que des personnes experimentées qui l'utilisent m'expliquent pourquoi.

En fait je ne vois pas de cas d'utilisation: pourquoi faire du remoting plutot que du client/serveur.
Avec du client/serveur via les sockets on utilise aussi TCP, on ne fait que transiter des données ou des commandes qui permettent de lancer des traitement et obtenir une reponse...
Bref, je ne vois pas ce qu'apporte le remoting. QQun aurait une réponse, des exemples?

[Sphax]

Salut,

Je ne suis pas expert en la matière mais j'ai ma petite idée sur la question (et la réponse ). Derrière le remoting que crois tu qu'il y a ? Des sockets bien sur. Le remoting .Net n'est qu'une facilité qui t'est offerte en encapsulant les acces bas niveau (socket) ce qui est qd meme pas mal vu la complexité que peut prendre tout ça. J'imagine aussi que le remoting .Net t'offre des tas d'autres choses déja implémentées, testées, optimisées etc... que tu n'as pas a recoder toi même (sérialisation texte / binaire , sécurité, passage par référence, par valeur...).

C'est surement de l'artillerie lourde, qui n'est pas nécessaire dans des scénarii trés (trés) simples dans lesquelles la simple utilisation de socket pour faire communiquer tes applis suffit.

[bootix]

Merci pour ta réponse mais je ne suis toujours pas convaincu lol.
Bah en fait je ne trouve pas ça plus simple: les mecanisme de proxy, d'interface partagée... AU final la quantité de code n'est pas inferieure je crois.

[par valeur]
En fait c'est le fondement meme que je ne comprends pas:
pourquoi serialiser un objet et le faire transiter sur le reseau alors que l'on pourrait obtenir justes les données nécessaire à l'initialisation via socket et le créer nous meme en local:
1) Plus simple a mettre en oeuvre en socket qu'avec le remoting
2) Moins de données transitent sur le réseau

[par reference]
Créer un serveur traitant de simple commande donnant les actions à réaliser, c'est plus rapide à mettre en oeuvre en socket (je crois).

Partant de ce constat ou sont les avantages ?

[Thomas Lebrun]

Le Remoting, c'est l'appel de procédure distante.

En gros, imagine cette application:
- tu as un client sur ton PC qui te sert à controler le PowerPoint qui est sur un serveur
- ton client appelle des méthodes qui sont sur ton application serveur
- sur le serveur, tu executes ces méthodes


Ainsi, tu as exécuté, sur ton serveur, des méthodes qui ont été lancé depuis ton client

C'est plus clair :

[bootix]

Merci pour ta reponse Thomas.

Ce n'est pas vraiment un problème de clarté en ce qui concerne l'utilisation. par référence cela me parait evidemment le cas d'utilisation priviliegié mais ce que je me demande c'est:
N'est ce pas plus simple de créer un petit serveur TCP recevant par exemple des chaines de caracteres identifiées comme des commandes pour bouger les slides (pour reprendre ton exemple) ?

Concernant l'utilisation du marshalling par valeur, tu ne réponds pas, dois-je deduire que tu ne vois pas non plus de cas pratique d'utilisation ?

[Sphax]

Morpheus : je pense que bootix sait bien ça, mais ça ne repond pas à sa question, il pense que c'est plus simple de faire tout ça manullement avec des messages transitant par des sockets.

bootix :

[par valeur]
En fait c'est le fondement meme que je ne comprends pas:
pourquoi serialiser un objet et le faire transiter sur le reseau alors que l'on pourrait obtenir justes les données nécessaire à l'initialisation via socket et le créer nous meme en local:
1) Plus simple a mettre en oeuvre en socket qu'avec le remoting
2) Moins de données transitent sur le réseau

Bien sur ton exemple semble simple et marcherait pour un cas particulier. il faudrait refaire du code spécifique pour chaque classe que tu souhaites faire transiter dans tes tuyaux + création de ton propre "protocole" de transmission (sérialisation).
Le remoting te propose une généralisation de ces services, pas besoin de code spécifique particulier pour des types différent, il "suffit" de dériver d'une classe, d'implémenter telle interface, et le tour est joué. L'overhead du au remoting .Net (et encore faudrait le calculer, en serialisation binaire je ne sais pas si c'est beaucoup) est la contrepartie de cette généralisation a mon avis (on peut pas gagner sur tous les plans en meme temps )

[par reference]
Créer un serveur traitant de simple commande donnant les actions à réaliser, c'est plus rapide à mettre en oeuvre en socket (je crois).

Quasi meme reponse que juste au dessus : tu veux ajouter une nouvelle commande, code spécifique avec ta solution. En remoting, idem, soit un de tes objets implémente une nouuvelle interface, soit tu créés un nouvel objet qui dérive de la bonne classe et voila.

Avec toujours en arrière plan le fait que le remoting t'offre des services évolués (type de sérialisation, sécurité, surement d'autres auquel toi et moi ne penserions meme pas) qui te prendraient des années à développer si tu veux faire un truc sérieux et robuste.

Je ne voudrais pas avoir l'air de défendre absoluement le remoting .Net, je ne connais pas assez, je ne sais pas s'il a des faiblesses particuliere. Il est possible que pour certains cas (besoin de performances ? et encore je suis pas sur) le fait de refaire des choses bas niveau manuellement soit avantageux. Mais ta question semble plus générale un peu comme si tu disais : pourquoi utiliser tel framework/dll/composant tout fait, qui demande un peu d'apprentissage, et qui introduit de l'overhead (ce dont tu parles pour le marshalling par valeur) , pourquoi ne pas tout refaire soit meme manuellement ? Toujours la même réponse : par ce qu'il vaut mieux réutiliser des choses éprouvés, génériques, réutilisables, probablement bien mieux développées et débuggugées que ce que tu pourrais produire .

[bootix]

Merci beaucoup sphax, je pense que ca repond mieux à mes questions.

Je n'ai pas eu l'occasion de travailler sur des problème ou le remoting est sans conteste plus avantageux.

Tes commentaires me semblent pertinents.

Merci pour vos réponses.