IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Delphi Discussion :

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


Sujet :

Delphi

  1. #1
    Membre actif Avatar de femtosa
    Inscrit en
    Juin 2002
    Messages
    253
    Détails du profil
    Informations forums :
    Inscription : Juin 2002
    Messages : 253
    Points : 222
    Points
    222
    Par défaut [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 ?
    "L'expérience est le seul livre que les imbéciles savent lire ... !"

    Qui à dit cela ? Moi je n'sais pas !
    Mais en tout cas, je l'applique au pas !

  2. #2
    Expert éminent sénior

    Avatar de sjrd
    Homme Profil pro
    Directeur de projet
    Inscrit en
    Juin 2004
    Messages
    4 517
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : Suisse

    Informations professionnelles :
    Activité : Directeur de projet
    Secteur : Enseignement

    Informations forums :
    Inscription : Juin 2004
    Messages : 4 517
    Points : 10 152
    Points
    10 152
    Par défaut
    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.
    sjrd, ancien rédacteur/modérateur Delphi.
    Auteur de Scala.js, le compilateur de Scala vers JavaScript, et directeur technique du Scala Center à l'EPFL.
    Découvrez Mes tutoriels.

  3. #3
    Membre actif Avatar de femtosa
    Inscrit en
    Juin 2002
    Messages
    253
    Détails du profil
    Informations forums :
    Inscription : Juin 2002
    Messages : 253
    Points : 222
    Points
    222
    Par défaut
    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 ?
    "L'expérience est le seul livre que les imbéciles savent lire ... !"

    Qui à dit cela ? Moi je n'sais pas !
    Mais en tout cas, je l'applique au pas !

  4. #4
    Membre chevronné
    Avatar de Clorish
    Profil pro
    Inscrit en
    Juin 2003
    Messages
    2 474
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2003
    Messages : 2 474
    Points : 2 158
    Points
    2 158
    Par défaut
    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.
    On passe du temps a vous repondre, alors soyez sympas, passez du temps ..... a vous relire !
    --
    Pourquoi tant de haine pour cette pauvre aide Delphi ????
    Aiiimezzz laaaaa .... Si-Non-Cham-Pi-Gnon !!!
    --
    Pour plus de Renseignements : Venez me rejoindre sur Msn .... Promis je mords pas

  5. #5
    Expert éminent sénior

    Avatar de sjrd
    Homme Profil pro
    Directeur de projet
    Inscrit en
    Juin 2004
    Messages
    4 517
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : Suisse

    Informations professionnelles :
    Activité : Directeur de projet
    Secteur : Enseignement

    Informations forums :
    Inscription : Juin 2004
    Messages : 4 517
    Points : 10 152
    Points
    10 152
    Par défaut
    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.
    sjrd, ancien rédacteur/modérateur Delphi.
    Auteur de Scala.js, le compilateur de Scala vers JavaScript, et directeur technique du Scala Center à l'EPFL.
    Découvrez Mes tutoriels.

  6. #6
    Membre actif Avatar de femtosa
    Inscrit en
    Juin 2002
    Messages
    253
    Détails du profil
    Informations forums :
    Inscription : Juin 2002
    Messages : 253
    Points : 222
    Points
    222
    Par défaut
    Ok merci beaucoup !



    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' !
    "L'expérience est le seul livre que les imbéciles savent lire ... !"

    Qui à dit cela ? Moi je n'sais pas !
    Mais en tout cas, je l'applique au pas !

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Passer une socket en mode non bloquant
    Par ProgVal dans le forum Langage
    Réponses: 2
    Dernier message: 24/12/2009, 22h15
  2. communication Port Usb en mode non bloquant
    Par laurentleroy dans le forum C
    Réponses: 4
    Dernier message: 29/10/2007, 00h29
  3. Réponses: 6
    Dernier message: 09/08/2006, 16h45
  4. socket non bloquante
    Par jeje99 dans le forum Réseau
    Réponses: 15
    Dernier message: 21/02/2006, 09h52
  5. Réponses: 1
    Dernier message: 05/01/2006, 01h26

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo