Discussion :

[aallal]

Bonjour Mr. François ,

J’utilise le Tcp/ip pour connecter des automates d’analyses à l’informatique central , sur certains automates , il y des caractères de contrôles qui sont envoyés comme le ENQ, EOT , ACK, NAK , ce genre de caractère contrôles ne sont pas interceptés par les composants tcp-ip comme celui ide indy(IdTCPServer) ou de Overbyte(TWSocketServer), puisqu'il n' y a pas CRLFà la fin .

Comment on peut donc faire pour intercepter ce genre de message de contrôles indispensable pour la suite de la communication . en réalité beaucoup de protocole comme l’ASTM commence par envoyé un ENQ pour établir la connexion , l’intercepteur doit retourner un ACK à cette demande, c’et après que le vrai message est envoyé.

Merci d’avance de votre aide ou suggestion.


Amen ALLAL

[ShaiLeTroll]

Avec le bon vieux TServerSocket et TClientSocket, j'échangeais du binaire, et le hasard pouvait que ces données contiennent ce genre de valeur !
Je pense que les IdTCPServer et TWSocketServer sont aussi capables de te les fournir, évite juste les fonctions à base de string en XE2, en privilégiant la manipulation de Byte !

je ne vois pas le rapport avec le CRLF, c'est du TCP\IP, le contenu est libre, c'est la couche applicative qui fournit la compréhension des paquets reçus

Pour le ENQ, EOT , ACK, NAK, c'est juste des caractères, tu dois pouvoir les recevoir sans soucis !
ne confonds pas avec la ACK et NAK de la touche TCP\IP qui gère justement la bonne réception des messages (voir les exceptions lors d'un SendMessage)

[aallal]

Bonjour ,
l'instrument que je veux connecter en tcp-ip , envoi un ENQ , de mon coté je ne reçois rein que ce soit avec TIDTcpServer (indy) ou bien avec TWsocket (OverByte), avant en utilisant une connexion rs232 j'avais aucun problème.

Merci.

[Andnotor]

Ce n'est pas simplement en remplaçant une connexion RS232 par une Ethernet que ça va marcher. Tu as bien sûr configuré ton "instrument" pour envoyer les données à une adresse IP sur un port précis ?
Contrôle également le dialogue à mettre en place. Il paraît surprenant qu'il y ait besoin de ENQ, ACK en TCP...

[aallal]

Oui bien sûr que j'ai configuré l'instrument l'ip + le port de mon serveur tcp-ip , au stade actuelle j’utilise un simulateur ASTM , moi aussi ça m'a paru bizarre la nécessité des ENQ et ACK.

le dialogue est celui de l'ASTM le protocole d'échange de données standard pour les instruments médicaux. Je vais essayais de voir s'il y a des spécifications de l'ASTM pour le tcp-ip , c'est une piste !

[ShaiLeTroll]

Ce n'est pas si surprenant pour avoir travailler dans chez fabricant, c'est juste que le protocole n'a pas changé entre le RS232, RS422 ou même en TCP\IP
A ce que j'ai pu voir chez ce fabricant, lors de l'ajout du TCP\IP, sur la plupart des modèles de carte que l'on fabriquait, c'est un switch physique qui routait la trame vers le RS232 ou vers le RJ45, le code C 16bit du micro-controleur n'avait pas changé
Pour le code Windows, le code était fouilli, j'ai jamais trouvé où tout cela se faisait !

Pour ton instrument
Soit le protocole maison était bien séparé entre le format de trame et le mode de transport, ils ont juste changer la couche transport en conservant le même protocol et tu hérites de ENQ, ACK en TCP... après tout pourquoi changer un code robuste !
Soit le protocole a été allégé pour le TCP et dans ce cas, tu dois gérer un autre parseur de trame

D'ailleurs, si le TCP\IP garanti l'échange de données, il ne garanti le bon traitement et la bonne compréhension des données par la couche applicative
donc il peut être nécessaire d'avoir un échange de ACK\NAK au niveau cohérence des données !