Discussion :

[thieum74]

Bonjour,

J'utilise une socket TCP/IP tres classique.
Je fais un send d'un buffer d'une taille constante et je m'apercois que, de temps en temps, je dois faire 2 recv afin d'obtenir l'int�gralit� de mon buffer!!!

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
n=recv(sock,(char*)&buff,2964,0);
if(n!=2964)
      n+=recv(sock,(char*)&buff+n,2964-n,0);

Je pr�cise que je fais un setsockopt afin d'avoir des buffers d'envoi et de reception suffisant.

Est ce normal ???
Y a til une explication ???
Exite il un moyen de forcer le reception en 1 seul recv ???

[vincedom]

Bonjour

Moi aussi j'ai deja rencontre le meme probleme....
Je crois que c'est une question de temps de reception qui est un peu trop long.... La solus faire plusieurs recv (jusqu'a que tu es le bon nombre de bytes) .


J'en connais pas d'autre

[thieum74]

Ok,
Je suppose qu'il est inutile de jouer avec SO_RCVTIMEO et SO_SNDTIMEO...

Mais est ce que qq'un a une explication ???
Ou peut etre une solution...

[zul]

Une explication possible est peut-etre la fragmentation ? Un lien ethernet accepte des paquets de 1500 octets maximum. Si tu envoie 2394 octet d'un coup, il va falloir deux paquets pour faire passer sur ethernet.

Mais ca me parait �trange que l'on est acc�s qu'a une partie d'un message tcp ( m�me si c'est la premi�re ). Donc je ne suis pas sur.

Au passage, c'est pas tres bien de hardcod� ca dans le code. Au pire, fais un
#define MAX_SIZE 2394

ou tu peux surement utiliser sizeof(buf) ici, je ne sais pas.

Pourquoi vouloir envoyer autant d donn�e d'un coup ?

[thieum74]

Effectivement, la taille des paquets est de 1500 octets en ethernet et aussi en UDP (je crois) mais en TCP normalement il n'y a pas de taille de paquets limite... (enfin je crois...)

D'autant plus que lorsque ce phenomene se produit le premier paquet est tjr de 2920 et le second de 44 !!!!

Sinon le Hardcodage c'est juste pour l'exmple de code..., et je transmet de gros paquet car c'est une var d'�tat d'environ 150 machines pour faire une sorte de supervision... enfin bref, j'ai pas trop le choix...

[niglo]

en TCP normalement il n'y a pas de taille de paquets limite... (enfin je crois...)

Biensur qu'il y a une taille de paquet limite, c'est juste que pour toi c'est transparent. La taille est limit�e par le paquet IP (et non tcp ou udp, ca c'est le nom du protocole de transport des paquets).

Tu fais un send, et apr�s le message que tu veux envoyer est d�coup� en plusieurs paquets par le protocole choisit !!!

[Luc Hermitte]

Je suis s�r que tu n'as certainement pas voulu �crire �a.

(char*)&buff

Sinon pour ton pb, je ne saurais dire. Un probl�me de timeout peut-�tre ? Et encore il me semble que les codes de retour devraient �tre diff�rents. Le forum r�seau conviendra certainement bien mieux que le forum d'un langage qui ne sait pas ce qu'est une socket.

[zul]

Le man de recv de ma debian indique le flag

MSG_WAITALL
This flag requests that the operation block until the full
request is satisfied. However, the call may still return less
data than requested if a signal is caught, an error or discon-
nect occurs, or the next data to be received is of a different
type than that returned.

qui devrait resoudre ton probleme. Je ne sais pas si c'est portable par contre.