Quelle classe ou fonction utiliser pour envoyer des messages par TCP IP

Bonjour,

C'est la première fois que je dois faire un projet avec une communication TCP et je ne sais pas qu'elle classe ou fonction utiliser pour arriver à mes fins.

J'ai un serveur qui ne fait que d'attendre une connexion TCP pour lire une chaine de caractère envoyée sur un port. Le serveur est passif, il ne répond pas après la réception du texte.

Mon rôle est d'envoyer une chaine de caractère au serveur en étant sur que celui-ci l'ai bien reçu.
Il y a une contrainte au niveau du temps, je peux me permettre un délai lors de l'établissement de la connexion mais aucun lorsque j'envoie le message.
Je dois donc gérer séparément la connexion au serveur et l'envoi de messages.
Lors de la connexion je dois pouvoir modifier un timeout.
Avant d'envoyer un message je dois être certain que que la connexion est valide.

J'ai testé les classes TTcpClient et TIdTCPClient mais je n'arrive pas faire ce que j'aimerais.

Le but final est de créer une DLL qui sera utilisée par Simatic WinCC permettant l'envoi de message.

J'utilise l'outil de développement C++ Builder 2007.

Merci d'avance

TCP n'est pas un protocole orienté message.
Il serait peut-être plus simple d'utiliser un protocole plus adapté à vos contraintes, comme UDP, si vos messages sont de petites tailles.

Citation:

---

Envoyé par bacelar

TCP n'est pas un protocole orienté message.

---

C'est vrai: une connexion TCP doit être vue comme un flux in-interrompu de données.
Si tu veux y ajouter la notion de 'message' (parlons ici de 'blocs' de données), tu vas devoir l'implémenter toi-même.
Par exemple en décrétant qu'un message se termine systématiquement par un caractère de type 'retour charriot' ('\n' en C/C++).
Donc ton programme va lire chaque octetreçu sur sa socket et la stocker dans un buffer. Dès qu'il détecte un '\n', il sait qu'il a reçu un bloc complet et peut le passer au reste de l'application pour qu'elle le traite.
Ton programme vide alors le buffer et recommence pour le message suivant.

Citation:

---

Il serait peut-être plus simple d'utiliser un protocole plus adapté à vos contraintes, comme UDP, si vos messages sont de petites tailles.

---

Surtout pas!
UDP est avant tout un protocole qui autorise la perte de paquets. Si les messages qu'ils envoient doivent tous arriver à destination, TCP est un meilleur choix.

Citation:

---

Il y a une contrainte au niveau du temps, je peux me permettre un délai lors de l'établissement de la connexion mais aucun lorsque j'envoie le message.

---

Je te conseille alors de désactiver l'algorithme de Nagle sur ta socket TCP . Tu y gagneras en vitesse au prix d'une légere augmentation de bande passante.

Boost.Asio peut être intéressant, si tu utilises déjà boost par exemple (dans le cas contraire aussi, mais tu seras peut-être plus réticent pour ajouter une bibliothèque à tes dépendances).
Elle permet de mâcher le travail.

Citation:

---

Envoyé par bacelar

Il serait peut-être plus simple d'utiliser un protocole plus adapté à vos contraintes, comme UDP, si vos messages sont de petites tailles.

---

Mais dans ce cas, le serveur devra impérativement renvoyer un datagramme de confirmation de bonne réception, sachant que ce datagramme peut être lui-même perdu, donc il faut gérer les retransmissions et ignorer les éventuels doublons côté serveur...

Bref, faut (presque) réimplémenter TCP, donc ce n'est pas forcément optimal côté temps de développement, même si in fine le résultat sera souvent "meilleur" en performances avec de l'UDP.
Mais bon, quitte à bosser aussi bas, pour ma part je passerais directement en Raw Sockets en m'évitant les couches UDP/IP.

UDP ne garantie pas l'ordre d'acheminement non plus.

Citation:

---

Envoyé par Mac LAK

Bref, faut (presque) réimplémenter TCP, donc ce n'est pas forcément optimal côté temps de développement

---

C'est le moins qu'on puisse dire !

Citation:

---

, même si in fine le résultat sera souvent "meilleur" en performances avec de l'UDP.

---

Non: un paquet TCP transite aussi vite qu'un paquet UDP. Le seul cas où UDP est plus rapide que TCP c'est si un paquet TCP précédent a été perdu, soit 0.4% des cas pour une transmission internet, et grosso modo moins d'un cas sur un million pour un réseau local LAN filaire. Mais dans ce cas, il faudra encore gérer le désordonnancement des paquets avec UDP (ou même d'abord savoir si ça a un sens au niveau de son appli).

Citation:

---

Mais bon, quitte à bosser aussi bas, pour ma part je passerais directement en Raw Sockets en m'évitant les couches UDP/IP.

---

De deux choses l'une:

- soit c'est pour une transmission dans un réseau local, donc probablement en filaire et donc le TCP fera aussi bien (taux de perte de paquets infime).

- soit c'est pour une transmission via le net, et un paquet non-TCP et non-UDP ne survivra pas au premier routeur rencontré.

Sur une sémantique message, le cas de perte ou de rejeu est facilement implémentable sans avoir recours à des fenêtre de temporisation, des fenêtre de bufferisation etc...

TCP/IP donne beaucoup de service mais UDP à un périmètre d'utilisation aussi vaste.

nouknouk, tes statistiques prennent-t-elles en compte le cout d'établissement et de fermeture de connexion, le problème des démarrage progressif (Nagles) etc... ?

Merci de vos réponses.

Voici quelques précisions sur vos remarques:

1 - Je n'ai pas le choix que d'utiliser TCP qui est imposé par le serveur. Celuis-ci est une application achetée où je n'ai aucun pouvoir de modification.
2 - Le serveur attend des blocs contenant du texte avec un terminateur "\r" pour séparer les diverses chaines.
3 - Le serveur ne retourne aucun message.
4 - Nous travaillons sur un réseau LAN et le réseau Internet ne sera jamais utilisé.
5 - Je n'ai pas besoin d'optimiser à la milli-seconde le protocol. Mais avant d'envoyer un message je dois être sur que la connexion est toujours OK car je dois éviter au maximum de bloquer mon application (DLL) plus de 100ms lors d'un envoi de message.


En fait j'ai juste besoin :
- de pouvoir tester si la connexion est réellement valide (Je suis p'être naif, mais je pensais que Connected ou Select de la classe TTcpClient me donnais) en cas de coupure du câble ou autre.
- de gérer les timeout qui sont actuellement proche des 20s.

Je vais voir Boost.Asio si ça arrange mes bidons...

Citation:

---

Envoyé par nouknouk

Non: un paquet TCP transite aussi vite qu'un paquet UDP.

---

Pas tout à fait : traverser (logiciellement) la couche TCP est plus long que traverser la couche UDP : pas de machine à états, pas de fenêtres, pas de fragmentation, pas de connexion trois points, etc.

Attention : soyons bien d'accord, là, on parle de gain très légers (de l'ordre de la microseconde au mieux pour chaque paquet). Sur UN envoi, c'est difficilement mesurable. Sur un transfert soutenu, c'est mesurable, voire significatif.

Citation:

---

Envoyé par nouknouk

- soit c'est pour une transmission dans un réseau local, donc probablement en filaire et donc le TCP fera aussi bien (taux de perte de paquets infime).

---

Toujours pareil : ce n'est qu'un problème de temps de traversée de la stack. Pas plus, pas moins.

Citation:

---

Envoyé par nouknouk

- soit c'est pour une transmission via le net, et un paquet non-TCP et non-UDP ne survivra pas au premier routeur rencontré.

---

Je n'envisageais pas une seule seconde d'utiliser des raw sockets sur WAN, je te rassure... ;)

Aucun protocole IP ne pourra dire en temps réel si le câble est déconnecté ou pas. C'est pas leur fonction. Débranché le câble ne réinitialisa pas les connexions TCP. Vous le rebranchez en moins de 2 minutes et les connexions sont encore opérationnelles.

L'approche la plus raisonnable est de faire des envoies non bloquant dans la partie cliente.

Citation:

---

Envoyé par bacelar

Aucun protocole IP ne pourra dire en temps réel si le câble est déconnecté ou pas. C'est pas leur fonction. Débranché le câble ne réinitialisa pas les connexions TCP. Vous le rebranchez en moins de 2 minutes et les connexions sont encore opérationnelles.

---

Je suis pas pro en communication mais je pensais qu'il était possible en utilisant des fonctions qui agisse à bas niveau de savoir si le récepteur (serveur) est toujours actif dans un socket ouvert.

Citation:

---

Envoyé par bacelar

L'approche la plus raisonnable est de faire des envoies non bloquant dans la partie cliente.

---

Oui je crois que c'est une bonne solution.
Je vais envoyé mes messages par socket non bloquant et faire une boucle (de max 100ms) qui vérifie si mes données ont bien été envoyées.

Citation:

---

Envoyé par lesteph

Je suis pas pro en communication mais je pensais qu'il était possible en utilisant des fonctions qui agisse à bas niveau de savoir si le récepteur (serveur) est toujours actif dans un socket ouvert.

---

Le driver Ethernet peut savoir instantanément si le câble est branché ou pas, c'est d'ailleurs ce qui permet à ton OS de te le dire.
Mais cela n'a absolument rien à voir avec les connexions TCP/IP, situées bien plus haut dans le modèle OSI, et qui peuvent "survivre" sans connexion physique pendant un petit moment (classiquement, trente secondes est un timeout courant).

Citation:

---

Envoyé par lesteph

Je vais envoyé mes messages par socket non bloquant et faire une boucle (de max 100ms) qui vérifie si mes données ont bien été envoyées.

---

Ou tu mets tout ça dans un thread et tu communiques au travers d'une FIFO, ça marche bien aussi.

Citation:

---

Envoyé par Mac LAK

Le driver Ethernet peut savoir instantanément si le câble est branché ou pas, c'est d'ailleurs ce qui permet à ton OS de te le dire.
Mais cela n'a absolument rien à voir avec les connexions TCP/IP, situées bien plus haut dans le modèle OSI, et qui peuvent "survivre" sans connexion physique pendant un petit moment (classiquement, trente secondes est un timeout courant).

---

Le driver Ethernet ne peut pas savoir si le câble est coupé après un switch.
Et il n'y a pas que la coupure de fil qui peux poser problème, l'application serveur peux être KO.

Citation:

---

Envoyé par Mac LAK

Ou tu mets tout ça dans un thread et tu communiques au travers d'une FIFO, ça marche bien aussi.

---

Oui c'est une bonne solution, mais un peu trop compliqué à gérer dans mon cas. C'est l'application qui appelle ma DLL qui dois gérer le buffer des données a envoyer. Ma DLL dois juste retourner 1 ou 0 si les données ont bien été envoyées.

Je vais creuser et faire encore des tests avec les classes Indy et Boost.

Merci en tout cas de tous vos commentaires :ccool:

Citation:

---

Envoyé par lesteph

Le driver Ethernet ne peut pas savoir si le câble est coupé après un switch.

---

Bien entendu, vu que le câble n'est PAS coupé : la connexion physique entre le switch et ta carte est "parfaite", c'est après que ça part en sucette.

Citation:

---

Envoyé par lesteph

Et il n'y a pas que la coupure de fil qui peux poser problème, l'application serveur peux être KO.

---

C'est TCP qui se charge de ça, après timeout, et non pas Ethernet.

Citation:

---

Envoyé par lesteph

Oui c'est une bonne solution, mais un peu trop compliqué à gérer dans mon cas. C'est l'application qui appelle ma DLL qui dois gérer le buffer des données a envoyer. Ma DLL dois juste retourner 1 ou 0 si les données ont bien été envoyées.

---

Alors pas le choix, faudra le faire en synchrone.

Citation:

---

Envoyé par Mac LAK

Alors pas le choix, faudra le faire en synchrone.

---

Question que je me pose : est-ce que tu es garanti d'avoir reçu l'ACK du distant quand send retourne sur une socket TCP synchrone ou est-ce que tu es seulement sur que les données sont dans le buffer d'émission et tu te prendras éventuellement une erreur plus tard si la transmission a échoué ?

Citation:

---

Envoyé par 3DArchi

Question que je me pose : est-ce que tu es garanti d'avoir reçu l'ACK du distant quand send retourne sur une socket TCP synchrone ou est-ce que tu es seulement sur que les données sont dans le buffer d'émission et tu te prendras éventuellement une erreur plus tard si la transmission a échoué ?

---

En UDP, la réponse est bien entendu "non" : quand tu reviens du send, c'est que c'est dans le buffer d'envoi et c'est tout.
En TCP, je pense qu'il doit être possible d'attendre l'ACK avant de revenir. Toutefois, il serait très très étonnant (pour des raisons évidentes de performances) que ce soit le mode par défaut des stacks sur les OS classiques...

Citation:

---

Envoyé par Mac LAK

En TCP, je pense qu'il doit être possible d'attendre l'ACK avant de revenir. Toutefois, il serait très très étonnant (pour des raisons évidentes de performances) que ce soit le mode par défaut des stacks sur les OS classiques...

---

J'avais un vague souvenir de ce genre: send retourne dès que les données sont transmises au buffer de la stack et non à la réception du ACK.

Donc une partie de son problème de départ (celle que je souligne) :

Citation:

---

Envoyé par lesteph

Il y a une contrainte au niveau du temps, je peux me permettre un délai lors de l'établissement de la connexion mais aucun lorsque j'envoie le message.

---

pourrait se traiter en jouant sur la taille des buffers d'émission/réception. Faudrait regarder comment évolue le volume de données produites par rapport à la vitesse de connexion : augmenter les buffers d'émission selon des scénarii appropriés à son appli.

Citation:

---

Envoyé par 3DArchi

Faudrait regarder comment évolue le volume de données produites par rapport à la vitesse de connexion : augmenter les buffers d'émission selon des scénarii appropriés à son appli.

---

Habituellement, plus les buffers sont gros, et plus il y a de latence entre l'envoi "officiel" (retour du send, donc) et l'envoi réel sur le réseau... Du moins pour TCP/IP, en UDP c'est en général sans réelle corrélation.

Citation:

---

Envoyé par Mac LAK

Habituellement, plus les buffers sont gros, et plus il y a de latence entre l'envoi "officiel" (retour du send, donc) et l'envoi réel sur le réseau... Du moins pour TCP/IP, en UDP c'est en général sans réelle corrélation.

---

Tout à fait. Mais si ce qui l'intéresse est de récupérer rapidement la main, ça peut être une piste. Mais bien sur sans connaître plus des contraintes de son système, ce n'est là qu'une idée.