Discussion :

[Gawik]

Bonjour,

Je cherche des explications sur le comportement des fonction send et recv.

Dans un modèle de communication IPC par socket, est-ce normal qu'un appel à send soit bloquant si aucun appel à recv n'est réalisé ?
Par exemple, j'ai un processus Serveur qui boucle sur l'envoie d'une donnée de 6Mo et un processus client qui crée la connection mais ne fait aucun appel à recv.
J'observe que le 1er appel à send fonctionne et met ~7ms, mais le second appel à send est bloquant. Est-ce le fonctionne logique d'une socket TCP/IP ? Faut-il obligatoirement faire des appels à recv pour vider le buffer de la socket
et permette au send de transmettre de nouvelles données ?

Est-il possible de paramétrer la taille du buffer de la socket au niveau de l'OS ?
Est-il préférable de faire 1 seul appel à recv pour lire les 6Mo de données, ou est-il préférable de faire plusieurs appel à recv avec des blocs de données plus petits (64Ko, 256Ko...) ?


Merci

[Obsidian]

Bonjour,

Dans un modèle de communication IPC par socket, est-ce normal qu'un appel à send soit bloquant si aucun appel à recv n'est réalisé ? Par exemple, j'ai un processus Serveur qui boucle sur l'envoie d'une donnée de 6Mo et un processus client qui crée la connection mais ne fait aucun appel à recv. J'observe que le 1er appel à send fonctionne et met ~7ms, mais le second appel à send est bloquant. Est-ce le fonctionne logique d'une socket TCP/IP ?

En effet, c'est bien le comportement attendu. L'un des principes fondateurs de TCP est d'émuler une connexion de type flux, comme un tube, et ce même si c'est en s'appuyant sur une couche qui ne l'est pas (typiquement IP, qui fonctionne par datagrammes et dont ni l'arrivée ni l'ordre ne sont garantis).

Par contre, si ça pose problème pour différentes raisons, tu peux paramétrer explicitement ton socket pour qu'il ne soit pas bloquant. Ce n'est pas pour cela que les données seront transmises si elles ne peuvent pas l'être, mais ça te laissera le loisir de faire autre chose en attendant.

Faut-il obligatoirement faire des appels à recv pour vider le buffer de la socket et permette au send de transmettre de nouvelles données ?

Dans le principe, oui. Tu dois pouvoir vider le buffer dans certains cas particuliers, mais ça dépendra beaucoup de l'implémentation locale à ta machine et, dans tous les cas, cela n'a pas de sens de permettre à un émetteur d'envoyer une grande quantité de données vers une connexion ouverte si c'est pour les ignorer avant même de les avoir reçues.

Est-il possible de paramétrer la taille du buffer de la socket au niveau de l'OS ?

Oui, mais ce n'est probablement pas ce que tu cherches à faire. Cela va surtout être intéressant en fonction de la montée en charge et du nombre de connexions simultanées.

Est-il préférable de faire 1 seul appel à recv pour lire les 6Mo de données, ou est-il préférable de faire plusieurs appel à recv avec des blocs de données plus petits (64Ko, 256Ko...) ?

Ça, par contre, ça dépend essentiellement de ton programme. Il est tout-à-fait sûr, en soi, de faire un seul gros recv() vers un buffer correctement alloué. C'est le système lui-même qui découpera le tout en datagrammes et qui le reconstituera de l'autre côté. Par contre, d'une part, allouer 6 Mo dans un tableau sous forme de variable locale (donc dans la pile) est une hérésie. Préférer un malloc() en bonne et due forme. Ensuite, si tu peux traiter tes données à la volée, il est bien entendu recommandé d'utiliser des petits buffers.

Ensuite, si pour une raison ou une autre, la transmission se passe mal, l'appel système va échouer dans sa totalité et tu risques de devoir ré-émettre toutes tes données depuis le début.