socket.shutdown vs socket.close

J'ai récemment vu un peu de code qui ressemblait à ceci (avec sock étant un objet socket bien sûr):

sock.shutdown(socket.SHUT_RDWR)
sock.close()

Quel est exactement le but d'appeler shutdown sur le socket puis de le fermer? Si cela fait une différence, ce socket est utilisé pour les E / S non bloquantes.

Voici une explication :

Une fois qu'un socket n'est plus nécessaire, le programme appelant peut supprimer le socket en appliquant un sous-programme de fermeture au descripteur de socket. Si un socket de livraison fiable est associé à des données lors de la fermeture, le système continue de tenter le transfert de données. Cependant, si les données ne sont toujours pas livrées, le système les ignore. Si le programme d'application n'a aucune utilisation pour les données en attente, il peut utiliser le sous-programme d'arrêt sur le socket avant de le fermer.

L'appel closeet shutdownont deux effets différents sur le socket sous-jacent.

La première chose à souligner est que le socket est une ressource dans le système d'exploitation sous-jacent et que plusieurs processus peuvent avoir un handle pour le même socket sous-jacent.

Lorsque vous l'appelez closedécrémente le nombre de descripteurs de un et si le nombre de descripteurs a atteint zéro, le socket et la connexion associée passent par la procédure de fermeture normale (en envoyant effectivement un FIN / EOF à l'homologue) et le socket est désalloué.

Ce à quoi il faut faire attention ici est que si le nombre de descripteurs n'atteint pas zéro parce qu'un autre processus a encore un descripteur sur le socket, la connexion n'est pas fermée et le socket n'est pas désalloué.

D'autre part, l'appel shutdownà la lecture et à l'écriture ferme la connexion sous-jacente et envoie un FIN / EOF à l'homologue quel que soit le nombre de processus qui ont des descripteurs sur le socket. Cependant, il ne désalloue pas le socket et vous devez toujours appeler close par la suite.

Explication de l'arrêt et de la fermeture: arrêt progressif (msdn)

Shutdown (dans votre cas) indique à l'autre extrémité de la connexion qu'il n'y a plus aucune intention de lire ou d'écrire sur le socket. Puis close libère toute mémoire associée au socket.

L'omission de l'arrêt peut entraîner la persistance du socket dans la pile des systèmes d'exploitation jusqu'à ce que la connexion ait été fermée correctement.

OMI les noms «arrêt» et «fermer» sont trompeurs, «fermer» et «détruire» souligneraient leurs différences.

il est mentionné directement dans le Socket Programming HOWTO ( py2 / py3 )

Déconnexion

À proprement parler, vous êtes censé l'utiliser shutdownsur une prise avant de vous close. Le shutdownest un avertissement à la prise à l'autre extrémité. Selon l'argument que vous lui transmettez, cela peut signifier « Je ne vais plus envoyer, mais je vais quand même écouter », ou « Je n'écoute pas, bon débarras! ». La plupart des bibliothèques de sockets, cependant, sont tellement habituées aux programmeurs qui négligent d'utiliser cette étiquette que normalement a closeest le même que shutdown(); close(). Ainsi, dans la plupart des situations, un arrêt explicite n'est pas nécessaire.

...

Ce code ci-dessus n'est-il pas faux?

L'appel de fermeture directement après l'appel d'arrêt peut faire en sorte que le noyau rejette de toute façon tous les tampons sortants.

Selon http://blog.netherlabs.nl/articles/2009/01/18/the-ultimate-so_linger-page-or-why-is-my-tcp-not-reliable, il faut attendre entre l'arrêt et le close jusqu'à ce que read renvoie 0.

il existe quelques types d'arrêt: http://msdn.microsoft.com/en-us/library/system.net.sockets.socket.shutdown.aspx . * nix est similaire.

Shutdown (1), force le socket no à envoyer plus de données

Ceci est utile dans

1- Rinçage du tampon

2- Détection d'erreur étrange

3- Protection sûre

Permettez-moi de vous expliquer plus, lorsque vous envoyez une donnée de A à B, il n'est pas garanti qu'elle soit envoyée à B, elle est uniquement garantie d'être envoyée au tampon A os, qui à son tour l'envoie au tampon B os

Donc en appelant shutdown (1) sur A, vous videz le tampon de A et une erreur est levée si le tampon n'est pas vide c'est-à-dire: les données n'ont pas encore été envoyées au pair

Cependant, cela est irréversible, vous pouvez donc le faire après avoir complètement envoyé toutes vos données et vous voulez être sûr que c'est au moins dans le tampon du système d'exploitation du pair.