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

Version imprimable

23/09/2009, 11h44
lesteph

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
23/09/2009, 12h13
bacelar

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.
23/09/2009, 12h26
nouknouk

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.
23/09/2009, 13h00
Alp

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.
23/09/2009, 13h05
Mac LAK

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.
23/09/2009, 13h46
loufoque

UDP ne garantie pas l'ordre d'acheminement non plus.
23/09/2009, 13h49
nouknouk

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é.
23/09/2009, 14h33
bacelar

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... ?
23/09/2009, 14h56
lesteph

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...
23/09/2009, 15h05
Mac LAK

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... ;)
23/09/2009, 15h26
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.

L'approche la plus raisonnable est de faire des envoies non bloquant dans la partie cliente.
23/09/2009, 15h56
lesteph

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.
23/09/2009, 16h07
Mac LAK

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.
24/09/2009, 08h52
lesteph

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:
25/09/2009, 12h46
Mac LAK

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.
25/09/2009, 14h44
3DArchi

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é ?
27/09/2009, 15h49
Mac LAK

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...
27/09/2009, 20h01
3DArchi

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.
27/09/2009, 20h53
Mac LAK

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.
28/09/2009, 09h20
3DArchi

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.
28/09/2009, 09h51
nouknouk

Citation:

Envoyé par Mac LAK

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.

On est bien d'accord: on parle d'un temps pour traverser la stack qui est totalement négligeable ; la granularité de l'ordonnanceur pour un OS non temps-réel (ce qui me semble être ton cas puisque tu parles de 'DLL') anihilera toute différence, de même que tout code dans ton développement un poil moins optimisé que ce qui aurait pu l'être.

Donc l'UDP n'aidera en rien ici à 'gagner du temps'. C'est ce que je voulais souligner, car ce genre de mythe "TCP est plus lent qu'UDP" (dans le sens SENSIBLEMENT plus lent) est un mythe qui a malheureusement la vie (trop) dure sur le web.

Citation:

Envoyé par bacelar

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... ?

On parle évidemment d'une connexion déjà établie, donc une comparaison dans le cadre d'un fonctionnement 'normal' de chacun des protocoles (ie. tels qu'ils ont été prévus). Et dans ce cas là, la différence est nulle.

Citation:

Envoyé par Mac LAK

[...]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).

+10. Au mieux, tu pourras détecter au moyen de fonction bas niveau (non relatives au sockets) la perte de connexion sur le premier lien entre ton ordi et l'équipement suivant (switch, ...). En aucun cas, tu ne pourras 'monitorer' le serveur à l'autre bout de la connexion.
Les deux seules solutions sont:
- soit le programme du serveur qui envoie un ACK à chaque donnée reçue
- soit un mécanisme de 'keepalive' implémenté avec une fréquence bien supérieure aux 'standards' (genre 200ms au lieu des 30s habituelles).

Citation:

Envoyé par 3DArchi

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) pourrait se traiter en jouant sur la taille des buffers d'émission/réception.

Je ne vois pas en quoi jouer sur le buffer d'émission changera quoi que ce soit, à moins que les quantités de données soient telles que la liaison ne supporte plus la charge.
La bonne solution me semble être la désactivation de l'algo de Nagle sur la socket qui générera un paquet à chaque appel 'write' sur ta socket.

L'idéal serait d'avoir plus de données sur les contraintes imposées. Mais si on se réfère à ce que j'ai pu glaner:

- on a un réseau filaire local (supposons du 100Mbits)
- on a une quantité de données 'raisonnable' puisqu'aucun souci de débit n'a été mentionné
- on veut un temps d'exécution de 100ms maximum de la fonction de la DLL.
- on préfère faire du synchrone pour l'appel de la fonction de la DLL (elle retourne le résultat de l'envoi).

Dans ce cas là, les contraintes ne sont finalement pas bien fortes. On peut surtout compter sur une latence très faible d'une réseau Ethernet uniquement filaire (moins de 5ms de RTT).

Donc on a 20 fois plus de temps (100ms / 5ms) que le temps 'réseau' nécessaire pour envoyer un paquet et recevoir une sorte d'ACK que le serveur émterrait à chaque réception de paquet.
En d'autres termes, ça veut dire que même si on a une perte de paquet de temps en temps (voir même 10 de fois de suite, ce qui n'arrivera jamais), la marge est bien assez large pour laisser le temps à la couche TCP de renvoyer le paquet perdu et attendre un message d'ACK (de niveau applicatif au sens OSI) du serveur.

Donc le plus simple me semble de ne pas s'encombrer outre mesure:

- une connexion en TCP, algo de Nagle désactivé (important)

- on établit une fois pour toutes la connexion avec le serveur au départ.

- chaque fois qu'on veut envoyer une donnée, on utilie le canal TCP; à la réception de la donnée, le serveur envoie à son tour un message d'ACK.

- dès le ACK reçu côté client, la DLL retourne le résultat.

- on implémente un timeout de 100ms. Passé le délais, la DLL retourne une erreur 'serveur indisponible ou réseau surchargé (ou liaison de daube)'.

Ca prendra 15 minutes à implémenter et ça couvrira l'ensemble des contraintes énumérées. Pas besoin de vouloir s'ennuyer à faire quoi que ce soit de plus complexe amha.
28/09/2009, 09h57
Mac LAK

Citation:

Envoyé par nouknouk

+10. Au mieux, tu pourras détecter au moyen de fonction bas niveau (non relatives au sockets) la perte de connexion sur le premier lien entre ton ordi et l'équipement suivant (switch, ...). En aucun cas, tu ne pourras 'monitorer' le serveur à l'autre bout de la connexion.

Pas par ce biais en tout cas, en effet. On peut toujours avoir un "keep-alive" via des requêtes ICMP ou UDP, mais c'est un tout autre registre et, surtout, ça commence à sentir l'usine à gaz si l'on en arrive à un tel point... :mouarf:
28/09/2009, 10h02
nouknouk

Citation:

Envoyé par Mac LAK

Pas par ce biais en tout cas, en effet. On peut toujours avoir un "keep-alive" via des requêtes ICMP ou UDP, mais c'est un tout autre registre et, surtout, ça commence à sentir l'usine à gaz si l'on en arrive à un tel point... :mouarf:

Désolé, j'ai édité mon post entre temps pour le compléter. Effectivement on peut avoir un mécanisme de keep-alive, mais au final ça ne sert à pas grand chose: quelle que soit la fréquence du keep-alive choisie, il se pourra très bien que le serveur soit 'tombé' entre le dernier 'keep alive' et l'appel de la fonction de la DLL.
On ne ferait que diminuer (mais on ne le supprime pas) la probabilité de renvoyer un résultat erroné en sortie de fonction DLL (genre "paquet OK" alors qu'en réalité les serveur était 'tombé' et le paquet jamais réçu).

Le mécanisme d'ACK au niveau logiciel est quand à lui sûr (sauf cas exceptionnel) et beaucoup plus immédiat à implémenter.
28/09/2009, 15h49
lesteph

Citation:

Envoyé par nouknouk

Donc le plus simple me semble de ne pas s'encombrer outre mesure:

- une connexion en TCP, algo de Nagle désactivé (important)
- on établit une fois pour toutes la connexion avec le serveur au départ.
- chaque fois qu'on veut envoyer une donnée, on utilie le canal TCP; à la réception de la donnée, le serveur envoie à son tour un message d'ACK.
- dès le ACK reçu côté client, la DLL retourne le résultat.
- on implémente un timeout de 100ms. Passé le délais, la DLL retourne une erreur 'serveur indisponible ou réseau surchargé (ou liaison de daube)'.

Yes c'est exactement ce que j'aimerais faire mais il y a un problème, mon serveur ne me répond pas, c'est une applic achetée ou je ne peux rien faire. Il faut que je puisse lire l'ACK de la couche TCP.

Citation:

Envoyé par nouknouk

Ca prendra 15 minutes à implémenter et ça couvrira l'ensemble des contraintes énumérées. Pas besoin de vouloir s'ennuyer à faire quoi que ce soit de plus complexe amha.

Quelles classes, fonctions, ... est ce que tu utilise pour faire ça ?

Citation:

Envoyé par Mac LAK

Pas par ce biais en tout cas, en effet. On peut toujours avoir un "keep-alive" via des requêtes ICMP ou UDP, mais c'est un tout autre registre et, surtout, ça commence à sentir l'usine à gaz si l'on en arrive à un tel point... :mouarf:

Jeudi passé en faisant des recherches sur le net je suis tombé sur un article qui parlait de faire un keep-alive avec l'envoi d'un message TCP ne contenant aucune donnée. Est ce que ça serais utilisable ?
28/09/2009, 15h59
nouknouk

Citation:

Envoyé par lesteph

Yes c'est exactement ce que j'aimerais faire mais il y a un problème, mon serveur ne me répond pas, c'est une applic achetée ou je ne peux rien faire. Il faut que je puisse lire l'ACK de la couche TCP.

Effectivement, j'aurais du relire avec plus d'attention tes posts précédents :oops:

Tu as une solution très simple à implémenter pour palier à ce souci: un petit logiciel jouant le rôle de proxy que tu intercales entre le serveur à contacter et la DLL qui émet les messages.

Concrètement, la communication ne se fera pas entre ta DLL et le serveur directement, mais entre ta DLL est un petit programme (à toi) qui tournera en local sur la machine hébergeant le serveur: la DLL est exécutée sur le poste client ; le 'proxy' s'exécute quant à lui sur la même machine 'physique' que le 'serveur' auquel la DLL doit envoyer ses messages.

Encore plus conrètement:

- ta DLL (côté client donc) envoie un message via une connexion TCP à ton proxy.

- le proxy reçoit le message, et le frowarde vers l'appli serveur vi une connexion TCP mais cette fois locale à la machine (connexion utilisant le localhost).

- si problème de réception côté serveur ou connexion fermée prématurément, ton proxy étant en localhost, il va être notifié de la chose quasi instantanément.

- le proxy renvoie le résultat au client (la DLL): ACK ou erreur.

- la DLL reçoit le résultat et sort de ta fonction d'envoi.

Citation:

Quelles classes, fonctions, ... est ce que tu utilise pour faire ça ?

Tout dépend de ton environnement (notamment OS(es), version(s) supportées, ...) et de tes contraintes (lib externe autorisée, ...).

Citation:

Jeudi passé en faisant des recherches sur le net je suis tombé sur un article qui parlait de faire un keep-alive avec l'envoi d'un message TCP ne contenant aucune donnée. Est ce que ça serais utilisable ?

Amha, tu vas galérer 10x plus pour un résultat plus incertain: rien ne te garantira qu'entre le dernier keepalive reçu et le moment où tu envoies le message, le serveur est toujours accessible (crash serveur, coupure réseau, ...).
28/09/2009, 16h57
lesteph

Bin chui déçu :cry: moi qui croyais que j'aurais pu utiliser l'ACK de la couche TCP simplement, bon chui p'être un peu naif des fois... :roll:

:ccool: Yes ta solution est claire, me conviens parfaitement et parait assez simple a implémenter.

Citation:

Envoyé par nouknouk

Tout dépend de ton environnement (notamment OS(es), version(s) supportées, ...) et de tes contraintes (lib externe autorisée, ...).

J'utilise l'outil de développement Builder C++ 2007 et l'application côté client et serveur tourne sous Windobe XP. P'être dans quelque temps le client devra être sur Vista (ou 7) mais... c'est pas pour demain.
28/09/2009, 17h17
bacelar

Je ne vois pas pourquoi ne pas utiliser les fonctionnalités offerte par la stack TCP/IP.
http://msdn.microsoft.com/en-us/libr...51(VS.85).aspx

Pas testé mais je ne pense pas que cela puisse contenir des surprises.
28/09/2009, 17h21
nouknouk

Citation:

Envoyé par lesteph

Bin chui déçu :cry: moi qui croyais que j'aurais pu utiliser l'ACK de la couche TCP simplement, bon chui p'être un peu naif des fois... :roll:

Les deux raisons principales qui me paraisent à l'origine du fait de ne pas pouvoir récupérer l'ACK d'un paquet envoyé:

- le protocole TCP n'envoie pas (forcément) un ACK par 'paquet' reçu (mais un ACK pour une quantité de données pouvant correspondre à plusieurs 'paquets' émis). Tu as en effet la notion de 'fenêtre glissante' ('window' dans les articles techniques anglais) qui fait que l'émetteur a le droit d'envoyer plusieurs 'paquets' à la suite sans devoir à chaque fois attendre l'ACK du 'paquet' précédent, ceci pour améliorer les délais et la bande passante utilisée.

- le protocole TCP est un protocole destiné à gérer la transmission d'un flux continu de données, pas un protocole qui gère des données paquets par paquets. La mécanique interne du protocole (et les équipements intermédiaires entre la source et la destination) a en effet toute latitude de fragmenter/regrouper des paquets de données pour rendre la transmission plus efficiente. A partir de là, puisque la notion de 'paquet de données' n'existe pas, l'existence de la notion d'ACK pour un paquet de données est compromise ;)

Citation:

J'utilise l'outil de développement Builder C++ 2007 et l'application côté client et serveur tourne sous Windobe XP. P'être dans quelque temps le client devra être sur Vista (ou 7) mais... c'est pas pour demain.

Je ne pourrai pas t'aider alors, sauf à dire qu'il existe une implémentation des 'sockets standard' relativement multi-plateforme et bien assez utilisée pour trouver de nombreux articles sur le sujet, dont celui-là ;)
28/09/2009, 17h31
nouknouk

Citation:

Envoyé par bacelar

Je ne vois pas pourquoi ne pas utiliser les fonctionnalités offerte par la stack TCP/IP.

Parce que comme dit précédemment, la notion de keepalive ne garantira pas que le message a effectivement été reçu côté serveur sauf à mettre une période de keepalive sensiblement inférieure (50% maxi) au délai maximum imposé (ici 100ms).

Et dans ce cas, on se retrouve avec un keepalive tellement faible qu'on va générer un traffic réseau 'pour rien' (dans le sens où une solution bien plus efficiente existe et donne finalement plus de garanties).

Par manque de temps j'ai encore simplifié la chose... je ferai mieux plus tard... :roll:

Je me base uniquement sur l'établissement de la connexion. Si la connexion est OK c'est qu'il n'y a aucun problème, que mon serveur la acceptée et qu'il est à l'écoute. Donc pas de câble débranché, de switch KO, de serveur planté ou...

Juste après j'envoie mes données. Bien sur il y a un risque qu'il y ait un problème entre l'établissement et l'envoi, mais sur les quelques micro-secondes qu'il y a... je pense que c'est totalement négligeable 8-)

J'ai fait des essais et il arrive quelques fois que le temps établissement de la connexion soit entre 100 et 200ms, sinon il est bien inférieur à 100ms.

J'ai utilisé la classe TTcpClient en socket non bloquante. Voici le bout de code :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 // Creat the TCP connection ClientTCP = new TTcpClient(NULL); if( ClientTCP == NULL ) return -2 ; ClientTCP->BlockMode = bmNonBlocking ; ClientTCP->RemoteHost = Host ; ClientTCP->RemotePort = IntToStr(Port); // Start connect timer Time0 = GetTickCount(); // Open Connection ClientTCP->Open(); // Wait than connection is etablished do{ Select = ClientTCP->Select( &ReadOK, &WriteOK, &Flag, 25); TimeElapsed = GetTickCount() - Time0 ; if(TimeElapsed > Timeout ){ ClientTCP->Close(); delete ClientTCP ; return -3 ; } } while( !( (Select==true)&&(WriteOK==true)&&(Flag==false) ) ); // Send Data ClientTCP->Sendln( Msg, "\r" ); ClientTCP->Close(); delete ClientTCP ; return 1 ; }
Merci à tous pour vos commentaires :ccool:

30/09/2009, 20h09
bacelar

Si vous faites une connexion pour chaque message, vous aurez des performances calamiteuses.
01/10/2009, 14h21
lesteph

Comme je l'ai noté, je ferai mieux un peu plus tard, d'autres priorités sont apparues... :calim2:

Et surtout c'est la solution la plus simple que j'ai trouvé sans besoin d'écrire des dizaines de lignes de code.
Mais si il y a d'autres solutions aussi simple et qui s'approche plus des contraintes de bases, je suis preneneur... :D

Citation:

Si vous faites une connexion pour chaque message, vous aurez des performances calamiteuses

Les performances ne sont pas si calamiteuses puisques selon mes tests le temps de connexion est quelques fois entre 100 et 200ms mais en général il est bien en dessous de 100ms. Bon je pense que le cash de Windobe y est pour quelque chose.