Meilleure pratique: gardez la connexion TCP / IP ouverte ou fermez-la après chaque transfert?

Question

Mon serveur-application utilise un TIDTCPSServer, plusieurs applications client utilisent TIDTCPCLIENTS pour se connecter au serveur (tous les ordinateurs sont dans le même LAN).

Certains clients n'ont besoin de contacter le serveur toutes les deux minutes, d'autres une fois à chaque seconde et un le fera environ 20 fois par seconde.

Si je garde la connexion entre un client et le serveur ouvert, je vais enregistrer le reconnecter, mais que je dois vérifier si la connexion est perdue.

Si je ferme la connexion après chaque transfert, il doit se reconnecter à chaque fois, mais il n'est pas nécessaire de vérifier si la connexion est toujours là.

Quelle est la meilleure façon de procéder?

À quelle fréquence de transferts de données dois-je garder la connexion ouverte en général?

Quels sont les autres avantages / inconvénients pour les deux scénarios?

Answer 1

Je suggérerais un mélange des deux. Lorsqu'une nouvelle connexion est ouverte, commencez une minuterie inactive. Chaque fois que les données sont échangées, réinitialisez la minuterie. Si la minuterie s'écoule, fermez la connexion (ou envoyez une commande au client pour demander s'il veut que la connexion reste ouverte). Si la connexion a été fermée lorsque les données doivent être envoyées, ouvrez une nouvelle connexion et répétez. De cette façon, les connexions moins utilisées peuvent être fermées périodiquement, tandis que les connexions plus utiles peuvent rester ouvertes.

Answer 2

Deux cents de l'expérience ...

Ma première application client / serveur TCP / IP a utilisé une nouvelle connexion et un nouveau thread pour chaque demande ... il y a des années ...

Ensuite, j'ai découvert (en utilisant ProcessExplorer) qu'il a consommé certaines ressources de réseau car toutes les connexions fermées ne sont en effet pas détruites, mais restent dans un état particulier pendant un certain temps. Beaucoup de fils ont été créés ...

J'ai même eu quelques problèmes de connexion avec beaucoup de demandes concurrentes: je n'avais pas assez de ports sur mon serveur!

Alors Je l'ai réécrit, suivant le schéma HTTP / 1.1, et le KeepAlive caractéristique. Il est beaucoup plus efficace, utilise un petit nombre de threads et ProcessExplorer aime mon nouveau serveur. Et je ne manquais plus de port. :)

Si le client doit être arrêté, je vais utiliser un threadpool pour, au moins, ne créez pas de thread par client ...

En bref: si vous le pouvez, gardez vos connexions clients en vie pendant quelques minutes.

Answer 3

Bien qu'il puisse être bien de se connecter et de se déconnecter pour une application active une fois toutes les quelques minutes, l'application qui communique plusieurs fois par seconde verra une augmentation des performances en laissant la connexion ouverte.

De plus, votre code sera très simple si vous n'essayez pas d'ouvrir, de fermer ou de diagnostiquer ou de diagnostiquer constamment une connexion ouverte. Avec la logique ouverte et étroite appropriée, et SEH autour de votre lecture et écrit, il n'y a aucune raison de tester si le socket est toujours connecté avant de l'utiliser, utilisez-le simplement. Il vous dira quand il y a un problème.

Je pencherais pour garder une seule connexion ouverte dans la plupart des applications d'entreprise. Cela conduira généralement à un code plus propre, ce qui est plus facile à entretenir.

/deux centimes

Answer 4

Je suppose que tout dépend de votre objectif et de la quantité de demandes faites sur le serveur dans un temps donné sans parler de la bande passante disponible et du matériel sur le serveur.

Vous devez également réfléchir pour l'avenir, y a-t-il une chance qu'à l'avenir, vous aurez besoin de connexions à laisser ouvertes? Si oui, vous avez répondu à votre propre question.

J'ai implémenté un système de chat pour un projet dans lequel ~ 50 personnes (le nombre augmente avec chaque 2 mois) sont toujours connectées et en plus de discuter, il comprend également le transfert de données, la manipulation de la base de données à l'aide de certaines commandes, etc. Ma mise en œuvre est de garder le La connexion au serveur s'ouvre à partir du démarrage de l'application jusqu'à ce que l'application soit fermée, aucun problème jusqu'à présent, mais si une connexion est perdue pour une raison quelconque, elle est automatiquement rétablie et que tout se poursuit parfaitement.

Dans l'ensemble, je vous suggère d'essayer les deux (garder la connexion ouverte et la fermer après son utilisation) et voir ce qui correspond le mieux à vos besoins.

Answer 5

À moins que vous n'émettiez à plusieurs centaines de connexions simultanées, je la garderais certainement ouverte - c'est de loin le meilleur des deux options. Une fois que vous avez dépassé les centaines en milliers de connexions simultanées, vous devrez peut-être laisser tomber et vous reconnecter. J'ai architeclé tout mon cadre autour de cela (http://www.csinnovations.com/framework_overview.htm) Puisqu'il me permet de «pousser» les données au client du serveur chaque fois que cela est nécessaire. Vous devez rédiger un peu de code pour vous assurer que la connexion est en place et fonctionne (décrochage de réseau, pings chronométrés, etc.), mais si vous faites cela dans votre "framework", votre code d'application peut être écrit dans un tel La façon dont vous pouvez supposer que la connexion est toujours "en haut".

Answer 6

Le problème est la limite des threads par application, autour de 1400 threads. Donc, les clients max 1300 connectés en même temps + -.

Answer 7

Lors de la fermeture des connexions en tant que client, le port que vous avez utilisé ne sera pas disponible pendant un certain temps. Donc, à un volume élevé, vous utilisez des charges de différents ports. Pour tout ce qui est répétitif, je le garderais ouvert.