Sobre a distribuição entre pares
A API de Distribuição de Pares, que oferece suporte ao recurso Cache de Filial no Windows 7, Windows Server 2008 R2, Windows 8 e Windows Server 2012, fornece um conjunto de APIs de plataforma que pode aumentar a capacidade de resposta da rede de aplicações centralizadas quando acessadas a partir de escritórios remotos, ajudando a reduzir a utilização geral da rede de longa distância (WAN) sem interferir nas tecnologias de segurança da rede.
O sistema Peer Distribution oferece um conjunto de APIs de plataforma utilizadas tanto pelos editores que fornecem conteúdo digital quanto pelos consumidores que o solicitam. Para diferenciar facilmente essas funções, pode ser mais fácil pensar no editor em uma função de servidor e no consumidor em uma função de cliente. Além disso, é importante lembrar que, além dessas funções conceituais, o serviço de Peer Distribution é um verdadeiro sistema de pares, como indicado pela capacidade de qualquer nó de Peer Distribution publicar e consumir conteúdo digital. As APIs da plataforma de distribuição peer-to-peer são expostas a editores e consumidores através de uma biblioteca de importação Win32 (PeerDist.Lib).
O ciclo de vida do conteúdo fornecido por um editor e recuperado por um consumidor com o serviço de Peer Distribution é composto pelas seguintes operações:
| Descrição | |
|---|---|
| Publicação de Conteúdo | A publicação é feita para produzir uma descrição do conteúdo denominado Content Informationou Content Info para abreviar. Essas informações de conteúdo podem ser usadas por uma instância do serviço de distribuição entre pares para autenticar e reconstruir o conteúdo. Quando o conteúdo é publicado por um aplicativo no serviço de distribuição de mesmo nível, que é conceitualmente uma operação do lado do servidor, esse conteúdo fica associado à Identidade do Editor, que se baseia no SID do usuário associado ao token de acesso ao thread. Essa vinculação é feita para limitar o acesso ao conteúdo por entidades não autorizadas. No entanto, é importante notar que o acesso às informações de conteúdo é equivalente ao acesso ao próprio conteúdo, pois as informações de conteúdo podem ser usadas para obter o conteúdo de pares ou de um cache hospedado. Há uma nova versão da estrutura de dados de informações de conteúdo no Windows 8; no entanto, a versão anterior ainda é suportada. Para interoperar com clientes Windows 7, um administrador pode configurar o serviço de distribuição de pares para usar a versão anterior da estrutura de dados de informações de conteúdo. |
| Recuperação de Conteúdo | Para que um consumidor recupere conteúdo do serviço de Distribuição entre Pares, deve ser fornecido acesso às Informações de Conteúdo publicadas associadas a esse conteúdo. O serviço de distribuição de pares usado para publicar o conteúdo pode fornecer a informação de conteúdo associada. Depois que o consumidor tiver as Informações de Conteúdo, outras APIs de Distribuição entre Pares podem ser usadas para solicitar conteúdo ao serviço de Distribuição de Pares. O serviço de Distribuição Ponto a Ponto tentará recuperar o conteúdo da rede local. Se o conteúdo não estiver disponível, o aplicativo cliente será responsável por recuperar o conteúdo do servidor de origem. |
| Remoção de Publicação | Para aplicações que publicaram conteúdo no serviço de distribuição de mesmo nível, a função PeerDistServerUnpublish foi fornecida para permitir que o conteúdo seja despublicado. Depois que o conteúdo for despublicado, o serviço local de Distribuição entre Pares não fornecerá mais as informações associadas a esse conteúdo. |
Conclusão assíncrona
A API de Distribuição Ponto a Ponto suporta um modelo de API assíncrono e, como resultado, as APIs de Distribuição Ponto a Ponto permitem o uso de Portas de Conclusão de E/S ou Eventos como mecanismos de sinalização para processar operações assíncronas de conclusão na Distribuição Ponto a Ponto. Para qualquer mecanismo, a Distribuição de Pares usa uma estrutura OVERLAPPED. Em geral, a Distribuição de Pares assume a propriedade de uma estrutura de OVERLAPPED e de quaisquer parâmetros de saída que o Cliente passe para funções assíncronas da API. O Cliente não deve acessar esses recursos até que a função assíncrona específica seja concluída. Assim que as funções assíncronas se completarem, o serviço de Distribuição entre Pares não exigirá mais acesso a esses recursos e eles poderão ser reutilizados conforme o aplicativo de chamada considerar apropriado.
Não haverá nenhuma conclusão assíncrona se a função retornar qualquer código de erro diferente de ERROR_IO_PENDING. O retorno de um valor diferente de ERROR_IO_PENDING significa que a chamada falhou de forma síncrona. Se a API de Distribuição de Ponto retornar ERROR_IO_PENDING, o chamador deverá aguardar a conclusão assíncrona.
O código de erro da conclusão assíncrona pode ser recuperado de duas maneiras:
Porta de Conclusão Baseada em Porta de Entrada/Saída
O utilizador invoca o mecanismo de porta de conclusão de E/S fornecendo um identificador de porta de conclusão e uma chave de conclusão para as seguintes funções da API:
PeerDistRegisterForStatusChangeNotification
PeerDistServerPublishStream
PeerDistServerOpenContentInformation
PeerDistClientOpenContent
O usuário cria uma porta de conclusão chamando CreateIoCompletionPort. Esse identificador de porta de conclusão pode ser usado simultaneamente para outras operações de E/S assíncronas, bem como para operações específicas de Distribuição entre Pares.
O chamador deve usar a função GetQueuedCompletionStatus para gerir a conclusão assíncrona. Se a operação assíncrona falhar, a função GetQueuedCompletionStatus retornará FALSE e GetLastError retornará o código de erro apropriado. O chamador deve ignorar todos os campos da estrutura OVERLAPPED se o código de erro for diferente de ERROR_SUCCESS. A operação assíncrona terá êxito se a função GetQueuedCompletionStatus retornar TRUE.
Para mais informações, consulte Portas de Conclusão de E/S.
Conclusão Baseada em Eventos
Se o chamador definir um identificador de Evento válido para o campo hEvent da estrutura OVERLAPPED, a Distribuição por Pares usará esse identificador para sinalizar que a operação de I/O assíncrona associada foi concluída.
Um chamador de thread pode gerenciar operações sobrepostas especificando um identificador para o evento de redefinição manual do objeto da estrutura OVERLAPPED em uma das funções de espera. Depois que o evento é sinalizado, o chamador deve chamar PeerGetOverlappedResult passando na estrutura de OVERLAPPED apropriada. PeerGetOverlappedResult retornará FALSE e o chamador deve chamar GetLastError para recuperar o código de erro. O chamador deve ignorar todos os campos da estrutura OVERLAPPED se o código de erro for algo diferente de ERROR_SUCCESS. A operação assíncrona será bem-sucedida se a função PeerGetOverlappedResult retornar TRUE.
Se o chamador fornecer uma porta de conclusão junto com um evento, o evento será usado como o mecanismo de conclusão.
Windows 7: Usar a função GetOverlappedResult em vez de PeerGetOverlappedResult.