Discussion :

[sympho]

Bonjour,

Y a t-il moyen de vider les buffer d'une socket suite à un envoi.

En fait j'ai un code du genre

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
//coté client
recv(sock, &buf, sizex, 0);
recv(sock, &buf, sizey, 0);
 
//coté serveur
send(sock, &buf, sizea, 0);
send(sock, &buf, sizeb, 0);

Je voudrais que chaque envoi send corresponde à une réception recv, mais il arrive que deux envoi successifs donnent lieu à une seule réception, et du coup la 2ème réception peux bloquer ou ne pas correspondre à ce qui était attendu. Y a t-il un moyen de régler cela ?

Merci

[granquet]

soit tu te met en mode non bloquant. ainsi tes appels a recv retournerons une valeur particuliere s'il n'y as rien a lire plutot que de bloquer
soit tu utilise select pour savoir s'il y'as quelque chose a lire.

[sympho]

slt,

le problème en fait n'est pas tellement de bloquer, mais plutôt sur la correspondance 1-send<->1-recv

[Emmanuel Delahaye]

slt,

le problème en fait n'est pas tellement de bloquer, mais plutôt sur la correspondance 1-send<->1-recv

C'est pas vraiment contrôlable, et je ne vois pas où est le problème.

C'est à toi de définir un protocole minimum qui permet de reconstituer tes données à l'arrivée. Genre "Les données sont des lignes de texte terminées par un '\n'"

Je pense que tu as plus un problème de conception. Explique ce que tu veux faire et le moyen utilisé pour le faire. On verra les détails de réalisation en temps voulu. Chaque chose en son temps.

[sympho]

j'ai trouvé,

pour modifier la bufferisation du noyau pour une socket, il suffit de modifier ses options SO_SNDBUF et SO_RCVBUF.

[xankow]

Bonjour,

J'ai un peu le meme probleme. Je travaille avec des robots qui doivent dialoguer avec mon serveur. Mais ils ne sont pas capable de distinguer si le message recu est compose de plusieur requettes. Ces requettes ont des tailles diferentes, et sont envoyées a de tres faibles intervales.
Du coup windows prend plusieur requettes et n'envoie qu'un seul paquet. Ca me gene enormement....

Je travaille sous visual studio framework 1.1 en c#

Toutes propositions est bonne a prendre.

[3DArchi]

Il n'y a pas beaucoup de solutions. Si ton socket est TCP, alors tu travaille en mode 'flux'. Les échanges entre le client et le serveur ne doivent pas se percevoir comme 'paquet' mais comme un flux de données. Donc, plusieurs send pourront correspondre à un nombre différent de recv. En fait, c’est non seulement au niveau de la couche TCP du récepteur que tes paquets peuvent être découpés ou agglutinés mais aussi tout le long du réseau. TCP te garantie que tout ce que tu envoi sera reçu et dans le même ordre, mais c’est un mode flux et non un mode paquet.
Si tu veux un mode paquet, deux solutions :
-> utiliser un socket UDP. Mais tu perds les avantages du mode connecté en TCP (garantie de réception, ordre garantie...).
-> Soit tu reste sur TCP mais il te faut alors définir un protocole d'échange. En général, des protocoles de types TLV ([Type][Longueur][Valeur]) sont souples et évolutifs.

[xankow]

Pourtant en TCP a partir du framework 3.0 il existe une propriete NO_DELAY qui a pour but d'nvoyer un message directement, et de ne pas le stoquer 200 milliseconde (valeur par defaut windows). Cela deconnecte l'algo de Nagle, tout simplement.

Je ne comprend pas trop pourquoi je ne pourai pas y arriver en 1.1
Je te remerci de ta reponse, je vais regarder le TLV et voir ce que je peux en tirer pour mon appli.

[nicolas.sitbon]

Pourtant en TCP a partir du framework 3.0 il existe une propriete NO_DELAY qui a pour but d'nvoyer un message directement, et de ne pas le stoquer 200 milliseconde (valeur par defaut windows). Cela deconnecte l'algo de Nagle, tout simplement.

Je ne comprend pas trop pourquoi je ne pourai pas y arriver en 1.1
Je te remerci de ta reponse, je vais regarder le TLV et voir ce que je peux en tirer pour mon appli.

C'est un forum C, rien à voir avec Windows et encore moins le .NET Framework 3.0.
De plus, c'est très mal vu de squatter un topic!