Duplicando 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 por 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 DuplicateHandle do Win32

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

• Usando o mecanismo de herança de identificador

  Um processo filho (o processo de não controle) herda todos ou alguns dos identificadores criados em seu processo pai (o processo de controle).

• Durante o fechamento normal da conexão

  Se um aplicativo no processo de controle fechar um soquete e sair enquanto alguns dados ainda estiverem para serem enviados, esses dados restantes serão armazenados em buffer na DLL do Windows Sockets. Outro aplicativo no contexto do processo de serviço do sistema (o processo de não controle) envia esses dados posteriormente.

A opção Windows Sockets, em conjunto com o provedor TCP/IP, detecta e manipula cada uma das condições anteriores. A opção permite que apenas um processo por vez execute operações que transferem dados ou alterem o estado de um soquete compartilhado subjacente. Processa o controle de troca dinâmica do soquete subjacente, conforme necessário, para executar operações solicitadas. A opção serializa operações que diferentes processos solicitam executar em um soquete compartilhado e executa essas operações na ordem FIFO (primeiro a entrar primeiro a sair). A opção aguarda a conclusão de todas as operações em andamento antes de trocar o controle de um soquete subjacente por outro processo. Logicamente, a opção assume o controle do soquete subjacente longe do processo de controle assim que um processo de não controle solicita uma operação de qualificação. Depois que o controle é retirado, a opção trata o processo de controle original como um processo de não controle se o processo de controle original solicita operações qualificadas. Observe que a opção não executa nenhuma ação em um identificador de soquete duplicado até que o processo de não controle realmente use o identificador de soquete duplicado para uma transferência de dados ou operação de alteração de estado.

A opção e o provedor de serviços SAN apropriado são carregados em todos os processos que compartilham o acesso a um soquete subjacente específico. A opção 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 provedor de serviços san é necessário para manter seu contexto de soquete e informações de estado de conexão somente no processo que tem controle do soquete subjacente em qualquer ponto no tempo determinado. O provedor de serviços 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 a opção exigir a troca, conforme descrito na sequência a seguir. Para minimizar a quantidade de recursos necessários para troca, um provedor de serviços san pode manter suas informações de contexto e estado de conexão em todos os processos que compartilham um soquete subjacente.

Como a opção 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 , a opção não pode solicitar que o provedor de serviços SAN execute uma operação de troca 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 a opção 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 SAN não troca o controle do soquete até que todas as operações de transferência de dados iniciadas pelo processo de controle tenham sido concluídas.

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

A opção executa as seguintes etapas para trocar o controle de um soquete SAN conectado do processo de controle para o processo de controle seguinte (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. A opção 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, a opção chamará a função WSPSend do provedor de serviços SAN para enviar uma mensagem a um par conectado para solicitar uma 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, a opção na conexão par suspende o processamento de novas solicitações de aplicativo, aguarda que todas as operações de envio e RDMA em andamento no soquete SAN sejam concluídas e libera toda a memória RDMA. Em seguida, a conexão de par envia uma mensagem de resposta indicando que a sessão está suspensa. Ao receber essa mensagem de confirmação, a opção 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, soquetes SAN em ambos os pontos de extremidade 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, a opção na conexão de ponto remoto enfileira novas solicitações de bloqueio ou sobrepostas, armazena em buffer novos envios sem bloqueio para a configuração SO_SNDBUF, falha em novos envios sem bloqueio depois que o limite de buffer é atingido e falha em todos os novos recebimentos sem bloqueio com WSAEWOULDBLOCK. A opção local no processo de controle manipula novas solicitações no soquete do aplicativo como se o processo não tivesse controle do soquete.

2. Depois que a sessão é suspensa, a opção chama a função WSPDuplicateSocket do provedor de serviços SAN no processo de controle para direcionar o provedor de serviços SAN para transferir o contexto de soquete para o espaço de endereço do processo de controle seguinte. A opção especifica o processo de controle seguinte 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 soquete com êxito status e zero bytes. O provedor de serviços SAN também deve liberar automaticamente todos os buffers associados a essas solicitações. O provedor de serviços SAN libera todos os buffers, pois o comutador 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, a opção salva o valor no membro dwProviderReserved da estrutura WSAPROTOCOL_INFOW para a qual o parâmetro de saída lpProtocolInfo aponta. A opção usa esse valor para identificar o soquete subjacente no contexto do processo de controle seguinte. 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 comutador no parâmetro dwProcessId de WSPDuplicateSocket.

3. Depois que o contexto do soquete é transferido para o espaço de endereço do processo de controle seguinte, a opção chama a função WSPSocket do provedor de serviços SAN no contexto do processo de controle seguinte. Nessa chamada, a opção 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 processo de controle seguinte não solicitou 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 processo de controle seguinte, o provedor de serviços SAN poderá reativar o soquete anterior e retornar o mesmo descritor para o soquete que foi usado anteriormente. Nesse caso, o provedor de serviços SAN não deve chamar WPUCreateSocketHandle, mas deve continuar a usar o identificador de soquete original fornecido pelo comutador. Como alternativa, o provedor de serviços SAN pode criar um novo soquete, independentemente de um soquete existir anteriormente no processo. Nesse caso, a opção deve chamar a função WSPCloseSocket do provedor de serviços SAN no contexto do processo de controle seguinte para descartar o descritor de soquete anterior.

4. A opção reinicia o processamento de novas solicitações do aplicativo no processo de controle seguinte.

A opção duplica um soquete de escuta de maneira semelhante, exceto que a opção não é necessária para suspender uma sessão. A opção aguarda até concluir todas as chamadas WSPAccept que foram iniciadas pelas chamadas accept e AcceptEx de um aplicativo antes de chamar a função WSPDuplicateSocket do provedor de serviços SAN no processo de controle.

Como a opção suspende o processamento de novas solicitações em um soquete SAN antes de chamar a função WSPDuplicateSocket do provedor de serviços SAN, o provedor de serviços SAN pode liberar todos os recursos associados a um ponto de extremidade local no processo de controle. O provedor de serviços SAN pode até mesmo encerrar uma conexão subjacente. Se o provedor de serviços SAN fechar uma conexão subjacente no processo de controle, o provedor de serviços SAN deverá restabelecer a conexão depois que a opção chamar a função WSPSocket do provedor de serviços SAN dentro do processo de controle seguinte. Depois que a chamada WSPSocket retorna, o soquete SAN dentro do processo de controle seguinte deve estar no mesmo estado, da perspectiva do comutador, já que o soquete SAN no processo de controle era antes da opção chamar a função WSPDuplicateSocket do provedor de serviços SAN.

Se uma NIC san dá suporte ao compartilhamento de recursos entre pontos de extremidade executados em processos diferentes, o provedor de serviços SAN não precisa liberar recursos para um ponto de extremidade local no processo de controle 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 a opção troque o contexto do soquete de volta do processo de controle seguinte 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 SAN poderá melhorar o desempenho se o provedor de serviços SAN preservar o contexto de soquete no processo de controle depois que a opção alternar o controle do soquete para o processo de controle seguinte.

Observe que, em todos os casos, um descritor de soquete SAN deve permanecer válido até que a opção 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 a opção 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, uma escassez de recursos pode causar essa interrupção. A opção trata essas condições de erro, pois faz qualquer outra situação de erro. Se necessário, o comutador fecha todos os descritores associados ao soquete subjacente em todos os processos para encerrar a conexão do soquete com força. Se possível, o provedor de serviços SAN no par remoto deverá concluir chamadas WSPRecv que recebem dados de entrada com um código de erro apropriado, como WSAECONNRESET. Esse código de erro informa o par remoto do encerramento da conexão. Se a opção no par remoto não receber essa indicação de encerramento de conexão, a opção no par remoto atingirá o tempo limite de uma conexão suspensa se o sistema que solicitou a suspensão falhar.