Partager via

Windows Sockets : Blocage

  • Article

Cet article et deux autres articles similaires décrivent plusieurs problèmes de programmation Windows Sockets. Cet article traite du blocage. Les autres problèmes sont abordés dans les articles : Windows Sockets : Ordre d’octets et Sockets Windows : Conversion de chaînes.

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

Blocage

Un socket peut être en « mode bloquant » ou en « mode non bloquant ». Les fonctions des sockets en mode bloquant (ou synchrone) ne retournent pas tant qu’elles ne peuvent pas effectuer leur action. On parle de blocage car le socket dont la fonction a été appelée ne peut rien faire, il est bloqué jusqu'à ce que l'appel soit renvoyé. Un appel à la Receive fonction membre, par exemple, peut prendre un temps arbitrairement long, car il attend que l’application d’envoi envoie (c’est-à-dire si vous utilisez CSocketou utilisez CAsyncSocket avec blocage). Si un CAsyncSocket objet est en mode non bloquant (fonctionnant de façon asynchrone), l’appel retourne immédiatement et le code d’erreur actuel, récupérable avec la fonction membre GetLastError , est WSAEWOULDBLOCK, indiquant que l’appel aurait été bloqué immédiatement en raison du mode. (CSocket ne retourne jamais WSAEWOULDBLOCK. La classe gère le blocage pour vous.)

Le comportement des sockets est différent dans les systèmes d'exploitation 32 bits et 64 bits (tels que Windows 95 ou Windows 98) et dans les systèmes d'exploitation 16 bits (comme Windows 3.1). Contrairement aux systèmes d'exploitation 16 bits, les systèmes d'exploitation 32 bits et 64 bits utilisent les travaux multitâches préemptifs et fournissent le multithreading. Sous les systèmes d'exploitation 32 bits et 64 bits, vous pouvez mettre les sockets dans des 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 passer du temps à calculer lors du blocage. Pour plus d’informations sur la programmation multithread, consultez l’article Multithreading.

Remarque

Dans les applications multithread, utilisez la nature bloquante de CSocket pour simplifier la création du programme sans affecter la réactivité de l'interface utilisateur. Lorsque vous gérez des interventions de l'utilisateur dans le thread principal et le traitement de CSocket dans d'autres threads, vous pouvez séparer ces opérations logiques. Dans une application qui n’est pas multithread, ces deux opérations doivent être associées et gérées comme un seul thread, qui correspond généralement à CAsyncSocket de sorte que vous puissiez traiter les requêtes de communication à la demande, ou en remplaçant CSocket::OnMessagePending pour gérer les actions utilisateur pendant la longue activité synchrone.

Le reste de cette discussion est destinée à des programmeurs ciblant les systèmes d'exploitation 16 bits :

Normalement, si vous utilisez CAsyncSocket, vous devez éviter d'utiliser les opérations bloquantes et préférer le mode asynchrone à la place. Dans les opérations asynchrones, à partir du point auquel vous recevez un code d’erreur WSAEWOULDBLOCK après avoir appelé Receive, par exemple, vous attendez que votre OnReceive fonction membre soit appelée pour vous avertir que vous pouvez lire à nouveau. Les appels asynchrones sont effectués en appelant la fonction de notification de rappel appropriée de votre socket, telle que OnReceive.

Sous windows, les appels bloquants sont considérés comme une mauvaise pratique. Par défaut, CAsyncSocket prend en charge les appels asynchrones et vous devez gérer le blocage vous-même à l’aide de notifications de rappel. La classe CSocket, en revanche, est synchrone. Cette méthode pompe les messages Windows et gère le blocage pour vous.

Pour plus d'informations sur les blocages, consultez la spécification Windows Sockets. Pour plus d’informations sur les fonctions « Activé », consultez Windows Sockets : Notifications de socket et Sockets Windows : Dérivation à partir de classes de socket.

Pour en savoir plus, consultez :

Voir aussi

Windows Sockets dans MFC
CAsyncSocket ::OnSend