Que sont SO_SNDBUF et SO_RECVBUF
Pouvez-vous m'expliquer ce que sont exactement SO_SNDBUF et SO_RECVBUF options?
OK, pour une raison quelconque, le système d'exploitation met en mémoire tampon les données sortantes/entrantes, mais je voudrais clarifier ce sujet.
Quel est leur rôle (en général)?
S'agit-il de tampons par socket?
Existe-t-il une connexion entre les tampons de la couche Transport (le TCP, par exemple) et ces tampons?
Ont-ils un comportement/rôle différent lors de l'utilisation de sockets de flux (TCP) et lors de l'utilisation de sockets sans connexion (UDP)?
Un bon article sera super aussi.
Je l'ai recherché sur Google, mais je n'ai trouvé aucune information utile.
Le préfixe "SO_" est pour "option socket", donc oui, ce sont des paramètres par socket pour les tampons par socket. Il existe généralement des valeurs par défaut et des valeurs maximales pour l'ensemble du système.
SO_RCVBUF Est plus simple à comprendre: c'est la taille du tampon que le noyau alloue pour contenir les données arrivant dans le socket donné pendant le temps entre leur arrivée sur le réseau et quand il est lu par le programme qui le possède. prise. Avec TCP, si des données arrivent et que vous ne les lisez pas, le tampon se remplira et l'expéditeur sera invité à ralentir (en utilisant TCP mécanisme d'ajustement de la fenêtre). Pour UDP, une fois le tampon est plein, les nouveaux paquets seront simplement jetés.
SO_SNDBUF, Je pense, ne compte que pour TCP (en UDP, tout ce que vous envoyez va directement au réseau). Pour TCP, vous pouvez remplir le tampon soit si la télécommande côté ne lit pas (pour que le tampon distant soit plein, alors TCP communique ce fait à votre noyau, et votre noyau arrête d'envoyer des données, au lieu de les accumuler dans le tampon local jusqu'à ce qu'il se remplisse) . Ou il pourrait se remplir en cas de problème de réseau, et le noyau ne reçoit pas d'accusé de réception pour les données qu'il envoie. Il ralentira ensuite l'envoi de données sur le réseau jusqu'à ce que, finalement, le tampon sortant se remplisse. Si c'est le cas, les futurs appels de write() à ce socket par l'application seront bloqués (ou renverront EAGAIN si vous avez défini l'option O_NONBLOCK).
Tout cela est mieux décrit dans le livre nix Network Programming .
Sous Windows, le tampon d'envoi a un effet dans UDP. Si vous diffusez des paquets plus rapidement que le réseau ne peut les transmettre, vous finirez par remplir le tampon de sortie du socket et SendTo échouera avec "bloquerait". Augmenter SO_SNDBUF aidera à cela. J'ai dû augmenter à la fois les tampons d'envoi et de réception pour un test que je faisais pour trouver le taux de paquets maximum que je pouvais envoyer entre une boîte Windows et une boîte Linux. J'aurais également pu gérer la taille de l'envoi en détectant le code d'erreur "bloquerait", en dormant un peu et en réessayant. Mais augmenter la taille du tampon d'envoi était plus simple. La valeur par défaut dans Windows est 8K, ce qui semble inutilement petit à l'ère des PC avec Go de RAM!
La recherche sur Google pour "SO_RECVBUF msdn" m'a donné ...
http://msdn.Microsoft.com/en-us/library/ms740476 (VS.85) .aspx
qui répond à vos "sont-ils par socket" avec ces lignes du tableau des options:
SO_RCVBUF int Specifies the total per-socket buffer space reserved for receives.
SO_SNDBUF int Specifies the total per-socket buffer space reserved for sends.
Avec plus de détails plus tard:
SO_RCVBUF et SO_SNDBUF
Lorsqu'une implémentation Windows Sockets prend en charge les options SO_RCVBUF et SO_SNDBUF, une application peut demander différentes tailles de mémoire tampon (plus grandes ou plus petites). L'appel à setsockopt peut réussir même lorsque l'implémentation n'a pas fourni le montant total demandé. Une application doit appeler getsockopt avec la même option pour vérifier la taille du tampon réellement fournie.