Windows Sockets: bloqueando
Este artigo e dois artigos complementar explicam vários problemas na programação de Sockets do Windows.Este artigo aborda o bloqueio.Outros problemas são abordados nos artigos: Windows Sockets: Byte ordem e Windows Sockets: convertendo Strings.
Se você usar ou derivam da classe CAsyncSocket, você precisará gerenciar estes problemas sozinho.Se você usar ou derivam da classe CSocket, MFC gerencia-las para você.
Bloqueio
Um soquete pode estar no "modo de bloqueio" ou "modo não bloqueado". As funções do sockets em modo de bloqueio (ou síncrono) não retornará até que eles podem concluir sua ação.Isso é chamado de bloqueio porque o soquete cuja função foi chamada não pode fazer nada — é bloqueado — até que a chamada retorna.Uma chamada para o receber função de membro, por exemplo, pode levar um tempo arbitrariamente longo para concluir o que ele espera o aplicativo de envio enviar (isso é se você estiver usando CSocket, ou usando o CAsyncSocket com bloqueio).Se um CAsyncSocket objeto está no modo não bloqueado (operacional assíncrona), a chamada retorna imediatamente e o código de erro atual, recuperável com o GetLastError função de membro é WSAEWOULDBLOCK, indicando que a chamada seria ter bloqueado possuía não retornou imediatamente por causa do modo de exibição.(CSocket nunca retorna WSAEWOULDBLOCK.A classe gerencia bloqueio para você.)
O comportamento de soquetes é diferente em 32 bits e 64 bits sistemas operacionais (como Windows 95 ou Windows 98) 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 use multitarefa preemptiva e fornecer multithreading.Em sistemas operacionais de 32 bits e 64 bits, você pode colocar os soquetes em segmentos de trabalho separada.Um soquete em um thread pode bloquear sem interferir em outras atividades em seu aplicativo e sem gastar tempo de computação de bloqueio de.Para obter informações sobre a programação multithread, consulte o artigo Multithreading.
.gif "Observação") Observação |
|---|
Em aplicativos multissegmentados, você pode usar a bloqueio natureza do CSocket para simplificar o design do programa sem afetar a capacidade de resposta da interface do usuário.Manipulando as interações do usuário no thread principal e CSocket alternativos threads de processamento, você pode separar essas operações lógicas.Em um aplicativo não é multithread, essas duas atividades devem ser combinadas e tratadas como um único segmento que normalmente significa usar CAsyncSocket para que você pode manipular as solicitações de comunicações sob demanda ou substituindo CSocket::OnMessagePending para tratar de ações do usuário durante a extensa atividade síncrona. |
O resto desta discussão é para programadores de direcionamento de sistemas operacionais de 16 bits:
Normalmente, se você estiver usando CAsyncSocket, você deve evitar usar o bloqueio de operações e operar de maneira assíncrona em vez disso.Em operações assíncronas, do ponto em que você receber um WSAEWOULDBLOCK código de erro depois de chamar o receber, por exemplo, aguarde até que seu OnReceive função de membro é chamada para notificar que você pode ler novamente.Chamadas assíncronas são feitas pela chamada volta função de notificação de retorno de chamada apropriada do soquete, como OnReceive.
Em Windows, chamadas de bloqueio são consideradas prática ruim.Por padrão, CAsyncSocket suporta chamadas assíncronas e você deve gerenciar o bloqueio usando notificações de retorno de chamada.Classe CSocket, por outro lado, é síncrono.Ele bombeia mensagens do Windows e gerencia o bloqueio para você.
Para obter mais informações sobre o bloqueio, consulte a especificação de Windows Sockets.Para obter mais informações sobre "Em" funções, consulte Windows Sockets: soquete notificações e Windows Sockets: derivação de Classes de soquete.
Para obter mais informações, consulte: