Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
Este artigo e dois artigos complementares explicam vários problemas na programação do Windows Sockets. Este artigo aborda o bloqueio. As outras questões são abordadas nos artigos: Windows Sockets: Byte Ordering e Windows Sockets: Converting Strings.
Se você usar ou derivar da classe CAsyncSocket, precisará gerenciar esses problemas por conta própria. Se você usa ou deriva da classe CSocket, a MFC os gerencia para você.
Bloqueio
Um soquete pode estar em "modo de bloqueio" ou "modo sem bloqueio". As funções dos soquetes no modo de bloqueio (ou síncrono) não retornam até que eles possam concluir sua ação. Isso é chamado de bloqueio porque o soquete cuja função foi chamada não pode fazer nada — está bloqueado — até que a chamada retorne. A chamada para a função de membro Receive, por exemplo, pode levar um tempo arbitrariamente longo para ser concluída, pois aguarda o envio de dados pelo aplicativo (isso se você estiver usando CSocket, ou usando CAsyncSocket com bloqueio de execução). Se um CAsyncSocket objeto estiver no modo sem bloqueio (operando de forma assíncrona), a chamada retornará imediatamente e o código de erro atual, recuperável com a função de membro GetLastError , é WSAEWOULDBLOCK, indicando que a chamada teria sido bloqueada se não tivesse retornado imediatamente devido ao modo.
CSocket( nunca retorna WSAEWOULDBLOCK. A classe gerencia o bloqueio para você.)
O comportamento dos soquetes é diferente em sistemas operacionais de 32 bits e 64 bits (como Windows 95 ou Windows 98) do que em sistemas operacionais de 16 bits (como o Windows 3.1). Ao contrário dos sistemas operacionais de 16 bits, os sistemas operacionais de 32 bits e 64 bits usam multitarefa preventiva e fornecem multithreading. Nos sistemas operacionais de 32 bits e 64 bits, você pode colocar seus soquetes em threads de trabalho separados. Um soquete em um thread pode bloquear sem interferir com outras atividades em seu aplicativo e sem gastar tempo de computação no bloqueio. Para obter informações sobre programação multithreaded, consulte o artigo Multithreading.
Observação
Em aplicações multithreaded, pode-se usar a natureza de bloqueio do CSocket para simplificar o design do seu programa sem afetar a responsividade da interface de utilizador. Ao manipular interações do usuário no thread principal e CSocket processar em threads alternativos, você pode separar essas operações lógicas. Em um aplicativo que não é multithreaded, essas duas atividades devem ser combinadas e tratadas como um único thread, o que geralmente significa usar CAsyncSocket para que você possa lidar com solicitações de comunicação sob demanda ou substituir CSocket::OnMessagePending para manipular ações do usuário durante a atividade síncrona longa.
O resto desta discussão é para programadores visando sistemas operacionais de 16 bits:
Normalmente, se estiveres a usar CAsyncSocket, deves evitar fazer operações de bloqueio e operar assincronamente. Em operações assíncronas, a partir do ponto em que recebe um código de erro WSAEWOULDBLOCK depois de chamar Receive, por exemplo, espera até que a sua função membro OnReceive seja chamada para notificá-lo de que pode ler novamente. As chamadas assíncronas são feitas invocando a função de retorno de chamada apropriada do seu soquete, como OnReceive.
No Windows, o bloqueio de chamadas é considerado uma má prática. Por padrão, o CAsyncSocket suporta chamadas assíncronas e você mesmo deve gerenciar o bloqueio usando notificações de retorno de chamada. A classe CSocket, por outro lado, é síncrona. Ele bombeia mensagens do Windows e gerencia o bloqueio para você.
Para obter mais informações sobre bloqueio, consulte a especificação do Windows Sockets. Para obter mais informações sobre funções "On", consulte Windows Sockets: Notificações de Soquete e Windows Sockets: Derivação de Classes de Soquete.
Para obter mais informações, consulte: