Rozhraní Windows Sockets: blokování
Tento článek a články dva Průvodce vyhledáváním popisují několik problémů v programování rozhraní Windows Sockets.Tento článek se vztahuje na blokování.Další problémy, které jsou zahrnuty v článcích: rozhraní Windows Sockets: objednávání bajt a rozhraní Windows Sockets: převod řetězců.
Pokud nepoužíváte nebo odvozena od třídy CAsyncSocket, bude nutné spravovat tyto problémy sami.Pokud nepoužíváte nebo odvozena od třídy CSocket, MFC spravuje, je pro vás.
Blokování
Soket lze v "blokování" nebo "neblokový režimu." Funkce v režimu blokování (nebo synchronní) soketů nevrací až do jejich dokončení jejich akce.To se nazývá blokování, protože soket, jejichž funkce byla volána nemohou nijak – je blokován – dokud volání vrátí.Volání příjem členské funkce, například může trvat libovolně dlouho dokončit, protože čeká odesílající aplikace odeslat (se jedná, pokud používáte CSocket, nebo pomocí CAsyncSocket s blokováním).Pokud CAsyncSocket je objekt v neblokový režimu (provozní asynchronně), vrátí volání okamžitě a aktuální kód chyby, vyhledatelné s GetLastError členské funkce je WSAEWOULDBLOCK, označující by blokováno volání byl okamžitě nevrátí z režimu.(CSocket nikdy vrátí WSAEWOULDBLOCK.Třída spravuje blokování automaticky.)
Chování soketů se liší podle 32bitové a 64bitové operační systémy (například Windows 95 nebo Windows 98) než v 16bitové operační systémy (například Windows 3.1).Na rozdíl od 16bitové operačních systémů 32bitové a 64bitové operační systémy pomocí preemptivní multitasking a poskytují multithreading.V 32bitových a 64bitových operačních systémech můžete umístit do samostatných pracovních podprocesů aplikace soketů.Soket v podprocesu můžete blokovat bez zasahování jiné činnosti v aplikaci a výpočetní čas tráví blokování.Informace o programování s více podprocesy, naleznete v článku při souběžném.
[!POZNÁMKA]
Ve víceprocesových aplikacích používáte blokování povahu CSocket zjednodušit návrh vašeho programu bez odezvy uživatelského rozhraní.Manipulací s interakcí uživatele v hlavní podproces a CSocket zpracování v alternativní podprocesů lze oddělit tyto logické operace.V aplikaci, která není s více podprocesy, musí být tyto dvě činnosti kombinované a zpracována jako jediný podproces, což obvykle znamená použití CAsyncSocket tak může zpracovávat požadavky na komunikaci na požádání nebo přepsání CSocket::OnMessagePending během dlouhé činnosti synchronní zpracování akce uživatele.
Zbytek této diskuse je pro programátory cílení 16bitové operační systémy:
Obvykle Pokud používáte CAsyncSocket, by měla předejít pomocí blokování operací a raději pracovat asynchronně.Asynchronní operace, od okamžiku, kdy obdržíte WSAEWOULDBLOCK kód chyby po volací příjem, například čekat vaše OnReceive členské funkce se nazývá upozornit, že můžete číst znovu.Asynchronní volání voláním zpět do soketu zpětné volání příslušné oznámení funkce jako OnReceive.
V části Windows blokování volání jsou považovány za špatné praxe.Ve výchozím nastavení CAsyncSocket podporuje asynchronní volání a spravovat, blokování sami pomocí oznámení zpětného volání.Třída CSocket, na druhé straně je synchronní.Zprávy systému Windows čerpadla a spravuje blokování pro vás.
Další informace o blokování viz specifikace rozhraní Windows Sockets.Další informace o "funkcích na" Viz rozhraní Windows Sockets: soket upozornění a rozhraní Windows Sockets: odvozené od třídy Socket.
Více informací naleznete: