Função closesocket (winsock.h)

Artigo
08/27/2023

A função closesocket fecha um soquete existente.

Sintaxe

int closesocket(
  [in] SOCKET s
);

Parâmetros

[in] s

Um descritor que identifica o soquete a ser fechado.

Retornar valor

Se nenhum erro ocorrer, closesocket retornará zero. Caso contrário, um valor de SOCKET_ERROR é retornado e um código de erro específico pode ser recuperado chamando WSAGetLastError.

Código do erro	Significado
WSANOTINITIALISED	Uma chamada WSAStartup bem-sucedida deve ocorrer antes de usar essa função.
WSAENETDOWN	O subsistema de rede falhou.
WSAENOTSOCK	O descritor não é um soquete.
WSAEINPROGRESS	Uma chamada do Windows Sockets 1.1 de bloqueio está em andamento ou o provedor de serviços ainda está processando uma função de retorno de chamada.
WSAEINTR	A chamada (bloqueando) do Windows Socket 1.1 foi cancelada por meio de WSACancelBlockingCall.
WSAEWOULDBLOCK	O soquete é marcado como não desbloqueado, mas o membro l_onoff da estrutura persistente é definido como diferente de zero e o membro l_linger da estrutura persistente é definido como um valor de tempo limite diferente de zero.

Comentários

A função closesocket fecha um soquete. Use-o para liberar o descritor de soquete passado no parâmetro s . Observe que o descritor de soquete passado no parâmetro s pode ser reutilizado imediatamente pelo sistema assim que a função closesocket for emitida. Como resultado, não é confiável esperar que mais referências ao descritor de soquete passado no parâmetro s falhem com o erro WSAENOTSOCK. Um cliente Winsock nunca deve emitir closesocketsimultaneamente com outra chamada de função Winsock.

Todas as operações de envio e recebimento sobrepostas pendentes ( WSASend/ WSASendTo/ WSARecv/ WSARecvFrom com um soquete sobreposto) emitidas por qualquer thread nesse processo também são canceladas. Qualquer evento, rotina de conclusão ou ação de porta de conclusão especificada para essas operações sobrepostas é executada. As operações sobrepostas pendentes falham com o erro status WSA_OPERATION_ABORTED.

Um aplicativo não deve assumir que todas as operações de E/S pendentes em um soquete terão a garantia de serem concluídas quando closesocket retornar. A função closesocket iniciará o cancelamento nas operações de E/S pendentes, mas isso não significa que um aplicativo receberá a conclusão de E/S para essas operações de E/S quando a função closesocket retornar. Portanto, um aplicativo não deve limpar nenhum recurso (estruturas WSAOVERLAPPED , por exemplo) referenciados pelas solicitações de E/S pendentes até que as solicitações de E/S sejam realmente concluídas.

Um aplicativo sempre deve ter uma chamada correspondente para fechar oocket para cada chamada bem-sucedida ao soquete para retornar todos os recursos de soquete para o sistema.

A estrutura persistente mantém informações sobre um soquete específico que especifica como esse soquete deve se comportar quando os dados são enfileirados para serem enviados e a função closesocket é chamada no soquete.

O membro l_onoff da estrutura persistente determina se um soquete deve permanecer aberto por um período especificado após uma chamada de função closesocket para permitir que os dados enfileirados sejam enviados. Esse membro pode ser modificado de duas maneiras:

Chame a função setsockopt com o parâmetro optname definido como SO_DONTLINGER. O parâmetro optval determina como o membro l_onoff é modificado.
Chame a função setsockopt com o parâmetro optname definido como SO_LINGER. O parâmetro optval especifica como os membros l_onoff e l_linger são modificados.

O membro l_linger da estrutura persistente determina a quantidade de tempo, em segundos, que um soquete deve permanecer aberto. Esse membro só será aplicável se o membro l_onoff da estrutura persistente não for zero.

Os parâmetros padrão para um soquete são o l_onoff membro da estrutura persistente é zero, indicando que o soquete não deve permanecer aberto. O valor padrão para o membro l_linger da estrutura persistente é zero, mas esse valor é ignorado quando o membro l_onoff é definido como zero.

Para permitir que um soquete permaneça aberto, um aplicativo deve definir o membro l_onoff como um valor diferente de zero e definir o membro l_linger como o tempo limite desejado em segundos. Para desabilitar a abertura de um soquete, um aplicativo só precisa definir o membro l_onoff da estrutura persistente como zero.

Se um aplicativo chamar a função setsockopt com o parâmetro optname definido como SO_DONTLINGER para definir o membro l_onoff como um valor diferente de zero, o valor do membro l_linger não será especificado. Nesse caso, o tempo limite usado depende da implementação. Se um tempo limite anterior tiver sido estabelecido para um soquete (chamando anteriormente a função setsockopt com o parâmetro optname definido como SO_LINGER), esse valor de tempo limite deverá ser restabelecido pelo provedor de serviços.

A semântica da função closesocket é afetada pelas opções de soquete que definem membros da estrutura persistente .

L_onoff	l_linger	Tipo de fechamento	Aguarde o fechamento?
zero	Não se importe	Fechamento normal	No
Zero	zero	Forçado	No
Zero	Zero	Normal se todos os dados forem enviados dentro do valor de tempo limite especificado no membro l_linger . Difícil se todos os dados não puderem ser enviados dentro do valor de tempo limite especificado no membro l_linger .	Yes

Se o membro l_onoff da estrutura LINGER for zero em um soquete de fluxo, a chamada closesocket retornará imediatamente e não receberá WSAEWOULDBLOCK se o soquete estiver bloqueando ou não. No entanto, todos os dados enfileirados para transmissão serão enviados, se possível, antes que o soquete subjacente seja fechado. Isso também é chamado de desconexão normal ou fechamento. Nesse caso, o provedor do Windows Sockets não pode liberar o soquete e outros recursos por um período arbitrário, afetando assim os aplicativos que esperam usar todos os soquetes disponíveis. Esse é o comportamento padrão de um soquete.

Se o membro l_onoff da estrutura persistente não for zero e l_linger membro for zero, closesocket não será bloqueado mesmo se os dados enfileirados ainda não tiverem sido enviados ou reconhecidos. Isso é chamado de fechamento rígido ou anulativo, porque o circuito virtual do soquete é redefinido imediatamente e todos os dados não retornados são perdidos. No Windows, qualquer chamada recv no lado remoto do circuito falhará com WSAECONNRESET.

Se o membro l_onoff da estrutura persistente estiver definido como diferente de zero e l_linger membro estiver definido como um tempo limite diferente de zero em um soquete de bloqueio, a chamada closesocket será bloqueada até que os dados restantes sejam enviados ou até que o tempo limite expire. Isso é chamado de desconexão normal ou fechamento se todos os dados forem enviados dentro do valor de tempo limite especificado no membro l_linger . Se o tempo limite expirar antes que todos os dados sejam enviados, a implementação do Windows Sockets encerrará a conexão antes que closesocket retorne e isso será chamado de fechamento rígido ou anulativo.

Não é recomendável definir o membro l_onoff da estrutura persistente como diferente de zero e o membro l_linger com um intervalo de tempo limite diferente de zero em um soquete sem bloqueio. Nesse caso, a chamada para closesocket falhará com um erro de WSAEWOULDBLOCK se a operação de fechamento não puder ser concluída imediatamente. Se closesocket falhar com WSAEWOULDBLOCK , o identificador de soquete ainda será válido e uma desconexão não será iniciada. O aplicativo deve chamar closesocket novamente para fechar o soquete.

Se o membro l_onoff da estrutura persistente for diferente de zero e o membro l_linger for um intervalo de tempo limite diferente de zero em um soquete de bloqueio, o resultado da função closesocket não poderá ser usado para determinar se todos os dados foram enviados para o par. Se os dados forem enviados antes do tempo limite especificado no membro l_linger expirar ou se a conexão tiver sido anulada, a função closesocket não retornará um código de erro (o valor retornado da função closesocket será zero).

A chamada closesocket só será bloqueada até que todos os dados sejam entregues ao par ou o tempo limite expire. Se a conexão for redefinida porque o tempo limite expirar, o soquete não entrará TIME_WAIT estado. Se todos os dados forem enviados dentro do período de tempo limite, o soquete poderá entrar em TIME_WAIT estado.

Se o membro l_onoff da estrutura persistente for diferente de zero e o membro l_linger for um intervalo de tempo limite zero em um soquete de bloqueio, uma chamada para closesocket redefinirá a conexão. O soquete não irá para o estado TIME_WAIT.

A função getsockopt pode ser chamada com o parâmetro optname definido como SO_LINGER para recuperar o valor atual da estrutura persistente associada a um soquete.

Nota Para garantir que todos os dados sejam enviados e recebidos em uma conexão, um aplicativo deve chamar o desligamento antes de chamar closesocket (consulte Desligamento normal, opções persistentes e fechamento de soquete para obter mais informações). Observe também que um evento de rede FD_CLOSE não é postado depois que closesocket é chamado.

Aqui está um resumo do comportamento closesocket :

Se o membro l_onoff da estrutura LINGER for zero (o padrão para um soquete), closesocket retornará imediatamente e a conexão será normalmente fechada em segundo plano.
Se o membro l_onoff da estrutura persistente estiver definido como diferente de zero e o membro l_linger for definido como zero (sem tempo limite) closesocket retornará imediatamente e a conexão será redefinida ou encerrada.
Se o membro l_onoff da estrutura persistente estiver definido como diferente de zero e o membro l_linger for definido como um tempo limite diferente de zero:– Para um soquete de bloqueio, closesocket será bloqueado até que todos os dados sejam enviados ou o tempo limite expire.
– Para um soquete sem bloqueio, closesocket retorna imediatamente indicando falha.

Para obter mais informações , consulte Desligamento normal, opções persistentes e fechamento de soquete para obter mais informações.

Nota Ao emitir uma chamada winsock de bloqueio, como closesocket, o Winsock pode precisar aguardar um evento de rede antes que a chamada possa ser concluída. O Winsock executa uma espera alertável nessa situação, que pode ser interrompida por uma APC (chamada de procedimento assíncrono) agendada no mesmo thread. A emissão de outra chamada winsock de bloqueio dentro de um APC que interrompeu uma chamada Winsock de bloqueio contínuo no mesmo thread levará a um comportamento indefinido e nunca deve ser tentada por clientes Winsock.

Notas para soquetes IrDA

Lembre-se:

O arquivo de cabeçalho Af_irda.h deve ser incluído explicitamente.
Há suporte para as opções padrão persistentes.
Embora o IrDA não forneça um fechamento normal, o IrDA adiará o fechamento até que as filas de recebimento sejam limpas. Portanto, um aplicativo pode enviar dados e chamar imediatamente a função de soquete e ter certeza de que o receptor copiará os dados antes de receber uma mensagem de FD_CLOSE.

Notas para caixa eletrônico

Veja a seguir os problemas importantes associados à remoção de conexão ao usar o ATM (Modo de Transferência Assíncrona) e o Windows Sockets 2:

O uso das funções closesocket ou shutdown com SD_SEND ou SD_BOTH resulta no envio de um sinal RELEASE no canal de controle. Devido ao uso do atm de canais de dados e sinais separados, é possível que um sinal RELEASE possa chegar ao final remoto antes que o último dos dados atinja seu destino, resultando em uma perda desses dados. Uma solução possível é programar um atraso suficiente entre os últimos dados enviados e as chamadas de função closesocket ou shutdown para um soquete de caixa eletrônico.
Não há suporte para metade do fechamento pelo caixa eletrônico.
As desconexões abortivas e normais resultam no envio de um sinal RELEASE com o mesmo campo de causa. Em ambos os casos, os dados recebidos na extremidade remota do soquete ainda são entregues ao aplicativo. Confira Desligamento normal, opções persistentes e fechamento de soquete para obter mais informações.

Windows Phone 8: essa função tem suporte para aplicativos da Windows Phone Store no Windows Phone 8 e posterior.

Windows 8.1 e Windows Server 2012 R2: essa função tem suporte para aplicativos da Windows Store em Windows 8.1, Windows Server 2012 R2 e posteriores.

Requisitos

Requisito	Valor
Cliente mínimo com suporte	Windows 8.1, Windows Vista [aplicativos da área de trabalho \| Aplicativos UWP]
Servidor mínimo com suporte	Windows Server 2003 [aplicativos da área de trabalho \| Aplicativos UWP]
Plataforma de Destino	Windows
Cabeçalho	winsock.h (inclua Winsock2.h)
Biblioteca	Ws2_32.lib
DLL	Ws2_32.dll