Notes
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Cet article et deux articles complémentaires expliquent plusieurs problèmes dans la 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. Cela est appelé blocage, car le socket dont la fonction a été appelée ne peut rien faire — est bloqué — jusqu’à ce que l’appel retourne. 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 des systèmes d’exploitation 32 bits et 64 bits (tels que Windows 95 ou Windows 98) que 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 un multithreading. Sous les systèmes d’exploitation 32 bits et 64 bits, vous pouvez placer vos sockets dans des threads de travail distincts. Un socket dans un thread peut bloquer sans interférer avec d’autres activités dans votre application et sans passer du 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 bloquante de la conception de CSocket votre programme sans affecter la réactivité de l’interface utilisateur. En gérant les interactions utilisateur dans le thread principal et CSocket le traitement dans d’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 en tant que thread unique, ce qui signifie généralement que CAsyncSocket vous pouvez gérer les demandes de communications à la demande, ou remplacer CSocket::OnMessagePending pour gérer les actions utilisateur pendant une longue activité synchrone.
Le reste de cette discussion concerne les programmeurs ciblant des systèmes d’exploitation 16 bits :
Normalement, si vous utilisez CAsyncSocket, vous devez éviter d’utiliser des opérations bloquantes et fonctionner de manière 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 des pratiques incorrectes. 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. Il pompe les messages Windows et gère le blocage pour vous.
Pour plus d’informations sur le blocage, 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 plus d’informations, consultez :