Shabang a écrit :
Citation :
Le but n'est pas de détecter les ecritures, mais les fins d'écritures. Ca permet de ne pas balancer 40 Mo de données d'un coup aux sockets qui ne sauront pas les emettre sans cafouillage... On va plutôt émettre par blocs de 30 ou 40 ko, et envoyer la suite sur reception d'une information 'fin d'ecriture'.
|
Donc si j'ai bien compris, il y a une bufferisation des donnees lors de l'envoi sur la socket, a tel point que l'ecriture peut se faire apres l'execution de la routine d'ecriture (par exemple un write(2)), et se finir eventuellement pendant le select?
|
Absolument. Il y a suffisament de buffers pour qu'un bloc pas trop gros (30..40 ko) puisse (vu de l'utilisateur) être envoyé en une fois, mais si il est vraiment énorme, on va manger énormément de ressources brutalement (pic), et ces ressources ne sont pas forcément disponibles, d'où un 'écrètage' et les pertes de données qui s'en suivent (perdre des données en émission, fait le faire quand même...). Le mécanisme de régulation est fourni par select() avec les évènements "write'.
Citation :
C'est dangereux de negliger ce phenomene pour des envois beacoup moins gros, comme des chaines de caractères de quelques dizaine d'octets (représentant un protocole de communication)?
|
En pratique, aucun risque, mais en toute rigueur, il faudrait appelet select() après tout write() de façon a syncroniser le processus (emission 'blocante')
Citation :
Ce n'est pas bloquant d'envoyer la chaine d'un seul trait avec write(2), du moment qu'en face la lecture est non bloquante?
|
En face, on ne sait pas ce qu'il y a. Effectivement, une ecriture avec write() n'est pas blocante.
Message édité par Emmanuel Delahaye le 14-05-2005 à 14:50:09
---------------
Des infos sur la programmation et le langage C: http://www.bien-programmer.fr Pas de Wi-Fi à la maison : http://www.cpl-france.org/