2010-11-23 9 views
21

Pouvez-vous me expliquer ce sont exactement SO_SNDBUF et SO_RECVBUF options? OK, pour une raison quelconque, le système d'exploitation tamponne les données sortantes/entrantes, mais je voudrais clarifier ce sujet.Que sont SO_SNDBUF et SO_RECVBUF

Quel est leur rôle (généralement)?

S'agit-il de tampons par socket?

Existe-t-il une connexion entre les tampons de la couche de transport (le tampon 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 génial aussi.

Je l'ai googlé mais je n'ai trouvé aucune information utile.

Répondre

3

Recherche 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 de la table 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 and SO_SNDBUF 
When a Windows Sockets implementation supports the SO_RCVBUF and SO_SNDBUF options, an application can request different buffer sizes (larger or smaller). The call to setsockopt can succeed even when the implementation did not provide the whole amount requested. An application must call getsockopt with the same option to check the buffer size actually provided. 
49

Le préfixe "SO_" est pour "" socket option ", 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 à l'échelle du système. Est plus simple à comprendre: c'est la taille du buffer que le noyau alloue pour maintenir les données arrivant dans le socket donné pendant le temps qu'il passe entre le réseau et le programme qui le possède . Avec TCP, si les données arrivent et que vous ne les lisez pas, le tampon se remplira, et l'expéditeur devra ralentir (en utilisant le mécanisme de réglage de la fenêtre TCP). Pour UDP, une fois le tampon saturé, les nouveaux paquets seront simplement supprimés.

SO_SNDBUF, je pense, seulement des questions pour TCP (en UDP, tout ce que vous envoyez va directement sur le réseau). Pour TCP, vous pouvez remplir la mémoire tampon si le côté distant ne lit pas (pour que le tampon distant soit plein, 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 remplit). Ou il pourrait se remplir s'il y a un problème de réseau, et le noyau n'obtient pas de remerciements pour les données qu'il envoie. Il ralentira alors l'envoi de données sur le réseau jusqu'à ce que, finalement, le tampon sortant se remplisse. Si c'est le cas, les appels write() futurs à cette socket par l'application bloquent (ou renvoient EAGAIN si vous avez défini l'option O_NONBLOCK).

Tout ceci est décrit dans le livre Unix Network Programming.

7

Sous Windows, le tampon d'envoi a un effet dans UDP. Si vous envoyez des paquets plus vite que le réseau ne peut les transmettre, vous finirez par remplir le tampon de sortie du socket et SendTo échouera avec "would block". Augmenter SO_SNDBUF aidera avec ceci. J'ai dû augmenter à la fois les tampons d'envoi et de réception pour un test que je faisais pour trouver le débit de paquets maximum que je pouvais envoyer entre une machine Windows et une machine Linux.J'aurais pu aussi gérer la taille d'envoi en détectant le code d'erreur "would block", en dormant un peu et en réessayant. Mais le pompage de la taille du tampon d'envoi était plus simple. La valeur par défaut dans Windows est 8K, ce qui semble inutilement petit dans cette ère de PC avec des Go de RAM!

Questions connexes