Função closesocket (winsock.h)
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 |
|---|---|
| Uma chamada WSAStartup bem-sucedida deve ocorrer antes de usar essa função. | |
| O subsistema de rede falhou. | |
| O descritor não é um soquete. | |
| Uma chamada de bloqueio do Windows Sockets 1.1 está em andamento ou o provedor de serviços ainda está processando uma função de retorno de chamada. | |
| A chamada do Windows Socket 1.1 foi cancelada por meio do WSACancelBlockingCall. | |
| O soquete é marcado como não desbloqueio, mas o membro l_onoff da estrutura persistente é definido como não zero e o membro l_linger da estrutura persistente é definido como um valor de tempo limite não 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 novas 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 pendentes de envio e recebimento sobrepostas (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 status de erro 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 o 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 deve sempre ter uma chamada correspondente para fechar o conjunto 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 do 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 não zero e definir o membro l_linger como o tempo limite desejado em segundos. Para desabilitar um soquete de permanecer aberto, 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 não 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 até fechar? |
|---|---|---|---|
| zero | Não se importe | Fechamento gracioso | No |
| Zero | zero | Difícil | 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 desbloqueando. 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 ou fechamento normal. 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 abortivo, pois o circuito virtual do soquete é redefinido imediatamente e todos os dados não existentes 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 não zero e l_linger membro estiver definido como um tempo limite não zero em um soquete de bloqueio, o closesocket será bloqueado 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 de todos os dados serem enviados, a implementação do Windows Sockets encerrará a conexão antes que o closesocket retorne e isso será chamado de fechamento rígido ou abortivo.
Não é recomendável definir o membro l_onoff da estrutura persistente como não zero e o membro l_linger com um intervalo de tempo limite não zero em um soquete sem bloqueio. Nesse caso, a chamada para fechar oocket falhará com um erro de WSAEWOULDBLOCK se a operação de fechamento não puder ser concluída imediatamente. Se o closesocket falhar com WSAEWOULDBLOCK , o identificador do 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 não for zero e o membro l_linger for um intervalo de tempo limite não 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 na l_linger membro 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 expirar. Se a conexão for redefinida porque o tempo limite expirar, o soquete não entrará em 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 l_onoff membro da estrutura persistente não for 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.
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 l_onoff membro da estrutura persistente estiver definido como não zero e o membro l_linger estiver definido como zero (sem tempo limite) o 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 estiver definido como um tempo limite diferente de zero:– Para um soquete de bloqueio, feche os blocos até que todos os dados sejam enviados ou o tempo limite expire.
– Para um soquete sem bloqueio, closesocket retorna imediatamente indicando falha.
Para obter informações adicionais , consulte Desligamento Normal, Opções Persistentes e Fechamento de Soquete para obter mais informações.
Anotações 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. Assim, 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 o ATM
Veja a seguir problemas importantes associados ao teardown de conexão ao usar o ATM (Modo de Transferência Assíncrono) e o Windows Sockets 2:
- Usar as funções closesocket ou shutdown com SD_SEND ou SD_BOTH resulta em um sinal RELEASE sendo enviado no canal de controle. Devido ao uso do atm de canais de dados e sinal separados, é possível que um sinal RELEASE possa chegar ao final remoto antes que o último dos dados chegue ao seu destino, resultando em uma perda desses dados. Uma das soluções possíveis é programar um atraso suficiente entre os últimos dados enviados e as chamadas de função closesocket ou shutdown para um soquete atm.
- Não há suporte para a metade do fechamento pelo ATM.
- As desconexões abortivas e normalmente resultam em um sinal RELEASE sendo enviado com o mesmo campo de causa. Em ambos os casos, os dados recebidos na extremidade remota do soquete ainda são entregues ao aplicativo. Consulte 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 posterior.
Requisitos
| 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 |
Confira também
Desligamento normal, opções persistentes e fechamento de soquete