Aceitando solicitações de conexão

Se um aplicativo chamar a função WSAAccept, acceptou AcceptEx para aceitar uma solicitação de conexão de entrada em um soquete, o switch Windows Sockets sempre encaminhará esta 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 flui pelo caminho NDIS e o provedor de serviços TCP/IP a manipula. Se uma solicitação de conexão chegar de um par remoto numa SAN, o switch atuará como um intermediário entre o fornecedor de serviço TCP/IP e o fornecedor de serviço SAN, para determinar se a solicitação de conexão deve ser aceite e para concluir as funções WSAAccept, aceitarou AcceptEx do aplicativo.

A figura a seguir mostra uma visão geral da interação entre o comutador Windows Sockets e o fornecedor de serviços SAN a fim de determinar se 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 um pedido de conexão de entrada de um par remoto, o fornecedor de serviços de SAN sinaliza um objeto de evento conforme descrito em A escuta de conexões numa SAN.

2. O switch do Windows Sockets chama a função WSPEnumNetworkEvents de 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, o switch 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 do switch para a função WSPAccept do provedor de serviços SAN, o switch especifica uma função de condição. O provedor de serviços de SAN deve chamar essa função de condição no mesmo thread em que a função WSPAccept foi chamada antes de retornar da chamada de WSPAccept.

5. O switch 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, o switch retornará o código CF_ACCEPT ao provedor de serviços SAN para concluir a função de condição do switch. Ao receber CF_ACCEPT, o provedor de serviços de SAN inicializa uma estrutura de dados interna na qual armazena informações sobre o soquete de aceitação. A função WSPAccept do fornecedor de serviços SAN deve, em seguida, chamar a função WPUCreateSocketHandle para adquirir um descritor para o socket de receção do switch. O fornecedor de serviços SAN deve armazenar o descritor do switch na sua estrutura de dados interna para o socket de aceitação e deve retornar o seu próprio descritor para esse socket de aceitação para completar a chamada WSPAccept. O switch deve fornecer o descritor interno do fornecedor de serviços SAN para o soquete de aceitação ao chamar as funções do fornecedor de serviços SAN, enquanto o fornecedor de serviços SAN deve fornecer o descritor de soquete do switch em chamadas para o switch.

Antes de concluir com sucesso WSPAccept, o provedor de serviços SAN deve chamar a função Win32 ResetEvent para reinicializar o objeto de evento. Isso permite que o provedor de serviços de SAN chame posteriormente a função Win32 SetEvent para sinalizar que o switch deve aceitar o próximo pedido de ligação a entrar.

Rejeitando uma solicitação de conexão

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

Demonstrando aceitação ou recusa de um pedido de conexão com um par remoto

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

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

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

Sessão de Negociação

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

Para negociar uma sessão

1. O switch do parceiro remoto chama a função WSPRecv do provedor de serviços SAN para publicar um conjunto de buffers de recebimento.

2. O comutador no par remoto chama a função WSPSend do fornecedor de serviços SAN para enviar uma mensagem de negociação de sessão ao comutador no ponto de extremidade de aceitação local. Esta mensagem inclui o número de buffers de recebimento que o switch no peer remoto postou.

3. O switch no ponto de extremidade de aceitação local chama a função WSPRecv do provedor de serviços SAN local para postar os seus próprios buffers de receção, mas talvez não consiga fazê-lo a tempo de receber a mensagem de negociação da sessão. Se o switch local não postar um buffer de recebimento a tempo e se a NIC subjacente não oferecer 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 switch remoto em seus próprios buffers de recebimento privados. Quando os switches recebem buffers, o provedor de serviços SAN copia os dados dos seus buffers de receção privados para os buffers do switch de forma um a um, até que todos os dados tenham sido copiados dos buffers privados para os buffers do switch.

   O provedor de serviços de rede de armazenamento executa o processamento de receção normal em switches subsequentes, ou seja, ele coloca todos esses buffers de switch na fila de receção na NIC.

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

4. O switch no ponto de extremidade de aceitação local posta seus buffers de recebimento antes de responder à mensagem de negociação da sessão. O switch local chama a função WSPSend do provedor de serviços SAN local para responder à mensagem de negociação da sessão. A resposta do switch local inclui o número de buffers de recebimento que o switch local postou. A partir deste ponto, o switch 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, o switch aguardará até receber a primeira mensagem de dados de seu par remoto antes de concluir a chamada AcceptEx do aplicativo.

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