Discussion :

[Coussati]

bonjour

cette question ne s'applique pas à un composant bien précis, mais aux composants client - server tcp ip en général, car c'est le même principe logiquement

pour exemple nous pouvons prendre les compo fournit dans delphi 7 Tclientsocket et Tserversocket

dans mon application, le server acceptera maximum 10 clients

tout fonctionnait parfaitement jusqu'à ce que je détecte une "faille" : le serveur est en écoute sur un port, si d'autres clients extérieur (client ftp ou autre) connaissent le port (en cas d'une application public par exemple) ils pourront s'y connecter

même s'ils ne pourront pas répondre aux différents "messages" qu'envoie le server, ils prendront une place inutilement

avez vous une idée ? pour soit niveau composant mettre une sorte de clé / chiffrement et déconnecter dans le "on accept" par exemple ?

[Coussati]

je ne trouve aucune solution, vous êtes ma dernière chance

si je me suis mal exprimé ou que vous n'avez pas compris mon problème je peux vous expliquer autrement ...

parce qu'on dirait qu'il n'y a pas de solution

[ShaiLeTroll]

Dans le OnAccept, tu ne peux pas échanger grand chose, en HTTPS par exemple, la connexion TCP\IP est effectué, ensuite l'échange de clés se produit, puis la "connexion" HTTP est faite (du moins la séquence POST->REPONSE)

Dans ton cas, une fois le client ouvert, tu lui envoie un message propre à ton application, le client doit répondre par un autre message, si tu ne reçois pas le message adéquat, tu fermes la connexion ... un simple Socket.Close !

Utilise un tableau Handle\Etat pour avoir l'état des lieux des connectés ... si un connecté reste pendant plus de 5secondes sans passer de Connecté à Identifié, tu le kick ...

Le Serveur n'envoie de données réelles qu'une fois le client identifié !

C'est ce que je faisais en général ... dans un projet, j'avais plusieurs programmes, une fois connecté sur le serveur, je demandais au programme qui il était (j'avais P1, P2, P2B, P3, P4, P5 et P6, AD1, AD2) et je devais envoyer à chacun différents messages en fonction d'évènement d'un automate et des actions sur l'un ou l'autre des programmes aussi ensuite le serveur se chargeait de dispatcher aux bons destinataires ...

Perso, j'utilisais OnRead en mode bloquant, mais je ne traitais pas le message, je ne faisais que le stocker dans un buffer, et c'est un thread qui se chargeait du parsage, analyse du message, préparation de la réponse, puis un autre thread se chargeait du KeepAlive, Envoie des Données ou du Kick ...

[Coussati]

merci pour ta réponse

j'avais pensé à faire quelque chose dans ce genre, mais je suis obligé de mettre en place un timer, et pour moi c'était compliquer la situation :/

[ShaiLeTroll]

C'est parce que tu traites tes messages dès leur reception ... passant toujours par un Thread et une FIFO (au final les performances sont meilleures et cela évite les problèmes de bufferisation des données TCP\IP) !

Effectivement, le plus simple dans ton cas, c'est un Timer, ...

[Coussati]

merci pour ton aide

j'essaierai de mettre en place le système et si j'ai un soucis je reviens poster