Socket, taille maximale ?

Bonjour

Mon problème est le suivant: je dois transmettre des données d'un processus à un autre par le biais d'une socket, en utilisant la librairie Winsock. J'utilise une socket type AF_INET, IP = 127.0.0.1 et port = 1026 pour effectuer des tests. Il se trouve que j'ai un problème lors de la l'écriture et/ou lecture sur la socket, selon la taille des données qui sont envoyées.

Le premier test que j'ai effectué fut d'envoyer 3733 octets d'un processus à l'autre. A l'aide de send et de recv, le transfert s'est correctement déroulé. Le deuxième test quant à lui fut d'envoyer 4972 octets. Et là cela n'a pas fonctionné: la valeur de retour de send() est correcte et indique bien le nombre d'octets envoyés, par contre recv() qui est bloquant n'arrive pas à récupérer les données. De plus, j'essaye seulement de lire les 4 premiers octets qui indiquent la taille du message. Même les 4 premiers octets ne semblent pas disponibles. Pour finir, j'ai effectué un dernier test qui consiste à envoyer une 2eme fois les données si celles-ci ne sont pas reçues, et la réception fonctionne lors de la 2eme écriture.

D'ou cela peut-il venir ?

Cordialement,

Julien.

Est-ce un socket de type STREAM (tcp) ou bien de type DATAGRAM (udp) ?

Il s'agit d'une socket de type STREAM.

Par contre je viens de remarquer quelque chose: la lecture d'un message sur la socket se déroule en 2 étapes. La première consiste à récupérer la taille du message qui est indiqué par les 4 premiers octets grâce à un recv de taille 4. Ensuite, la 2e étape consiste à récupérer la totalité du message grâce à la taille récupérée précédemment avec un 2eme recv. Le code est le suivant:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

ret = READ_SOCKET(p_LnDM->p_Socket.OSL_ConfSet_Client, MsgSize, 4); if(ret == 4) { /*WAIT_MS(1000);*/ memcpy(Msg, MsgSize, 4); memcpy(&MsgSizeInt, MsgSize, 4); ret = READ_SOCKET(p_LnDM->p_Socket.OSL_ConfSet_Client, Msg + 4, MsgSizeInt - 4); if(ret == (MsgSizeInt - 4)) { /* ... */ } }

---

Si je décommente le WAIT_MS(1000) qui est un macro qui correspond en fait à un Sleep d'une seconde, cela fonctionne. Mais bon, la raison m'échappe.

Julien.

WAIT_MS(1) fonctionne également. Est-ce réellement un problème de temporisation ?!

Julien.

Evidemment, il faut que tu laisses le temps à tes octets d'arriver à destination.
L'idée de réessayer d'envoyer les octets s'ils n'ont pas été lus ne sert à rien en TCP. C'est la couche de transport qui s'occupe de ça, et elle fait ça très bien.

La doc de recv sur msdn dit :
"For connection-oriented sockets (type SOCK_STREAM for example), calling recv will return as much data as is currently available—up to the size of the buffer specified."
Donc, cela sous-entend que si seulement 1 octet est dispo, tu vas récupérer un seul octet. Il faut donc que tu boucles sur recv, jusqu'à récupérer la totalité des octets que tu attends (ou qu'une erreur se produise).

Je te conseille vivement Wireshark pour examiner les packets transmis, tu verras beaucoup mieux ce qui se passe.

Edit : SOCK_STREAM se prête très bien à des flux continus de données, où l'ordre des octets est important (genre un terminal ou un transfert de fichier).
Si ton protocole est plutôt du style "requete/réponse" ponctuelle, il vaut mieux (à mon humble avis) utiliser un SOCK_DATAGRAM qui gère lui même la taille des packets à transmettre "atomiquement".

Ok, je te remercie.

Cordialement,

Julien.