Discussion :

[lesteph]

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

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

[nouknouk]

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.

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.

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.

[Mac LAK]

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.

[loufoque]

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

[nouknouk]

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 !

, 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).

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

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

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

[Mac LAK]

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.

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

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

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

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