Bonjour  
 
Voici mon problême :  
 
Si j'envoie successivement par l'intermédiare de la méthode send() 2 trames, la première trame est bien envoyé immédiatement mais la deuxième est envoyée seulement après réception de l'ACK correspondant à la première trame ce qui peut prendre un certain temps.
 
Est-il possible d'envoyer ces deux messages d'affiler sans attendre l'ACK?
 
En espérant avoir été clair.
 
Merci d'avance

il n'y pas de notion de trames au niveau API de TCP. Seulement (et c'est sans doute configurable et dépendant du système), chaque send faire transmettre un nouveau segment. Pour s'en sortir, c'est simple : il suffit de regarder sa documentation, tu auras sans doute un flags MSG_MORE pour ton send. Ça donnera la possibilité d'envoyer un seul segment pour deux appels.
 
Mais ce que tu décris est sans doute faux. J'y connais rien à Windows, mais si sa pile IP vaut quelqu'un chose, alors TCP ne fonctionne pas comme ça. Il est capable d'envoyer plusieurs segments sans attendre d'ACK. Ce que tu vois n'est que ponctuelle, sauf sous certaines conditions, TCP ne va pas attendre un ACK pour expédier un nouveau segment.
 
Bref, oublie. Documente toi sur ta fonction send.
 
send('G', 0)
send('E', 0)
send('T', 0)
 
-> sans doute 3 segments
 
send('G', MSG_MORE)
send('E', MSG_MORE)
send('T', 0)
 
-> sans doute 1 seul segment
 
(tout cela dépend de beaucoup de paramètres, mais ça devrait tendre vers ce comportement)

sinon tu n'a qu'à juste aggréger tes messages en un seul.

+1
c'est le windowing ou sliding window ce dont tu parles.
 
edit : TCP fourni une manière sûre de transmettre des données bout en bout sur un canal. le windowing se fait en couche 3, tu ne peux donc pas y accéder comme celà (pense au nombre de routeurs/switch que ton segment va traverser...)

 
Effectivement j'ai vu que dans la couche TCP il y avait le champ "Fenêtre". Mais même si ce champ est supérieur à 1 dans mon cas, le deuxième send est transmis seulement après la réception de l'ACK, donc y a-t-il un lien entre ce champ et mon problême?

c'est le récepteur qui fournit la taille de la fenêtre, en octet, de la quantité d'info qu'il est d'accord de recevoir. pour éviter la congestion, cette fenêtre part de 1, puis double jusqu'à atteindre la seuil critique.
 
bref, tu ne peux pas agir là dessus

non 4.
 
Et ce n'est pas un problème de fenêtre ici, c'est juste ce qui se passe entre l'applicatif et TCP qui n'est pas ce qui est souhaité. Avec un MSG_MORE ou un gros send, on a ce qu'on veut exactement. Pas la peine de mettre les mains dans le cambouis, ça n'est pas la solution.

oui mais dans mon cas la fenêtre du récepteur est égale à 20000...????

OK je regroupe mes messages et je les envoie en une fois, comme ca je ne rencontre plus le problème auquel je suis confronté. Mais il n'y a pas un autre moyen qui me permette d'envoyer des messages sans attendre forcément l'ACK?

 
Pour info et pour culture personnelle, la fenêtre est utilisé dans le cas ou l'on envoie un message important et que celui-ci nécessite d'être découpé, c'est ca ?

oui 4 pardon.  
 
non pour les problèmes de congestion / gestion de flux

Ba mon problême s'apparente à un problème de gestion de flux, non?

mais arrêtez putain ! ça n'a rien à voir ! si TCP tu lui dit d'envoyer dès que possible, il le fait. Et donc il va pas aggréger tes send.  Documentes toi sur MSG_MORE et arrêtez vos conneries sur les windows et autres gestions de flux. Le problème est applicatif.

pas vraiment non. c'est pas ce qu'on entend habituellement par congestion ou régulation de flux...

non. tout le temps. parce que justement TCP n'est pas un ping-pong  1 send = 1 ack. C'est trop long à expliquer, documente toi.

et sans t'offenser : tu devrais peut-être complètement ignorer tout ça, car ça n'est certainement pas un problème dans ton application. Vue ta connaissance limitée de TCP, j'aimerais savoir ce qui te fais lui jeter la pierre. Les implémentations TCP même de Windows sont correctes. Bref, ça ressemble un peu à de la branlette intellectuel ton truc
 
Fais des send tous bêtes, sans te préoccuper du reste, et ça fonctionnera de manière quasi-optimale. Envoie tes paquets de données sans trop de poser de questions. Du moment que tu ne fais pas du char par char ... et même si tu le faisais, ta pile TCP s'en accomoderait sans problème et optimiserait ça au point que tu n'y verrais pas la différence.
 
Mais si tu as un proto par dessus TCP, c'est certain que c'est meilleur si au lieu de faire :
send(header)
send(body)
 
tu fais send(header + body)
 
mais ça n'est certainement pas critique dans ton cas à priori.

 
Au lieu de prendre les autres pour des cons, tu ferais de leur expliquer toi qui a l'air si fort...
 
Concernant mon problème il s'agissait du "Nagle Agorithm" à désactiver pour pouvoir envoyer des trames sans attante de l'ACK
 
sur ce    

Va paître. Je crois que j'ai pas arrêté d'expliquer sur tout ce topic. Nagle c'est pas du tout le problème. C'est d'ailleurs complètement l'inverse. L'algorithme a justement pour but d'éviter les petits paquets. Alors quand tu parles de le désactiver, c'est du foutage de gueule. Tu sais même ce qu'est Nagle, t'as juste googler un peu et lu en diagonal. Alors documente toi un peu bordel. T'y connais rien en TCP, et quand on te dit que le problème n'est pas TCP, tu n'en fais rien. Tout un topic pour continuer à te branler avec TCP alors que le problème est applicatif. C'est pas la peine de demander de l'aide pour ne rien en faire.
Mais bon, si ça te satisfait une solution mytho ...

 
 
Y a pas a dire tu es un vrai champion. mais si ca te fais plaisir de dire que tu as raison je ne vais pas te contredire, normal tu es le big-boss du réseau. Maintenant mon probleme c'était bien Nagle que tu le veuille ou non et si  je préfere les performances au détriment de l'optimisation de la bande passante, cela ne regarde que moi.
 
Continue à prendre les autres pour des cons, t'as raison, tu es le seul a détenir la vérité.
Allez @+ champion

Perso je dirais que si tu veux du TCP sans TCP t'es mal barré.
 
Par contre l'UDP ne correspondrais pas plus à ton besoin ?

rien à voir

 
1-L'application host fonctionne en TCP, donc j'utilise tCP pour mon appli.
2-mes paquets transmis sont assurés de bien arriver à destination, donc pour moi c'est bien du tcp non?
3-j'ai des contraintes de performances qui m'obligent à transférer immédiatement les messages dès la commande SEND appliquée
 
c'est tout

1 Dommage Éliane !  
Par curiosité c'est qule type d'équipement ?
 
2 vi
 
3 c'est pour ça que je te parle d'UDP car pour simplifier :
UDP : pas fiable/rapide
TCP : fiable/lent
 
il ya toujours un prix à payer !

lent, lent. t'es dur là. le débit utile est de 90% pour UDP 70-80 pour TCP (de mémoire)

ok je corrige
 
c'est relatif