Forum Programmation.autre RPC, SOAP, tout ça

Posté par  (site web personnel) .
Étiquettes : aucune
0
22
fév.
2006
Salut :)

Dans un développement à plusieurs est venu la question du "comment on fait pour les communications réseaux ?".
A ça, plusieurs solutions:
- sockets + protocole "bas niveau"
- RPC

Les RPC:
+ super simples à mettre en place, le code fait abstraction de tout ce qui est réseau
- souvent, c'est unidirectionel (si j'ai bien compris, comme xml-rpc et soap)

Les sockets:
- c'est super chiant à faire son propre protocole qui au final revient à refaire ses propres rpc
+ une socket TCP et c'est bidrectionel sans soucis

Alors la question qui je pense a déjà une réponse qqpart, c'est existe t il un truc aussi simple à manier que XML-RPC/SOAP et qui permettrait simplement au serveur d'appeler des méthodes sur des clients connecté et vice-versa ?
J'ai pensé à CORBA par exemple...
Bref, si quelqu'un avait une idée/éclaircissement... :)

Merci !

PS: un des buts est aussi de rester indépendant du langage, donc pas de Java RMI par exemple :)

  • # Ca dépend ...

    Posté par  . Évalué à 3.

    A mon avis, ca dépend de la complexité des communications.

    Si le protocole est simple et consiste simplement à envoyer quelques 'opcodes' comme 'start' 'jump' 'die' ... alors une socket sur laquel tu lis ou ecris un simple entier pour chaque opcode est très simple à mettre en oeuvre, surtout en langage de haut niveau comme python, perl, ...

    Si par contre tu veux appeler un grand nombre de fonctions, nombre d'arguments variables, etc .... alors utilise plutot quelque chose comme RPC, SOAP, ...
    Le choix précis de la technologie dépend de l'environement technique.
    Par example, si tout tes services sont en java, RMI ou JINI sont pas mals. Si l'environement est très hétérogène, SOAP peut être une meilleur solution ...

    • [^] # Re: Ca dépend ...

      Posté par  (site web personnel) . Évalué à 1.

      mais comment tu fais si tu veux utiliser du SOAP avec des clients potentiellement derrière un nat ? Est-ce qu'il existe une ruse magique en utilisant une connexion TCP toujours active pour faire remonter les RPC du serveur vers le client ou est-ce que c'est simplement pas la bonne solution ?

      • [^] # Re: Ca dépend ...

        Posté par  . Évalué à 3.

        Si ton client est derrière un NAT, la connexion se fait à son initiative. Si tu veux utiliser du SOAP (ou un truc de ce genre-là), une solution est d'avoir un client qui polle à intervalle régulier le serveur, qui maintient une file de tâches à faire exécuter au client.

        Souci : c'est pas rapide dans les cas généraux. Tu peux pallier à ça en prévoyant :
        - soit une fréquence de poll variable, ajustable selon des recommandations serveurs, si les tâches clientes sont longues (une communication asynchrone s'impose donc de toutes façons) ;
        - soit que le client rappelle toujours le serveur tant que ce dernier ne lui a pas envoyé un message de fin de conversation, dans quel cas le client attend la période prédéfinie avant de recontacter le serveur.

        Ca n'a certes rien à voir avec une connexion socket et des échanges rapides de données.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.