Aceitando solicitações de conexão

Se um aplicativo chamar a função WSAAccept, accept ou AcceptEx para aceitar uma solicitação de conexão de entrada em um soquete, a opção Windows Sockets sempre encaminhará essa chamada para o provedor de serviços TCP/IP. Se uma solicitação de conexão de entrada chegar de uma rede não SAN, ela fluirá pelo caminho NDIS e o provedor de serviços TCP/IP o manipulará. Se uma solicitação de conexão chegar de um par remoto em uma SAN, a opção atuará como um intermediário entre o provedor de serviços TCP/IP e o provedor de serviços SAN para determinar se deseja aceitar a solicitação de conexão e concluir a função WSAAccept, accept ou AcceptEx do aplicativo.

A figura a seguir mostra uma visão geral da interação entre o comutador do Windows Sockets e o provedor de serviços SAN para determinar se deseja aceitar ou rejeitar uma solicitação de conexão de entrada. As sequências e seções a seguir descrevem a determinação de aceitação com mais detalhes.

Para aceitar ou rejeitar uma solicitação de conexão

1. Ao receber uma solicitação de conexão de entrada de um par remoto, o provedor de serviços SAN sinaliza um objeto de evento, conforme descrito em Escutando conexões em uma SAN.

2. A opção Windows Sockets chama a função WSPEnumNetworkEvents do provedor de serviços SAN para receber o código de evento FD_ACCEPT.

3. Ao receber o código de evento FD_ACCEPT, a opção chama a função WSPAccept do provedor de serviços SAN para aceitar ou rejeitar a solicitação de conexão de entrada.

4. Na chamada da opção para a função WSPAccept do provedor de serviços SAN, a opção especifica uma função de condição. O provedor de serviços SAN deve chamar essa função de condição no mesmo thread no qual a função WSPAccept foi chamada antes de retornar da chamada WSPAccept .

5. A opção retorna o código CF_ACCEPT ou CF_REJECT dessa função de condição para indicar que aceita ou rejeita a solicitação de conexão, respectivamente.

Aceitando uma solicitação de conexão e criando um soquete de aceitação

Se um aplicativo aceitar uma solicitação de conexão de entrada, a opção retornará o código CF_ACCEPT para o provedor de serviços SAN para concluir a função de condição do comutador. Ao receber CF_ACCEPT, o provedor de serviços SAN inicializa uma estrutura de dados interna na qual armazena informações sobre o soquete de aceitação. A função WSPAccept do provedor de serviços SAN deve chamar em seguida a função WPUCreateSocketHandle para adquirir um descritor para o soquete de aceitação da opção. O provedor de serviços SAN deve armazenar o descritor do comutador em sua estrutura de dados interna para o soquete de aceitação e deve retornar seu próprio descritor para que o soquete de aceitação conclua a chamada WSPAccept . A opção deve fornecer o descritor interno do provedor de serviços SAN para o soquete de aceitação ao chamar as funções do provedor de serviços SAN, enquanto o provedor de serviços SAN deve fornecer o descritor de soquete do comutador em chamadas up para a opção.

Antes de concluir com êxito o WSPAccept, o provedor de serviços SAN deve chamar a função Win32 ResetEvent para redefinir o objeto de evento. Isso permite que o provedor de serviços SAN chame posteriormente a função SetEvent do Win32 para sinalizar a opção para aceitar a próxima solicitação de conexão de entrada.

Rejeitando uma solicitação de conexão

Se um aplicativo rejeitar uma solicitação de conexão de entrada, a opção retornará o código CF_REJECT para o provedor de serviços SAN para concluir a função de condição da opção. Ao receber CF_REJECT, o provedor de serviços SAN deve retornar o código de erro WSAECONNREFUSED para a opção para concluir a chamada WSPAccept .

Indicando aceitação ou recusa de uma solicitação de conexão para um par remoto

Antes que um provedor de serviços SAN possa indicar a um par remoto que ele aceita ou recusa a solicitação de conexão do par remoto, o provedor de serviços SAN deve chamar a função de condição do comutador. Dependendo do valor retornado pela função de condição do comutador, o provedor de serviços san deve fazer uma das seguintes indicações para o par remoto:

Se a função de condição do comutador retornar CF_ACCEPT, o provedor de serviços SAN deverá indicar que aceita a solicitação de conexão do par remoto. O provedor de serviços SAN no par remoto pode concluir com êxito sua operação de conexão iniciada por uma chamada WSPConnect .

Se a função de condição do comutador retornar CF_REJECT, o provedor de serviços SAN deverá indicar que ele recusa a solicitação de conexão do par remoto. O provedor de serviços SAN no par remoto deve falhar na operação de conexão iniciada por uma chamada WSPConnect com o código de erro WSAECONNREFUSED.

Negociação de Sessão

Depois que a opção tiver usado com êxito um provedor de serviços SAN para aceitar uma solicitação de conexão de um par remoto, a opção negociará uma sessão com esse par.

Para negociar uma sessão

1. A opção no par remoto chama a função WSPRecv do provedor de serviços SAN para postar um conjunto de buffers de recebimento.

2. A opção no par remoto chama a função WSPSend do provedor de serviços SAN para enviar uma mensagem de negociação de sessão para a opção no ponto de extremidade de aceitação local. Essa mensagem inclui o número de buffers de recebimento que a opção no par remoto postou.

3. A opção no ponto de extremidade de aceitação local chama a função WSPRecv do provedor de serviços san local para postar seus próprios buffers de recebimento, mas pode não ser capaz de fazê-lo a tempo de receber a mensagem de negociação de sessão. Se a opção local não postar um buffer de recebimento a tempo e se a NIC subjacente não der suporte ao controle de fluxo, o provedor de serviços SAN no ponto de extremidade de aceitação local deverá armazenar em buffer a mensagem de negociação de sessão do comutador remoto em seus próprios buffers de recebimento privados. Quando as postagens de comutador recebem buffers, o provedor de serviços SAN copia dados de seus buffers de recebimento privados para os buffers de comutador em uma base um-para-um até que todos os dados sejam copiados dos buffers privados para os buffers de comutador.

   O provedor de serviços SAN executa o processamento de recebimento normal em buffers de comutador subsequentes, ou seja, ele posta todos esses buffers de comutador na fila de recebimento na NIC.

   Observe que um provedor de serviços san não deve descartar uma conexão simplesmente porque a opção não postou um buffer de recebimento antes da mensagem de negociação de sessão chegar. O comprimento máximo de uma mensagem de negociação de sessão é de 256 bytes.

4. A opção no ponto de extremidade de aceitação local posta seus buffers de recebimento antes de responder à mensagem de negociação de sessão. A opção local chama a função WSPSend do provedor de serviços de SAN local para responder à mensagem de negociação de sessão. A resposta do comutador local inclui o número de buffers de recebimento que o comutador local postou. Desse ponto em diante, a opção local garante que o conjunto postado de buffers de recebimento seja de tamanho suficiente para receber qualquer mensagem que chegue na conexão.

5. Se um aplicativo especificar um buffer de recebimento inicial em sua chamada AcceptEx , a opção aguardará até receber a primeira mensagem de dados de seu par remoto antes de concluir a chamada AcceptEx do aplicativo.

6. Se o aplicativo cancelar sua própria chamada de aceitação , a opção chamará a função WSPCloseSocket do provedor de serviços SAN apropriada para fechar o soquete SAN de aceitação.