[gull] Socket

[Marc SCHAEFER]

On Fri, Sep 24, 2004 at 08:52:32AM +0200, Blaise Vogel wrote:
> En résumé je ne comprends pas le comportement du receive. Que se passe-t-il a 
> ce moment, la fonction ne retourne-t-elle que le(s) paquets déjà reçus ? Dans 
> ce cas a quoi sert le bit de FIN de l'en tête TCP ?

TCP ne garantit absolument pas que la taille envoyée soit la taille
reçue. Il se peut même d'ailleurs que la fonction write(2) retourne un
compte de byte plus petit si le tampon est plein. Il faut alors boucler
jusqu'à ce que tous les bytes soient émis.  Il y a eu une discussion sur
cela récemment.

De plus, TCP incorpore divers algorithmes qui sont censés augmenter la
performance. Notamment, l'algorithme NAGLE essaie d'éviter d'envoyer
chaque touche du clavier dans un datagramme TCP différent (overhead de
48 bytes, de mémoire!).

Il est possible d'indiquer à la couche TCP du destinataire d'envoyer
immédiatement les données à la couche de traitement, avec le flag
PUSH. Probablement que sous UNIX un PUSH est envoyé si l'on
fait un flush(2) suffisamment vite (?).

Mais dépendre de tailles envoyées ne fonctionne pas en TCP. Cela peut
fonctionner en UDP, mais alors dans ce cas on dépend du MTU minimum
(sauf fragmentation) comme taille de données maximum.

Le mieux est donc d'incorporer une structuration des données (entête,
longueur, éventuel CRC) dans les données mises à disposition de TCP.

Le bit FIN signifie qu'aucune données ne sera plus envoyé dans cette
direction de transmission. C'est l'équivalent du close(2) ou
shutdown(2).

Si l'on utilise les fonctions de stdio (fwrite(3), etc), un buffering
intermédiaire, configurable, est également ajouté au problème.