Posté par SoWhat .
En réponse au message Sockets....
Évalué à 3.
En fait, je crois que c'est même la seule méthode valable quand on lit sur des sockets UDP. Un appel à 'recvfrom' lit autant de données que possible, dans la limite de l'espace mémoire fourni par l'utilisateur. Une fois l'appel à recvfrom terminé, le datagramme concerné est _perdu_. On n'est pas en TCP, mais bien en UDP. On doit lire datagramme par datagramme, contrairement à une socket TCP.
L'avantage qu'on peut y voir, c'est que si l'emetteur fait un 'sendto' de 36 octets, on est _sûr_ que le datagramme reçu par l'autre bord aurra lui aussi une taille de 36 octets. Comme on ne connait aps forcément la taille avant le lecture, on utilise souvent un buffer de 65536 octets comme paramètre de l'appel à 'recvfrom', puis on recopie les données effectivement reçues dans un buffer de taille plus appropriée (si besoin).
[^] # Re: Trop compliqué ton truc
Posté par SoWhat . En réponse au message Sockets.... Évalué à 3.
L'avantage qu'on peut y voir, c'est que si l'emetteur fait un 'sendto' de 36 octets, on est _sûr_ que le datagramme reçu par l'autre bord aurra lui aussi une taille de 36 octets. Comme on ne connait aps forcément la taille avant le lecture, on utilise souvent un buffer de 65536 octets comme paramètre de l'appel à 'recvfrom', puis on recopie les données effectivement reçues dans un buffer de taille plus appropriée (si besoin).