Discussion :

[Coussati]

bonjour

je vous explique mon problème :

j'ai une application client - serveur et à chaque connexion d'un client, je dois attendre de voir s'il est actif ou pas; pour cela le client envoie un message

s'il n'envoie aucun message, c'est qu'il est obsolète

mais dans ce genre d'application, les postes ne répondent pas dans un même laps de temps, à cause de plusieurs paramètre comme l'état de la connexion, la vitesse du processeur, ect; c'est pourquoi je préfère leur donner 20 secondes avant de les désigner "obsolète"

j'ai donc pensé à créer un thread pour chaque client qui se connecte; celui ci aura une durée de vie de 20 secondes : il aura pour but de vérifier (en boucle que le client a répondu, et en cas de non réponse après les 20 secondes, il s'auto kill

ma question est la suivante : comment procéder pour créer ce genre de thread ? il est dynamique car on ne sait pas combien on peut en avoir simultanément et ne dois pas faire ramer l'application ou la machine

j'aurais très bien pu raccourcir ce poste en posant ma question directement, mais n'étant pas un pro des thread (j'ai juste suivie quelques tuto sur developpez et d'autres site) et donc je voulais savoir si c'était adapté à ma situation, et si c'est réalisable

je vous remercie d'avance

[Rayek]

Qu'utilises tu comme composants pour le client-serveur ?

[Coussati]

Tclientsocket et Tserversocket

[ShaiLeTroll]

Déjà sur une machine standard, il est conseillé de ne pas dépasser 16 threads, surtout D7, après l'intégration de FastMM améliore (du moins limite les dégats si l'on abuse du thread) !

l'utilisation de stThreadBlocking peut être dangereuse pour cette raison !

Avec TServerSocket, tu as l'évènement OnRead, à chaque réception dans une liste de connexion, tu peux utiliser la propriété Data de chaque élements comme ceci Server.Socket.Connections[0].Data, tu peux y mettre un Objet ou Pointeur de Structure pour conserver la dernière Date de réception !

Dans un Thread séparé ou tout bêtement dans un Timer, tu parcours la liste de Connections et tu termine les Sockets qui ne communique plus !

Voir sur le Forum, j'ai déjà évoqué ce principe sous l'appellation de KeepAlive (soit tu implémentes ton propre KeepAlive au niveau application, soit tu plonges dans la doc TCP)

Pour la Gestion TCP avec ServerSocket, j'ai toujours utilisé en mode stNonBlocking, tout ce qui passe dans le socket est injecté dans une ThreadList.
Un Thread parcours cette ThreadList et gère tout le découpage de Buffer (gestion des données fragmentées en particulier), une fois l'analyse effectuée et qu'une structure est générée, on ajoute dans une 2nde ThreadList
Un 2nd Thread parcours cette 2nde ThreadList, et va effectuer les opérations "métiers" de l'appli, cela génère une autre structure qui est déposé dans une 3eme ThreadList
Un 3eme Thread s'occupe de parcourir la 3eme ThreadList, de transformer les structures en buffer et l'expédie vers le Client (il faut mémoriser tout le long le socket destinataire évidemment)

Biensur le Lock est limité à la récupération du Pointeur et la suppression de l'élement dans la liste en FIFO la plupart du temps, tout traitement se fait sur e pointeur récupéré en dehors du Lock

Structure ou Objet selon les besoins et habitudes ou pour faciliter la Sérialization

Selon ce principe, j'ai codé des applis qui tourne 24/24 en traitant presque de 1 000 000 requêtes des clients (ce qui donne près de 10 000 000 SQL pour la partie métier) en une seule journée !

Ne jamais faire de traitements long dans le OnClientRead, pendant ce temps les messages peuvent s'accumuler et faire déborder le tampon TCP\IP, c'est ce qui arrivait à l'un de nos partenaires lorsqu'on lui envoyait trop de données (plein de petit message, genre 40 en moins de 10 ms mais dont le traitement chez lui prenait bien plus)

[Coussati]

merci pour ton aide, je crois avoir trouvé un moyen d'après tes idées

j'ai besoin d'une boucle infinie, que me conseilles tu niveau efficacité et économie des ressources de la machine ?

le simple timer réglé sur 1 seconde ? ou autre chose ?

[ShaiLeTroll]

un Timer peut convenir si on ne touche pas l'appli pendant qu'elle traite des messages, cela peut géner, voir bloquer l'appli si tu as trop de traitement automatique

sinon, un Thread, plus délicat sur l'accès au ressource mais nettement plus élégant, avec un sleep(0) ou sleep(1), voir le sujet "Mesurer le temps dans un Thread"

[Coussati]

ok merci