Ce sont DONC SNDBUF et DONC 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 tamponne les données sortantes / incomming mais j'aimerais clarifier ce sujet.
Quel est leur rôle (en général)?
S'agit-il de tampons à prise unique?
y a-t-il un lien entre les tampons de la couche Transport (le tampon TCP, par exemple) et ces tampons?
ont-ils un comportement/rôle différent lorsqu'ils utilisent des prises de courant (TCP) et lors de l'utilisation de sockets sans connexion (UDP)?
un bon article sera génial aussi.
Je l'ai googlé mais n'ai trouvé aucune information utile.
3 réponses
le préfixe " SO_ "est pour " socket option", donc oui, ce sont les réglages par socket pour les tampons par socket. Il y a 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 affecte pour contenir les données arrivant dans la socket donnée pendant le temps entre son arrivée sur le réseau et sa lecture par le programme propriétaire de cette socket. Avec TCP, si les données arrivent et que vous ne les lisez pas, le tampon va se remplir, et l'expéditeur se verra dire de ralentir (en utilisant le mécanisme de réglage de la fenêtre TCP). Pour UDP, une fois que le tampon est plein, les nouveaux paquets seront simplement rejetés.
SO_SNDBUF, je pense, uniquement les questions pour le protocole TCP (UDP, tout ce que vous envoyez va directement vers le réseau). Pour TCP, vous pouvez remplir le tampon soit si le côté distant ne lit pas (de sorte que le tampon distant devient plein, alors TCP communique ce fait à votre noyau, et votre noyau arrête d'envoyer des données, à la place l'accumuler dans le tampon local jusqu'à ce qu'il se remplisse). Ou il pourrait se remplir s'il y a un problème de réseau, et que le noyau ne reçoive 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 le tampon sortant se remplisse. Si donc, à l'avenir write() les appels à cette socket par l'application vont bloquer (ou retourner EAGAIN si vous avez défini le O_NONBLOCK option).
tout Cela est décrit dans la Réseau Unix Programmation livre.
dans Windows, le tampon d'envoi a un effet dans UDP. Si vous éjectez des paquets plus rapidement que le réseau ne peut les transmettre, vous finirez par remplir le tampon de sortie socket et SendTo échouera avec "would block". Augmenter SO_SNDBUF aidera pour cela. J'ai dû augmenter les tampons d'envoi et de réception pour un test que je faisais pour trouver le taux maximum de paquets que je pouvais envoyer entre une boîte Windows et une boîte Linux. J'aurais aussi pu gérer la taille de l'envoi en détectant le " serait bloquez le code d'erreur, dormez un peu, et retrieving. Mais augmenter la taille du tampon d'envoi était plus simple. La valeur par défaut de Windows est 8k, ce qui semble inutilement petit dans cette ère de PC avec des GB de RAM!
la recherche de Google pour "SO_RECVBUF msdn" m'a donné...
http://msdn.microsoft.com/en-us/library/ms740476(SV.85).aspx
qui répond à vos "sont-ils par socket" avec ces lignes dans les options de la table:
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
quand une implémentation Windows Sockets supporte les So_rcvbuf et SO_RCVBUF SO_SNDBUF options, une application peut demander différentes tailles de tampon (plus grande ou plus petite). L'appel à setsockopt peut réussir, même quand le implementation n'a pas fourni la totalité du montant demandé. Un application doit appeler getsockopt avec la même option pour vérifier le la taille du tampon est en fait fournie.