J'ai besoin de mettre en œuvre deux applications qui échangeront des données les uns avec les autres. Les deux applications seront exécutées sur des PC séparés qui font partie d'un réseau local.
Comment nous pouvons faire cela à Delphi?
existe-t-il un composant libre qui facilitera la tâche d'échanger des données entre les applications entre les PC?
10 Réponses :
Si je l'écris moi-même, je (presque) utiliser toujours des sockets pour échanger des données entre les applications.
C'est un poids léger, il fonctionne bien sur la même machine, sur le réseau local ou sur Internet sans changement et vous permet de communiquer entre les applications avec des autorisations différentes, comme des services (les messages Windows causent ici des problèmes ici).
Ce n'est peut-être pas une exigence pour vous, mais je suis également fan de Transports indépendants de la plate-forme, comme TCP / IP.
Il y a beaucoup de choix libres pour Delphi. Voici quelques-uns que je connais. Si vous aimez bloquer les bibliothèques, consultez indy ou Synapse . Si vous préférez non-bloquer, consultez ICS . < / p>
Désolé pour mon ignorance mais ce qui bloque et non bloquant? Je n'ai jamais rencontré ces termes même après la programmation depuis plus de 15 ans et plus de 15 ans. En fait, je n'ai jamais rencontré une telle exigence jusqu'à la date. Ceci est pour la première fois qu'un client a demandé une installation qui permettra à nos applications s'exécutant sur un PC différent de communiquer et d'échanger des données entre elles. J'avais vraiment l'intention d'adopter DCOM mais que le fait est que l'utilisation de COM dans Delphi est une douleur pure dans le ...
J'ai eu de très mauvaises expériences avec DCOM dès que les MIDA d'origine, qui ont utilisé DCOM comme transport par défaut. Si vous décidez de l'essayer, faites d'abord une enquête. Blocage des appels Arrêtez l'exécution du code jusqu'à ce que l'appel soit terminé. Pour les applications interactives, celles-ci doivent être utilisées dans des threads. Appels non bloquants Contrôle de retour immédiatement et vous avertit avec un événement lorsque l'appel est terminé. Chacun a ses avantages et ses inconvénients.
Com à Delphi est probablement le moyen le plus simple d'utiliser COM, mais ce n'est généralement pas le meilleur moyen de travailler sur un réseau. Le blocage et le non-blocage se rapporte à la manière dont le système d'exploitation gère le fil qui initie les E / S (un thread ou un processus bloqué ne doit pas être exécuté jusqu'à ce qu'il soit débloqué). Blocage d'E / S provoque un nettoyage de threads non programmé par le planificateur d'exploitation jusqu'à ce que les E / S complètent. Les E / S non bloquantes ne bloquent pas le fil, le thread continue à courir, mais doit utiliser un rappel ou un interrogation ou un autre mécanisme pour notifier l'achèvement.
Probablement le moyen le plus simple est de lire et d'écrire un fichier (ou éventuellement un fichier par direction). Il présente également l'avantage qu'il est facile de simuler et de tracer. Ce n'est pas l'option la plus rapide, bien que (et cela sonne définitivement boiteux ;-)).
Un accès simultané à un fichier sur un réseau n'est pas sûr du tout. Il est parfaitement sûr si le contenu est en lecture seule. Mais si vous voulez que le fichier soit modifié, ce n'est pas une bonne idée. En raison de la communication réseau, vous ne pouvez jamais être sûr que le fichier est verrouillé, même si vous utilisez les API Windows correspondantes. Ce peut être un cauchemar de déboguer.
Regardez les solutions qui utilisent des interfaces de type "appel à la procédure distante". J'utilise Remobjects SDK pour ce genre de chose, mais il existe des versions open source de Realthinclient qui ferait aussi bien.
Ces deux vous permettent de créer une connexion qui pour la majeure partie de votre code est "transparente", et vous appelez simplement une interface qui envoie les données sur le fil et obtient les résultats. Vous pouvez ensuite programmer comment vous faites habituellement et oubliez les détails des sockets, etc.
De ce que j'ai lu Realthinclient est gratuit pour le développement uniquement. Quelle est la vraie image à propos de RTC?
Vérifiez avec RTC sur le statut. Je pense que c'est comme MySQL en ce sens qu'il existe des versions «plus anciennes» ouvertes et que l'actuel est facturé. Pour moi, Remobjects SDK mérite une peine d'être payé - il a été très flexible.
J'avais l'habitude d'utiliser des flots de mails si je devais communiquer avec plus d'un PC à la fois ("diffusion") sur un réseau, bien que la mise en garde ne soit pas garantie.
Pour 1 à 1, les tuyaux nommés sont une manière Windows de faire cette traction de tri, vous ouvrez essentiellement un canal de communication entre 2 pièces, puis écrivez des messages dans le tuyau. Pas directement en avant pour commencer mais très fiable et la voie recommandée pour des choses comme Windows Services.
MS offre des tuyaux nommés comme une voie alternative de communication avec un serveur SQL (autre que TCP / IP).
Mais comme le dit Bruce, TCP / IP est Standard et la plate-forme indépendante et très fiable.
Les parcs de messagerie et les tuyaux nommés utilisent toutes deux TCP / IP pour la communication entre les machines et sont des options de protocole viables entre les applications sur le même réseau.
C'est l'un de ces cas où il n'y a vraiment pas de "meilleure" réponse comme à peine toutes les technologies déjà discutées peut être utilisée pour communiquer avec précision entre deux applications. Le choix de laquelle la méthode à utiliser sera vraiment atteinte à la nature critique de votre communication, ainsi que de la quantité de données à transférer d'un poste de travail à une autre.
Si votre communication n'est pas sensible ou critique temporelle, un simple sondage d'une base de données ou d'un fichier à intervalles réguliers pourrait être suffisant. Si votre communication est critique et sensible au temps, la mise en place d'un serveur TCPIP dans chaque client peut être utile. Si juste sensible à la fois, les gamelles de messagerie font un bon choix, si critique mais pas sensible au temps puis nommé tuyaux.
Avant de choisir une technique, vous devez caractériser la communication en fonction de son débit, de sa granularité, de la latence et de la criticité.
Débit - Quelle quantité de données par unité devrez-vous vous déplacer? La gamme de valeurs possibles est si large que les applications à taux les plus bas et les plus élevées n'ont presque rien de commun.
granularité - Quelle est la taille des messages? Combien de données la demande de réception doit-elle avoir besoin avant de pouvoir utiliser le message?
latence - quand une application envoie un message, combien de temps l'autre application doit-elle le voir? À quelle vitesse voulez-vous que l'application de réception réagisse à l'application d'envoi?
criticité - Combien de temps un message reçu peut-il être laissé sans surveillance avant qu'il soit envahi par un message ultérieur? (Ce n'est généralement pas important que si le débit est élevé et que le stockage des messages est limité.)
Une fois que vous avez répondu à ces questions, vous pouvez commencer à poser des questions sur la meilleure technologie pour votre situation particulière.
-al.
+1, bien que j'ajouterais au point de "criticité": les messages peuvent être reçus d'être reçus ou même être supprimés complètement?
Les messages comportent généralement 10 000 octets à tout moment. Tous les messages seront enregistrés dans un format propriétaire compatible avec un logiciel d'analyse statistique tiers.
Excellent point mghie - Je vais ajouter de la commande et de la fiabilité à mon concept de criticité. -Al.
DCOM était une bonne méthode de communication interprocessée. C'était aussi l'un des points forts de Delphis. Aujourd'hui, je serais Selon la nature de votre projet, je choisirais soit
DCOM est obsolète et j'ai beaucoup de problèmes en utilisant. Il est même désactivé sur la nouvelle version de Windows Server AFAIK.
J'ai utilisé le Composants de multidiffusion de la bibliothèque Indy (IDIPMcastClient / Server) pour ce type de chose plusieurs fois. Les applications envoient juste XML les uns aux autres. Quick et facile avec des exigences de connexion minimes.
Pour l'intégration de l'application Delphi, un Middleware orienté des messages pourrait être une option. Les courtiers de messages offrent une livraison garantie, un équilibrage de la charge, des modèles de communication différents et ils travaillent une plate-forme inter-plate-forme et une langue continue. Les courtiers de message de message open source incluent:
(Disclaimer - Je suis l'auteur des bibliothèques client de Delphi / Free Pascal pour ces serveurs)
Le logiciel n'aura jamais plus de 4 pc dans le réseau local de sorte que ce n'est jamais le problème. Je ne veux pas utiliser de serveur pour cela. L'utilisation d'un serveur est comme appeler un éléphant pour ramasser une brindille! Merci pour des suggestions.
Une possibilité pourrait être de "partager" des objets sur le réseau.
Il est possible avec un serveur client comme notre Little Mormot .
Ce bibliothèque open source fonctionne de Delphi 6 jusqu'à XE2 et utilisez JSON pour la transmission. Il y a certaines fonctionnalités de sécurité incluses (impliquant un Authentification reposante Mécanisme ), et peut utiliser n'importe quelle base de données - ou aucune base de données du tout.
Voir en particulier le Les quatre premiers échantillons fournis et la documentation associée.