[D2006][Socket]Mode bloquant vs non-bloquant

Hello :!:

J'utilise le composant TTcpClient dans mon applic pour envoyer et recevoir des commandes entre le PC et un processeur embarqué.

La connexion et le transfert marche correctement, dans un mode bloquant.

Cepandant, j'aimerai pouvoir traiter les évènements de mes fenêtres pendant un 'TTcpClient.ReceiveBuf' (entre autre timer). J'ai donc essayé de passer en mode non-bloquant. Cependant, ma connexion ne marche plus (ça me dis que je ne suis pas connecté après un 'Open').

En fait, j'ai juste changé le mode de mon TTcpClient en non-bloquant, je n'ai pas traité de messages ou autre ... .

Auriez-vous quelques explications concernant le mode non-bloquant ... (comment travailler, quels évènements traiter) ? Est-ce possible de faire ceci sans faire de thread dédié à la communication ?

Si ton logiciel est déjà conçu en bloquant, n'essaye pas de changer en non-bloquant. Tu vas perdre trop de temps.

En revanche, déplace ton ReceiveBuf dans un thread, et tout fonctionnera parfaitement. :)

Je ne sais pas si je perdrais beaucoup de temps, car c'est une classe qui s'occupe des connexions TCP et FTP. Et tout passe par là. Donc je n'ai peut-être pas beaucoup de changement à faire. Mais je pense que je vais quand même passé par un thread.

Autrement par thread, le fonctionnement est, si j'ai bien compris :

• Un thread dédié à la communication qui envoie des données et en reçois quand on y demande.
• Mon programme principale demande une réponse, et fait du polling jusqu'à ce qu'une réponse soit parvenu du thread (et dans ce polling je peux intégrer une notion de timeout).

C'est correct comme vision des choses ?

Moi j'opterais pour un thread qui execute les comunications bloquantes (mlanipulation de la classe TTcpClient)

Ensuite, le Thread peut "dialoguer" avec l'application via un systeme de gestionnaires d'evenements (attention aux eventuels synchronisations) ou bien par sendMessage, ou encore par le biais de property scannés regulierement par l'application.

On peut effectuer les operations inverse pour que l'application puisse "dialoguer" avec le Thread.

C'est l'idée, oui :)

Si tu veux un mécanisme simple de gestion de tâches à effectuer dans un thread, je t'invite à au moins regarder TScCustomTaskQueue. ;) Ta classe de gestion des communications pourrait l'utiliser/en dériver.

Ok merci beaucoup !

:king:

Je vais implémenter un thread qui manipule un objet TTcpClient et mon applic fera du polling pour vérifié l'état du thread !

Comme ça, pour mon applic la récéption d'une commande est une opération bloquante, mais je peux intégrer des Timeout ainsi que traiter les messages dans une boucle pendant que le thread reste bloquer sur sont 'TTcpClient.ReceiveBuf' !