Windows-Sockets: Blockieren
In diesem Artikel und zwei Begleitartikeln werden mehrere Probleme bei der Programmierung von Windows Sockets erläutert. In diesem Artikel wird die Blockierung behandelt. Die anderen Probleme werden in den Artikeln behandelt: Windows Sockets: Byte-Sortierung und Windows Sockets: Konvertieren von Zeichenfolgen.
Wenn Sie die Klasse CAsyncSocket verwenden oder von dieser ableiten, müssen Sie diese Probleme selbst verwalten. Wenn Sie die Klasse CSocket verwenden oder ableiten, verwaltet MFC sie für Sie.
Blockierung
Ein Socket kann sich im "Blockierungsmodus" oder im "Nichtblockierungsmodus" befinden. Die Funktionen von Sockets im Blockierungsmodus (oder synchron) werden erst zurückgegeben, wenn sie ihre Aktion abschließen können. Dies wird als Blockierung bezeichnet, da der Socket, dessen Funktion aufgerufen wurde, nichts ausführen kann – wird blockiert , bis der Aufruf zurückgegeben wird. Ein Aufruf der Receive Memberfunktion kann z. B. eine willkürlich lange Zeit dauern, bis die sendende Anwendung gesendet wird (dies ist der Fall, wenn Sie die Anwendung verwenden CSocketoder mit Blockierung verwenden CAsyncSocket ). Wenn sich ein CAsyncSocket Objekt im Nichtblockingmodus befindet (asynchron ausgeführt), wird der Aufruf sofort und der aktuelle Fehlercode zurückgegeben, der mit der GetLastError-Memberfunktion abgerufen werden kann, ist WSAEWOULDBLOCK, der angibt, dass der Aufruf aufgrund des Modus nicht sofort zurückgegeben wurde. (CSocket gibt nie WSAEWOULDBLOCK zurück. Die Klasse verwaltet die Blockierung für Sie.)
Das Verhalten von Sockets unterscheidet sich unter 32-Bit- und 64-Bit-Betriebssystemen (z. B. Windows 95 oder Windows 98) als unter 16-Bit-Betriebssystemen (z. B. Windows 3.1). Im Gegensatz zu 16-Bit-Betriebssystemen verwenden die 32-Bit- und 64-Bit-Betriebssysteme präemptives Multitasking und bieten Multithreading. Unter den 32-Bit- und 64-Bit-Betriebssystemen können Sie Ihre Sockets in separate Arbeitsthreads einfügen. Ein Socket in einem Thread kann blockiert werden, ohne andere Aktivitäten in Ihrer Anwendung zu beeinträchtigen und keine Berechnungszeit für die Blockierung zu verbringen. Informationen zur Multithread-Programmierung finden Sie im Artikel Multithreading.
Hinweis
In Multithread-Anwendungen können Sie die Blockierungsform CSocket verwenden, um das Design Ihres Programms zu vereinfachen, ohne die Reaktionsfähigkeit der Benutzeroberfläche zu beeinträchtigen. Durch die Behandlung von Benutzerinteraktionen im Standard Thread und CSocket der Verarbeitung in alternativen Threads können Sie diese logischen Vorgänge trennen. In einer Anwendung, die nicht multithreaded ist, müssen diese beiden Aktivitäten kombiniert und als einzelner Thread behandelt werden. Dies bedeutet CAsyncSocket in der Regel, dass Sie Kommunikationsanforderungen bei Bedarf verarbeiten oder außer Kraft setzen CSocket::OnMessagePending können, um Benutzeraktionen während einer langen synchronen Aktivität zu verarbeiten.
Der Rest dieser Diskussion richtet sich an Programmierer für 16-Bit-Betriebssysteme:
Normalerweise sollten Sie bei Verwendung CAsyncSocketvon Blockierungsvorgängen vermeiden und stattdessen asynchron arbeiten. Bei asynchronen Vorgängen, ab dem Sie nach dem Aufruf einen WSAEWOULDBLOCK-Fehlercode erhalten, warten Sie beispielsweise, bis Die OnReceive Memberfunktion aufgerufen wird, um Sie darüber zu informieren, dass Sie erneut lesen Receivekönnen. Asynchrone Aufrufe erfolgen durch Aufrufen der entsprechenden Rückrufbenachrichtigungsfunktion Ihres Sockets, z . B. OnReceive.
Unter Windows gilt das Blockieren von Anrufen als schlechte Methode. Standardmäßig unterstützt CAsyncSocket asynchrone Aufrufe, und Sie müssen die Blockierung selbst mithilfe von Rückrufbenachrichtigungen verwalten. Klassen-CSocket hingegen ist synchron. Es pumpen Windows-Nachrichten und verwaltet die Blockierung für Sie.
Weitere Informationen zum Blockieren finden Sie in der Windows Sockets-Spezifikation. Weitere Informationen zu "Ein"-Funktionen finden Sie unter Windows Sockets: Socketbenachrichtigungen und Windows-Sockets: Ableiten von Socketklassen.
Weitere Informationen finden Sie unter: