Programmation réseau Delphi

Question

J'ai un programme client/serveur classique (gros client et base de données) écrit en Delphi 2006.Lorsque certaines conditions sont remplies chez le client, je dois en informer très rapidement tous les autres clients.Jusqu'à présent, cela se faisait à l'aide de diffusions UDP, mais cela n'est plus viable car les clients se connectent désormais depuis l'extérieur du LAN et la diffusion UDP est limitée au réseau local.

Je connais les bibliothèques Indy mais je ne suis pas vraiment sûr des composants à utiliser et de la manière de les structurer.Je suppose que j'aurai besoin d'un serveur auquel les clients se connectent et qui recevra et distribuera les messages... ?Des échantillons pour me aider à démarrer ?

Y a-t-il d'autres ensembles de composants ou technologies que je devrais examiner à la place/également ?

Answer 1

La réponse simple est que les protocoles standards disponibles dans Delphi (et d'autres outils) ne permettent pas la notification inverse.J'ai étudié cela pour un projet où je voulais utiliser SOAP.Ils supposent tous que le client demande au serveur, que le serveur répond et c'est tout.

Pour moi, la solution était le SDK RemObjects.Cela vous permet d'envoyer des notifications aux clients, et la notification peut contenir toutes les données de votre choix (tout comme le client vers le serveur).Moi-même, j'utilise la connexion SuperTCP, mais cela fonctionne aussi avec d'autres.Il peut toujours offrir une interface SOAP aux clients qui doivent l'utiliser, mais lorsque vous contrôlez à la fois le client et le serveur, cela fonctionne extrêmement bien.

Answer 2

Il existe plusieurs façons très simples de le faire avec Delphi, même si je suis sûr que le SDK RemObjects fonctionne également très bien.

1. Avoir un serveur central sur lequel est installé un *TIdTCPServer en écoute*.Chaque client dispose alors d'un TIdTCPClient dessus.Ils se connectent au serveur et bloquer sur une lecture en attendant pour le serveur pour écrire.Une fois que le serveur reçoit une notification via un socket d'écoute, il émissions à chacun des clients en attente.Il s’agit d’une notification quasi immédiate de tous les clients.
2. Avoir un serveur central doté d'un TIdTCPServer en écouteg dessus.Chaque client dispose alors d'un TIdTCPClient dessus.Ces clients peuvent "pinger" le serveur pour demander des mises à jour à intervalle régulier (utilisez un jeton de session pour maintenir l'état).La fréquence de l'intervalle détermine la rapidité de la notification.Lorsqu'un des clients doit avertir les autres, il en informe simplement le serveur.Le serveur utilise alors un file d'attente des messages pour faire une liste de toutes les sessions client actives et ajoute une notification pour chacune.Ensuite, la prochaine fois que chacun des clients se connectera, il lui enverra la notification et le supprimera de la file d'attente.
3. Maintenir un tableau des séances dans la base de données où chaque client met régulièrement à jour qu'il a une session active et se supprime lorsqu'il se déconnecte.Vous aurez besoin d'un processus de maintenance qui supprime les sessions mortes.Ensuite tu as un table de file d'attente de messages sur lequel un client peut écrire une mise à jour avec une ligne pour chaque session active en cours.Ensuite, les autres clients peuvent régulièrement envoyer une requête ping à cette table pour voir s'il y a des notifications en attente pour sa session, s'il y en a, il peut les lire, agir en conséquence, puis les supprimer.
4. Un genre de d'égal à égal approche dans laquelle les clients se connaissent grâce aux informations contenues dans la base de données, puis se connectent directement les uns aux autres et notifient ou demandent des notifications (en fonction des configurations du pare-feu et du NAT).Un peu plus complexe, mais possible.

Évidemment, le choix de l’implémentation dépendra de votre configuration et de vos besoins.Un réglage sera nécessaire pour obtenir les meilleurs résultats.

Les composants dont vous avez besoin pour cela sont les TIdTCPServer (auditeur) et TIdTCPClient (expéditeur).Tous deux se trouvent dans les bibliothèques Indy de Delphi.

Answer 3

Composants ICS de http://www.overbyte.be sont geniaux.AUtilisez TClientSocket et TServerSocket

Answer 4

Le projet FirebirdSQL utilise le concept de notifications comme étant des connexions serveur-client qui envoient une chaîne au client.Pour cela, le serveur de base de données utilise un autre port.Et demander au client de s'inscrire est intéressant de recevoir un certain type de notification via un appel API.

Vous pourriez utiliser la même idée.

Answer 5

RabbitMQ devrait correspondre à votre facture.Le serveur est gratuit et prêt à l'emploi.Vous avez juste besoin d'un côté client pour vous connecter, envoyer/envoyer un message et recevoir/extraire un message notifié.

Serveur: http://www.rabbitmq.com/download.htmlFaites un google pour le client ou implémentez-vous

Acclamations

Answer 6

Vous devriez pouvoir utiliser Multicast UDP dans le même but.La seule différence sera de rejoindre le groupe multicast depuis chaque client.

http://en.wikipedia.org/wiki/IP_Multicast

http://en.wikipedia.org/wiki/Internet_Group_Management_Protocol

Modifier: Juste pour clarifier, la multidiffusion vous permet de rejoindre un "groupe" donné associé à une adresse IP de multidiffusion.Tout paquet envoyé à cette adresse parviendra à tous les clients ayant rejoint le groupe

Answer 7

Vous pouvez regarder le composant wodVPN de weonlydo qui vous permet de créer une perforation UDP robuste et d'obtenir un transfert de port ou un VPN normal (avec un adaptateur réseau fourni) afin que vous puissiez connecter deux PC derrière un NAT.

J'utilise ce contrôle pour notre programme de communication et fonctionne très bien.