Duplicação de identificadores de soquete para uma SAN

Vários aplicativos executados em processos diferentes podem usar a opção Windows Sockets para executar operações em um soquete subjacente compartilhado. No entanto, apenas um aplicativo de cada vez pode executar operações nesse soquete subjacente compartilhado.

Para usar um soquete subjacente compartilhado, um aplicativo deve recuperar um identificador duplicado para esse soquete subjacente de uma das seguintes maneiras:

• Diretamente, chamando a função WSADuplicateSocket do Windows Sockets

  A chamada é feita no contexto do processo de controle (o processo no qual o soquete foi criado).

• Indiretamente, chamando a função Win32 DuplicateHandle

  A chamada é feita no contexto de um processo não controlador (diferente do processo no qual o soquete foi criado).

• Usando o mecanismo de herança de controlador

  Um processo filho (o processo não controlador) herda todos ou alguns dos identificadores criados no seu processo pai (o processo controlador).

• Durante o fecho suave da ligação

  Se um aplicativo no processo de controle fecha um soquete e sai enquanto alguns dados ainda precisam ser enviados, esses dados restantes são armazenados em buffer na DLL do Windows Sockets. Outra aplicação no contexto do processo de serviço do sistema (o processo não controlador) envia posteriormente esses dados.

A opção Windows Sockets, em conjunto com o provedor TCP/IP, deteta e manipula cada uma das condições anteriores. O switch permite que apenas um processo de cada vez execute operações que transferem dados ou alteram o estado de um soquete compartilhado subjacente. Os processos trocam dinamicamente o controle do soquete subjacente, conforme necessário, para executar as operações solicitadas. O switch serializa operações que diferentes processos solicitam executar em um soquete compartilhado e executa essas operações na ordem FIFO (first-in-first-out). O switch aguarda a conclusão de todas as operações em andamento antes de trocar o controle de um soquete subjacente por outro processo. Logicamente, o switch retira do processo de controlo o controlo sobre o socket subjacente assim que um processo não controlador solicita uma operação qualificada. Depois que o controle é retirado, o switch trata o processo de controle original como um processo não controlador se o processo de controle original solicitar operações qualificadas. Observe que o switch não executa nenhuma ação em um identificador de soquete duplicado até que o processo sem controle realmente use o identificador de soquete duplicado para uma transferência de dados ou operação de alteração de estado.

Tanto o switch quanto o provedor de serviços de SAN apropriado são carregados em todos os processos que compartilham o acesso a um determinado soquete subjacente. O switch mantém seu próprio contexto de soquete e informações de estado de conexão em todos os processos que compartilham o soquete. O fornecedor de serviços SAN é obrigado a manter as suas informações de contexto de socket e estado de conexão apenas no processo que tem controlo do socket subjacente em qualquer momento. O provedor de serviços de SAN deve trocar o controle de suas informações de contexto e estado de conexão do processo de controle atual para o próximo processo de controle sempre que o switch exigir a troca, conforme descrito na sequência a seguir. Para minimizar a quantidade de recursos necessários para a troca, um provedor de serviços de SAN pode manter suas informações de contexto e estado de conexão em todos os processos que compartilham um soquete subjacente.

Como o switch não cria o soquete SAN que corresponde a um soquete de aplicativo até que um aplicativo chame a função de conexão ou escuta , o switch não pode solicitar que o provedor de serviços de SAN execute uma operação de permuta antes que o soquete do aplicativo esteja conectado ou escutando. Mesmo depois que o soquete do aplicativo estiver conectado ou escutando, uma das seguintes condições deve ser atendida antes que o switch solicite que o provedor de serviços SAN troque o controle do soquete:

• Um processo que não controla o soquete inicia uma transferência de dados. O provedor de serviços de SAN não troca o controle do soquete até que todas as operações de transferência de dados iniciadas pelo processo de controle sejam concluídas.

• Um processo que não controla o soquete chama a função WSAAccept, WSPAcept ou AcceptEx para iniciar uma operação de aceitação de conexão em um soquete de escuta. O provedor de serviços de SAN não troca o controle do soquete até que todas as solicitações de aceitação iniciadas pelo processo de controle sejam concluídas.

O switch executa as seguintes etapas para trocar o controle de um soquete SAN conectado do processo de controle para o próximo processo de controle (Para obter uma visão geral do processo de troca, consulte a tabela na seção Comentários da documentação da função WSPDuplicateSocket .):

1. O switch suspende o processamento de novas solicitações do aplicativo no processo de controle. Quando todas as operações de envio e RDMA em andamento no soquete SAN forem concluídas, o switch chamará a função WSPSend do provedor de serviços SAN para enviar uma mensagem a um par conectado para solicitar a suspensão da sessão e chamará a função WSPDeregisterMemory do provedor de serviços SAN para liberar todos os buffers locais usados para operações de envio. Como resultado, o switch na conexão ponto a ponto suspende o processamento de novas solicitações de aplicativos, aguarda a conclusão de todas as operações de envio e RDMA em andamento no soquete SAN e libera toda a memória RDMA. Em seguida, a conexão de mesmo nível envia uma mensagem de resposta indicando que a sessão está suspensa. Ao receber essa mensagem de confirmação, o switch no ponto de extremidade local chama a função WSPDeregisterRdmaMemory do provedor de serviços SAN para liberar toda a memória RDMA. Neste ponto, os soquetes de SAN em ambos os endpoints da conexão só podem ter solicitações de recebimento pendentes. Essas solicitações de recebimento permanecem pendentes no soquete SAN do par remoto para permitir a reativação da sessão. As solicitações de recebimento no soquete SAN local no processo de controle são concluídas na próxima etapa. Enquanto a conexão é suspensa, o switch na ligação ao peer remoto enfileira novas solicitações de bloqueio ou sobrepostas, armazena em buffer novos envios sem bloqueio até à configuração SO_SNDBUF, não consegue enviar novos dados sem bloqueio depois de atingir o limite do buffer, e falha todas as novas receções sem bloqueio com WSAEWOULDBLOCK. O comutador local no processo de controle lida com novas solicitações no soquete do aplicativo como se o processo não tivesse controle do soquete.

2. Após a suspensão da sessão, o switch chama a função WSPDuplicateSocket do provedor de serviços SAN no processo controlador para direcionar o provedor de serviços SAN a transferir o contexto do soquete para o espaço de endereçamento do próximo processo controlador. A opção especifica o próximo processo de controle no parâmetro dwProcessId de WSPDuplicateSocket. A função WSPDuplicateSocket deve chamar a função WPUCompleteOverlappedRequest para concluir todas as solicitações de recebimento pendentes no socket com status de sucesso e zero bytes. O provedor de serviços de SAN também deve liberar automaticamente todos os buffers associados a essas solicitações. O provedor de serviços de SAN libera todos os buffers, pois o switch não solicita mais operações no soquete SAN após o retorno de WSPDuplicateSocket . A única exceção possível é uma chamada de função WSPCloseSocket , conforme descrito na próxima etapa. Depois que WSPDuplicateSocket retorna, o switch salva o valor no membro dwProviderReserved da estrutura WSAPROTOCOL_INFOW para a qual o parâmetro de saída lpProtocolInfo aponta. O switch usa esse valor para identificar o soquete subjacente no contexto do próximo processo de controle. Portanto, o valor em dwProviderReserved deve identificar exclusivamente o soquete subjacente e a conexão para esse soquete em todos os processos no sistema. Além disso, esse valor deve ser válido somente no contexto do processo especificado pelo switch no parâmetro dwProcessId de WSPDuplicateSocket.

3. Depois que o contexto do soquete é transferido para o espaço de endereço do próximo processo de controle, o switch chama a função WSPSocket do provedor de serviços SAN no contexto do próximo processo de controle. Nesta chamada, o switch passa o valor do soquete subjacente que foi retornado na chamada WSPDuplicateSocket para o membro dwProviderReserved da estrutura WSAPROTOCOL_INFOW para a qual o parâmetro de entrada lpProtocolInfo aponta. Se o próximo processo de controle não solicitar a criação do soquete SAN, o provedor de serviços SAN deverá criar um novo soquete e chamar a função WPUCreateSocketHandle para obter um identificador, conforme necessário para qualquer novo soquete. Se o soquete SAN tiver sido criado no contexto do próximo processo de controle, o provedor de serviços de SAN poderá reativar o soquete anterior e retornar o mesmo descritor para o soquete usado anteriormente. Nesse caso, o provedor de serviços de SAN não deve chamar WPUCreateSocketHandle, mas deve continuar a usar o identificador de soquete original fornecido pelo switch. Como alternativa, o provedor de serviços de SAN pode criar um novo soquete, independentemente de um soquete existir anteriormente no processo. Nesse caso, o switch deve chamar a função WSPCloseSocket do provedor de serviços SAN no contexto do próximo processo de controle para descartar o descritor de soquete anterior.

4. O switch reinicia o processamento de novas solicitações do aplicativo no próximo processo de controle.

O switch duplica um soquete de escuta de maneira semelhante, exceto que o switch não precisa suspender uma sessão. O comutador aguarda até concluir todas as chamadas WSPAccept que foram iniciadas pelas chamadas accept e AcceptEx de uma aplicação antes de chamar a função WSPDuplicateSocket do fornecedor de serviços SAN no processo de controlo.

Como o switch suspende o processamento de novas solicitações em um soquete de SAN antes de chamar a função WSPDuplicateSocket do provedor de serviços de SAN, o provedor de serviços de SAN pode liberar todos os recursos associados a um ponto de extremidade local no processo de controle. O provedor de serviços de SAN pode até mesmo encerrar uma conexão subjacente. Se o provedor de serviços de SAN fechar uma conexão subjacente no processo de controle, ele deverá restabelecer a conexão depois que o switch chamar a função WSPSocket do provedor de serviços de SAN no próximo processo de controle. Depois que a chamada WSPSocket retorna, o soquete SAN dentro do processo controlado seguinte deve estar no mesmo estado, na perspetiva do switch, como estava o soquete SAN no processo de controlo antes do switch chamar a função WSPDuplicateSocket do provedor de serviços SAN.

Se uma NIC de SAN oferecer suporte à partilha de recursos entre extremidades que operam em processos diferentes, o fornecedor de serviços de SAN não precisa libertar recursos para uma extremidade local no processo de controlo antes de receber uma chamada WSPDuplicateSocket. Nesse caso, o soquete SAN associado a um ponto de extremidade local permanece inativo no processo de controle anterior até que o switch mude o contexto do soquete de volta para o processo de controle anterior ou chame a função WSPCloseSocket do provedor de serviços SAN para fechar explicitamente o soquete. Como a maioria dos aplicativos executa seu acesso final ao soquete no processo que o criou originalmente — geralmente para fechar a conexão —, o provedor de serviços de SAN pode melhorar o desempenho se o provedor de serviços de SAN preservar o contexto do soquete no processo de controle depois que o switch trocar o controle do soquete para o próximo processo de controle.

Observe que, em todos os casos, um descritor de soquete SAN deve permanecer válido até que o switch chame a função WSPCloseSocket do provedor de serviços SAN para fechar explicitamente o soquete. Mesmo que o provedor de serviços SAN libere todos os recursos para o soquete em um processo específico antes de receber uma chamada WSPDuplicateSocket , o provedor de serviços SAN não deve reutilizar o descritor para o soquete até que o switch chame WSPCloseSocket nesse descritor.

Uma saída inesperada do processo ou alguma outra condição de erro pode interromper a operação de duplicação de soquete de um provedor de serviços SAN. Por exemplo, a escassez de recursos pode causar essa interrupção. O switch trata essas condições de erro como qualquer outra situação de erro. Se necessário, o switch fecha todos os descritores associados ao soquete subjacente em todos os processos para encerrar à força a conexão do soquete. Se possível, o provedor de serviços de SAN no peer remoto deve concluir chamadas WSPRecv que recebem dados de entrada com um código de erro apropriado, como WSAECONNRESET. Esse código de erro informa o peer remoto do término da conexão. Se o switch no peer remoto não receber essa indicação de terminação de conexão, o switch no peer remoto expira uma conexão suspensa se o sistema que solicitou a suspensão falhar.