Delen via


Windows Sockets: Blokkering

In dit artikel en twee aanvullende artikelen worden verschillende problemen in het programmeren van Windows Sockets uitgelegd. Dit artikel bevat informatie over blokkeren. De andere problemen worden behandeld in de artikelen: Windows Sockets: Byte Ordering en Windows Sockets: Tekenreeksen converteren.

Als u klasse CAsyncSocket gebruikt of afleiden, moet u deze problemen zelf beheren. Als u klasse CSocket gebruikt of afgeleid, beheert MFC deze voor u.

Blokkeren

Een socket kan zich in de 'blokkeringsmodus' of 'niet-blokkeringsmodus' bevinden. De functies van sockets in de blokkerende modus (of synchrone) worden pas geretourneerd als ze hun actie kunnen voltooien. Dit wordt blokkeren genoemd omdat de socket waarvan de functie is aangeroepen niets kan doen , wordt geblokkeerd - totdat de aanroep terugkeert. Een aanroep van de Receive-lidfunctie kan bijvoorbeeld een willekeurige lange tijd in beslag nemen wanneer wordt gewacht totdat de verzendende toepassing de gegevens verstuurt (dit is als u werkt met CSocket of CAsyncSocket met blokkering). Als een CAsyncSocket object zich in de niet-blokkeringsmodus bevindt (asynchroon opereren), retourneert de aanroep onmiddellijk en is de huidige foutcode, die kan worden opgehaald met de GetLastError-lidfunctie, WSAEWOULDBLOCK, wat aangeeft dat de aanroep zou zijn geblokkeerd als deze niet onmiddellijk zou zijn geretourneerd vanwege de modus. (CSocket retourneert nooit WSAEWOULDBLOCK. De klasse beheert de blokkering voor u.)

Het gedrag van sockets verschilt onder 32-bits en 64-bits besturingssystemen (zoals Windows 95 of Windows 98) dan onder de 16-bits besturingssystemen (zoals Windows 3.1). In tegenstelling tot 16-bits besturingssystemen gebruiken de 32-bits en 64-bits besturingssystemen preemptive multitasking en bieden multithreading. Onder de 32-bits en 64-bits besturingssystemen kunt u uw sockets in afzonderlijke werkthreads plaatsen. Een socket in een thread kan blokkeren zonder andere activiteiten in uw toepassing te verstoren en zonder rekentijd te besteden aan de blokkering. Zie het artikel Multithreading voor informatie over multithreaded programmeren.

Opmerking

In multithreaded toepassingen kunt u de blokkerende aard van CSocket gebruiken om het ontwerp van uw programma te vereenvoudigen zonder dat dit invloed heeft op de reactiesnelheid van de gebruikersinterface. Door gebruikersinteracties in de hoofdthread en CSocket verwerking in alternatieve threads te verwerken, kunt u deze logische bewerkingen scheiden. In een toepassing die niet multithreaded is, moeten deze twee activiteiten worden gecombineerd en als één thread worden uitgevoerd, wat meestal inhoudt dat CAsyncSocket wordt gebruikt om communicatieaanvragen op verzoek af te handelen, of dat CSocket::OnMessagePending wordt overschreven om gebruikersacties tijdens een lange synchrone activiteit af te handelen.

De rest van deze discussie is bedoeld voor programmeurs die gericht zijn op 16-bits besturingssystemen:

Normaal gesproken moet u, als u gebruikmaakt CAsyncSocket, voorkomen dat u blokkeringsbewerkingen gebruikt en asynchroon werkt. In asynchrone bewerkingen, vanaf het punt waarop u een WSAEWOULDBLOCK-foutcode ontvangt nadat u bijvoorbeeld hebt aangeroepen Receive, wacht u totdat de OnReceive lidfunctie wordt aangeroepen om u te informeren dat u opnieuw kunt lezen. Asynchrone aanroepen worden gedaan door de juiste callbackmeldingsfunctie van uw socket aan te roepen, zoals OnReceive.

Onder Windows worden blokkerende aanroepen beschouwd als slechte praktijken. CAsyncSocket ondersteunt standaard asynchrone oproepen en u moet de blokkering zelf beheren met behulp van callbackmeldingen. Klasse CSocket daarentegen is synchroon. Het pompt Windows-berichten en beheert blokkeringen voor u.

Zie de Specificatie van Windows Sockets voor meer informatie over blokkeren. Zie Windows Sockets: SocketMeldingen en Windows Sockets: Afgeleid van socketklassen voor meer informatie over 'Aan'-functies.

Voor meer informatie, zie:

Zie ook

Windows Sockets in MFC
CAsyncSocket::OnSend