Fonction closesocket (winsock.h)

La fonction closesocket ferme un socket existant.

Syntaxe

int closesocket(
  [in] SOCKET s
);

Paramètres

[in] s

Descripteur identifiant le socket à fermer.

Valeur retournée

Si aucune erreur ne se produit, closesocket retourne zéro. Sinon, une valeur de SOCKET_ERROR est retournée et un code d’erreur spécifique peut être récupéré en appelant WSAGetLastError.

Remarques

La fonction closesocket ferme un socket. Utilisez-le pour libérer le descripteur de socket passé dans le paramètre s . Notez que le descripteur de socket passé dans le paramètre s peut être immédiatement réutilisé par le système dès que la fonction closesocket est émise. Par conséquent, il n’est pas fiable de s’attendre à ce que d’autres références au descripteur de socket passés dans le paramètre s échouent avec l’erreur WSAENOTSOCK. Un client Winsock ne doit jamais émettre closesocket sur s simultanément avec un autre appel de fonction Winsock.

Toutes les opérations d’envoi et de réception qui se chevauchent en attente ( WSASend/ WSASendTo/ WSARecvFrom/ WSARecvFrom avec un socket superposé) émises par un thread de ce processus sont également annulées. Toute action d’événement, de routine d’achèvement ou de port d’achèvement spécifiée pour ces opérations qui se chevauchent est effectuée. Les opérations en attente qui se chevauchent échouent avec l’erreur status WSA_OPERATION_ABORTED.

Une application ne doit pas supposer que toutes les opérations d’E/S en suspens sur un socket seront toutes garanties terminées lors du retour de closesocket . La fonction closesocket lance l’annulation sur les opérations d’E/S en attente, mais cela ne signifie pas qu’une application recevra l’achèvement des E/S pour ces opérations d’E/S au moment où la fonction closesocket retourne. Par conséquent, une application ne doit pas nettoyer les ressources (structures WSAOVERLAPPED , par exemple) référencées par les demandes d’E/S en attente jusqu’à ce que les demandes d’E/S soient effectivement terminées.

Une application doit toujours avoir un appel correspondant à closesocket pour chaque appel réussi au socket afin de retourner toutes les ressources de socket au système.

La structure persistante conserve des informations sur un socket spécifique qui spécifie comment ce socket doit se comporter lorsque les données sont mises en file d’attente pour être envoyées et que la fonction closesocket est appelée sur le socket.

Le l_onoff membre de la structure persistante détermine si un socket doit rester ouvert pendant une durée spécifiée après un appel de fonction closesocket pour permettre l’envoi de données en file d’attente. Ce membre peut être modifié de deux manières :

• Appelez la fonction setsockopt avec le paramètre optname défini sur SO_DONTLINGER. Le paramètre optval détermine la façon dont le membre l_onoff est modifié.
• Appelez la fonction setsockopt avec le paramètre optname défini sur SO_LINGER. Le paramètre optval spécifie comment les membres l_onoff et l_linger sont modifiés.

Le l_linger membre de la structure persistante détermine la durée pendant laquelle , en secondes, un socket doit rester ouvert. Ce membre s’applique uniquement si le l_onoff membre de la structure persistante est différent de zéro.

Les paramètres par défaut d’un socket sont le l_onoff membre de la structure persistante est égal à zéro, ce qui indique que le socket ne doit pas rester ouvert. La valeur par défaut du membre l_linger de la structure persistante est zéro, mais cette valeur est ignorée lorsque le membre l_onoff est défini sur zéro.

Pour permettre à un socket de rester ouvert, une application doit définir le membre l_onoff sur une valeur différente de zéro et définir le membre l_linger sur le délai d’expiration souhaité en secondes. Pour désactiver l’ouverture d’un socket, une application doit uniquement définir le l_onoff membre de la structure persistante sur zéro.

Si une application appelle la fonction setsockopt avec le paramètre optname défini sur SO_DONTLINGER pour définir le membre l_onoff sur une valeur différente de zéro, la valeur du membre l_linger n’est pas spécifiée. Dans ce cas, le délai d’expiration utilisé dépend de l’implémentation. Si un délai d’expiration précédent a été établi pour un socket (en appelant précédemment la fonction setsockopt avec le paramètre optname défini sur SO_LINGER), cette valeur de délai d’expiration doit être rétablie par le fournisseur de services.

La sémantique de la fonction closesocket est affectée par les options de socket qui définissent les membres de la structure persistante .

Si le l_onoff membre de la structure LINGER est égal à zéro sur un socket de flux, l’appel closesocket retourne immédiatement et ne reçoit pas WSAEWOULDBLOCK , que le socket soit bloquant ou non bloquant. Toutefois, toutes les données mises en file d’attente pour transmission seront envoyées, si possible, avant la fermeture du socket sous-jacent. C’est également ce qu’on appelle une déconnexion ou une fermeture normale. Dans ce cas, le fournisseur Windows Sockets ne peut pas libérer le socket et d’autres ressources pendant une période arbitraire, ce qui affecte les applications qui s’attendent à utiliser tous les sockets disponibles. Il s’agit du comportement par défaut d’un socket.

Si le l_onoff membre de la structure persistante est différent de zéro et l_linger membre est égal à zéro, closesocket n’est pas bloqué même si les données en file d’attente n’ont pas encore été envoyées ou reconnues. C’est ce qu’on appelle une fermeture difficile ou abandonnée, car le circuit virtuel du socket est réinitialisé immédiatement et toutes les données non contenues sont perdues. Sur Windows, tout appel recv du côté distant du circuit échoue avec WSAECONNRESET.

Si le l_onoff membre de la structure persistante est défini sur une valeur différente de zéro et que l_linger membre est défini sur un délai d’expiration différent de zéro sur un socket bloquant, l’appel closesocket se bloque jusqu’à ce que les données restantes soient envoyées ou jusqu’à l’expiration du délai d’expiration. C’est ce qu’on appelle une déconnexion ou une fermeture normale si toutes les données sont envoyées dans le délai d’expiration spécifié dans le membre l_linger . Si le délai d’expiration expire avant que toutes les données n’ont été envoyées, l’implémentation windows Sockets met fin à la connexion avant le retour de closesocket , ce qu’on appelle une fermeture définitive ou abandonnée.

Il n’est pas recommandé de définir le l_onoff membre de la structure persistante sur une valeur différente de zéro et le membre l_linger avec un intervalle de délai d’expiration différent de zéro sur un socket non bloquant. Dans ce cas, l’appel à closesocket échoue avec une erreur WSAEWOULDBLOCK si l’opération de fermeture ne peut pas être effectuée immédiatement. Si closesocket échoue avec WSAEWOULDBLOCK , le handle de socket est toujours valide et aucune déconnexion n’est lancée. L’application doit appeler à nouveau closesocket pour fermer le socket.

Si le l_onoff membre de la structure persistante est différent de zéro et que le membre l_linger est un intervalle de délai d’expiration différent de zéro sur un socket bloquant, le résultat de la fonction closesocket ne peut pas être utilisé pour déterminer si toutes les données ont été envoyées à l’homologue. Si les données sont envoyées avant l’expiration du délai d’expiration spécifié dans le membre l_linger ou si la connexion a été abandonnée, la fonction closesocket ne retourne pas de code d’erreur (la valeur de retour de la fonction closesocket est zéro).

L’appel closesocket ne se bloque que jusqu’à ce que toutes les données soient remises à l’homologue ou que le délai d’expiration expire. Si la connexion est réinitialisée car le délai d’expiration expire, le socket ne passe pas à l’état TIME_WAIT. Si toutes les données sont envoyées dans le délai imparti, le socket peut passer à l’état TIME_WAIT.

Si le l_onoff membre de la structure persistante est différent de zéro et que le membre l_linger est un délai d’expiration zéro sur un socket bloquant, un appel à closesocket réinitialisera la connexion. Le socket ne passe pas à l’état TIME_WAIT.

La fonction getsockopt peut être appelée avec le paramètre optname défini sur SO_LINGER pour récupérer la valeur actuelle de la structure persistante associée à un socket.

Voici un résumé du comportement de closesocket :

• Si le l_onoff membre de la structure LINGER est égal à zéro (valeur par défaut pour un socket), closesocket retourne immédiatement et la connexion est normalement fermée en arrière-plan.
• Si le membre l_onoff de la structure persistante est défini sur une valeur différente de zéro et que le membre l_linger est défini sur zéro (aucun délai d’expiration), closesocket retourne immédiatement et la connexion est réinitialisée ou arrêtée.
• Si le l_onoff membre de la structure persistante est défini sur une valeur différente de zéro et que le membre l_linger est défini sur un délai d’expiration différent de zéro :– Pour un socket bloquant, ferme le bloc jusqu’à ce que toutes les données soient envoyées ou que le délai d’expiration expire.

  : pour un socket non bloquant, closesocket retourne immédiatement indiquant un échec.

Pour plus d’informations , consultez Arrêt normal, Options persistantes et Fermeture de socket pour plus d’informations.

Remarques pour les sockets IrDA

N'oubliez pas les éléments suivants :

• Le fichier d’en-tête Af_irda.h doit être inclus explicitement.
• Les options persistantes standard sont prises en charge.
• Bien qu’IrDA ne fournisse pas de fermeture normale, IrDA différera la fermeture jusqu’à ce que les files d’attente de réception soient vidées. Ainsi, une application peut envoyer des données et appeler immédiatement la fonction de socket , et être certain que le récepteur copiera les données avant de recevoir un message FD_CLOSE.

Remarques relatives au guichet automatique

Voici les problèmes importants associés à la désactivation de la connexion lors de l’utilisation du mode de transfert asynchrone (ATM) et de Windows Sockets 2 :

• L’utilisation des fonctions closesocket ou d’arrêt avec SD_SEND ou SD_BOTH entraîne l’envoi d’un signal RELEASE sur le canal de contrôle. En raison de l’utilisation par atm de canaux de signal et de données distincts, il est possible qu’un signal RELEASE atteigne l’extrémité distante avant que la dernière des données atteigne sa destination, ce qui entraîne une perte de ces données. Une solution possible consiste à programmer un délai suffisant entre les dernières données envoyées et les appels de fonction closesocket ou shutdown pour un socket ATM.
• La demi-fermeture n’est pas prise en charge par ATM.
• Les déconnexions abandonnées et normales entraînent l’envoi d’un signal RELEASE avec le même champ de cause. Dans les deux cas, les données reçues à l’extrémité distante du socket sont toujours remises à l’application. Pour plus d’informations , consultez Arrêt normal, Options persistantes et Fermeture de socket .

Windows Phone 8 : cette fonction est prise en charge pour les applications Windows Phone Store sur Windows Phone 8 et versions ultérieures.

Windows 8.1 et Windows Server 2012 R2 : cette fonction est prise en charge pour les applications du Windows Store sur Windows 8.1, Windows Server 2012 R2 et versions ultérieures.

Configuration requise

Voir aussi

Arrêt normal, options persistantes et fermeture de socket

WSAAsyncSelect

WSADuplicateSocket

WSAOVERLAPPED

Winsock Functions

Référence Winsock

Accepter

getsockopt

ioctlsocket

S' attarder

setsockopt

socket