Partager via


Windows Sockets : Bloquer

Cet article et deux éléments auxiliaires expliquent plusieurs problèmes relatifs à la programmation Windows Sockets.Cet article décrit le blocage.Les autres problèmes sont décrites dans les articles : Windows Sockets : L'ordre d'octet et Windows Sockets : convertir des chaînes.

Si vous utilisez ou dérivez de la classe CAsyncSocket, vous devrez gérer ces problèmes vous-même.Si vous utilisez ou dérivez de la classe CSocket, MFC les gère pour vous.

Bloquer

Un socket peut être « blocage de le mode » ou « mode non bloquant. » Les fonctions des sockets en mode de blocage (ou synchrone) ne retournent pas jusqu'à ce qu'ils puissent effectuer l'action.Il s'agit de blocage car le socket dont la fonction a été appelée ne peut rien — est bloqué — jusqu'à ce que l'appel.Un appel à la fonction membre de Receive , par exemple, peut prendre du temps arbitrairement bon se termine lorsqu'il attend l'application émettrice d'envoyer (c'est si vous utilisez CSocket, ou à l'aide de CAsyncSocket avec le blocage).Si un objet d' CAsyncSocket est en mode sans blocage (fonctionnant de façon asynchrone), l'appel est retourné immédiatement et un code d'erreur actuel, récupérable avec la fonction membre de GetLastError , est WSAEWOULDBLOCK, indiquant que l'appel se serait bloqué l'a effectué ne pas retourner immédiatement en raison de le mode.(CSocket ne retourne jamais WSAEWOULDBLOCK.La classe gère le blocage pour vous.)

Le comportement des sockets est différent de celui dans les systèmes d'exploitation 32 bits et 64 bits (tels que Windows 95 ou Windows 98) que sous les systèmes d'exploitation 16 bits (tels que Windows 3.1).Contrairement aux systèmes d'exploitation 16 bits, les systèmes d'exploitation 32 bits et 64 bits utilisent le multitâche préemptif et fournissent le multithreading.Sous les systèmes d'exploitation 32 bits et 64 bits, vous pouvez placer vos sockets dans les threads de travail distincts.Un socket dans un thread peut se bloquer sans interférer avec d'autres activités dans votre application et sans utiliser le temps de calcul sur le blocage.Pour plus d'informations sur la programmation multithread, consultez l'article multithreading.

[!REMARQUE]

Dans les applications multithread, vous pouvez utiliser la nature de blocage d' CSocket pour simplifier votre conception de programme sans affecter la réactivité de l'interface utilisateur.En gérant les interventions de l'utilisateur dans le thread principal et CSocket traitement dans les autres threads, vous pouvez séparer ces opérations logiques.Dans une application qui n'est pas multithread, ces deux activités doivent être combinées et gérées comme un thread unique, qui signifie habituellement à l'aide de CAsyncSocket vous pouvez traiter les requêtes de communications à la demande, ou substituant CSocket::OnMessagePending pour gérer des actions de l'utilisateur pendant l'activité synchrone longue.

Le reste de cette rubrique est pour les programmeurs qui ciblent des systèmes d'exploitation 16 bits :

Normalement, si vous utilisez CAsyncSocket, vous devez éviter d'utiliser bloquer les opérations et d'utilisation de façon asynchrone à la place.Dans les opérations asynchrones, du point auxquelles vous recevez un code d'erreur de WSAEWOULDBLOCK après avoir appelé Receive, par exemple, vous attendez que votre fonction membre d' OnReceive soit appelée pour vous informer que vous pouvez lire à nouveau.Les appels asynchrones sont apportées par le processus appelant la fonction de notification de rappel appropriée de votre socket, telle qu' OnReceive.

Sous windows, qui bloque des appels sont considérés comme incorrecte pratique.Par défaut, les appels de support de CAsyncSocket , et vous devez gérer le blocage vous-même en utilisant des notifications de rappel.La classe CSocket, en revanche, est synchrone.Elle consomme des messages windows et gère le blocage pour vous.

Pour plus d'informations sur le blocage, consultez la spécification de Windows Sockets layer).Pour plus d'informations sur les fonctions " ON ", consultez Windows Sockets : notifications de socket et le Windows Sockets : Dérivent des classes de sockets.

Pour plus d'informations, consultez :

Voir aussi

Référence

CAsyncSocket::OnSend

Concepts

Windows Sockets dans MFC