Estruture o poder da comunicação ponto a ponto no Windows Vista e no WCF

Justin Smith

Nesta página

	Quando a maioria de nós pensa sobre...
	Protocolo PNRP
	PeerChannel
	Pessoas ao meu Redor
	Conclusão

Quando a maioria de nós pensa sobre...

Quando a maioria de nós pensa sobre aplicativos ponto a ponto, pensa, instintivamente, em aplicativos de mensagens instantâneas, programas de compartilhamento de arquivos simples e jogos. Em grande parte, fomos condicionados a padronizar com o modelo cliente/servidor ao considerarmos designs de aplicativos distribuídos e raramente fornecemos modelos ponto a ponto, mesmo que nos lembremos deles, especialmente para aplicativos comerciais. A principal razão para esse foco no modelo cliente/servidor é simples: o desenvolvimento de aplicativos ponto a ponto costuma ser caro e demorado.

Tradicionalmente, os desafios ao desenvolvimento de aplicativos ponto a ponto incluíam a necessidade de desenvolver protocolos proprietários para troca de mensagens, tendo que localizar e se conectar a instâncias de um aplicativo oculto por trás de uma NAT (Conversão de endereços de rede) ou um firewall, e a necessidade de oferecer suporte à infra-estrutura inevitável e necessária para localizar aplicativos em uma WAN (rede de longa distância). Esses desafios, embora superáveis, representavam uma barreira substancial e, por conseqüência, muitos de nós nunca levaram em conta a surpreendente funcionalidade colaborativa que os aplicativos ponto a ponto oferecem.

Essas barreiras serão consideravelmente reduzidas com o lançamento do Windows Vista^™ e do .NET Framework que o acompanha. A combinação dos aprimoramentos do Windows Vista com o PNRP (Protocolo de resolução de nomes de ponto), o PNM (Pessoas ao meu Redor) e a introdução do PeerChannel no Windows^® Communication Foundation tornou os aplicativos ponto a ponto muito mais abordáveis. Eu, pessoalmente, espero um aumento de atividade na área ponto a ponto após o lançamento do Windows Vista.

O desenvolvimento ponto a ponto no Windows Vista é um tópico muito amplo, sendo assim um único artigo não pode esgotar o assunto. Portanto, em vez de tentar o impossível, apresentarei algumas das diferentes tecnologias ponto a ponto do Windows Vista e transmitirei um pouco de experiência para seus esforços de desenvolvimento ponto a ponto.

Além de pressupor que você tenha um conhecimento básico do Windows Forms, também vou assumir que você já esteja minimamente familiarizado em escrever aplicativos do Windows Communication Foundation. Caso contrário, convém adquirir algumas noções básicas, lendo um pouco do conteúdo disponível no Windows SDK ou em wcf.netfx3.com/content/resources.aspx.

Noções básicas sobre ponto a ponto: Redes em malha

Antes de mergulhar nas tecnologias ponto a ponto específicas, é importante examinar alguns princípios básicos dos aplicativos ponto a ponto. Para iniciantes, um aplicativo ponto a ponto é um aplicativo que se conecta diretamente a outras instâncias do aplicativo. Na linguagem ponto a ponto, cada instância do aplicativo denomina-se nó. O agrupamento de nós nomeado e conectado é freqüentemente denominado malha. Por conseqüência, as tecnologias que facilitam o desenvolvimento de aplicativos ponto a ponto são, com freqüência, denominada tecnologias de malha. O PNRP, o PeerChannel (no Windows Communication Foundation) e o PNM são, todos, exemplos de tecnologias de malha no Windows Vista.

Topologias de malha

Todas as tecnologias de malha do Windows Vista produzem malhas que têm mais ou menos a mesma topologia. Uma topologia de malha é, geralmente, uma abstração do padrão de conexão com os nós na malha. Para ilustrar, imagine mentalmente uma malha. Aposto que você imaginou uma malha muito semelhante àquela da Figura 1.

Figura 1 Malha totalmente conectada

Cada um dos quatro nós na malha da Figura 1 está conectado a todos os outros nós dela. Em outras palavras, se houver N nós na malha, cada nó manterá N - 1 conexões. Uma malha que atende a esse critério é considerada totalmente conectada. Malhas totalmente conectadas raramente são uma boa idéia; para sabermos por quê, consideremos a conexão entre os nós.

Nós em uma malha normalmente se comunicam usando transportes existentes e familiares. Como todo sistema operacional moderno, o Windows Vista utiliza TCP/IP e UDP para comunicação em rede. Se o transporte escolhido para uma malha totalmente conectada for o TCP/IP, cada nó na malha de N nós deverá criar ou aceitar N - 1 soquetes. À medida que N aumentar, o modelo se tornará claramente inviável. Por exemplo, se você considerasse o caso de N = 1000, cada nó precisaria manter 999 soquetes, o que simplesmente não funciona.

Para resolver os problemas de escalabilidade e de conectividade WAN, você deve buscar uma malha que seja parcialmente conectada, como a da Figura 2. Como o nome diz, nós em uma malha parcialmente conectada estão conectados apenas a alguns outros nós dela. Em termos ponto a ponto, esses nós adjacentes são chamados vizinhos. Em geral, uma malha parcialmente conectada coloca poucas demandas de recursos em cada nó, aumentando, assim, sua escalabilidade de modo considerável. Em teoria, uma malha parcialmente conectada pode crescer para incluir todos os aplicativos de todos os computadores do mundo.

Figura 2 Malha parcialmente conectada

União à malha

O modo pelo qual um nó se une a uma malha depende da tecnologia de malha usada, mas, falando genericamente, um nó candidato deve usar o nome de malha para resolver os endereços físicos de um ou mais nós que já se encontram na malha. Se você pressupor uma malha parcialmente conectada, o resultado da resolução de nome de malha será um subconjunto dos endereços físicos nela disponíveis. Ao receber os endereços físicos de um ou mais nós físicos da malha, o nó candidato deve, então, conectar-se a um, alguns ou todos os endereços. Após se conectar à malha, o nó recém-adicionado deve, em seguida, ficar pronto para responder a resoluções de nome de malha subseqüentes solicitados por outros nós candidatos.

A resolução de nome de malha é um tópico complexo.

Muito dessa complexidade se deve ao fato de que, em muitos casos, a resolução de um nome de malha depende de uma ou mais malhas. Para ilustrar, considere a malha usada pelo Serviço postal dos EUA. Mais especificamente, vamos supor que eu precise enviar uma encomenda para meu amigo Wilson. Para enviar a encomenda, talvez eu precise ir a uma agência dos correios. Se eu não souber aonde fica a agência dos correios mais próxima, posso entrar na Internet e procurar o endereço dela. Em um sentido abstrato, para "conectar-me" à malha do serviço postal dos EUA, eu precisei, primeiro, ir até a maior malha de todas, a Internet, para resolver o endereço do nó mais próximo. Em outras palavras, você pode usar uma malha para resolver os endereços contidos em outra malha. Discutirei este conceito na seção sobre o PNRP deste artigo.

Comunicação com outros nós

Uma vez conectado a uma malha, um nó pode se comunicar com outros nós de duas formas: inundação da malha (também chamado de mensagens entre vários participantes) ou mensagens direcionais. Como o nome implica, a inundação da malha é uma tentativa de enviar uma mensagem a todos os seus nós. Em geral, um nó em uma malha pode propagar uma mensagem para todos os outros nós, enviando a mensagem a todos os seus vizinhos. Ao receber a mensagem, o vizinho do nó remetente é responsável por encaminhá-la a seus vizinhos e assim por diante. Por outro lado, mensagens direcionais são uma tentativa de direcionar uma mensagem a um determinado nó da malha. Em uma malha parcialmente conectada, o nó remetente inicial pode não estar conectado ao destinatário pretendido. Se for esse o caso, o nó remetente inicial deverá enviar a mensagem a um ou mais de seus vizinhos. Um vizinho pode estar conectado ao destinatário pretendido. Sendo assim, o vizinho poderá encaminhar a mensagem a ele. Caso contrário, o vizinho buscará um palpite sobre qual de seus vizinhos pode estar conectado ao destinatário pretendido.

As malhas raramente são estáticas.

Na maioria dos aplicativos ponto a ponto, normalmente os nós podem se unir à malha ou deixá-la, seja devido a alterações na conectividade da rede, seja, no caso de um aplicativo de mensagens instantâneas, devido a um usuário iniciar e interromper o aplicativo. Além das alterações naturais em uma malha, a maioria das tecnologias de malha possui algum mecanismo para mantê-las. Em geral, a meta dessa manutenção é consertar ou sintonizar a malha de modo que ela opere com mais eficácia ou fique mais robusta. É importante observar que cada tecnologia de malha implementa a manutenção de maneira diferente.

Início da página

Protocolo PNRP

Como o nome diz, o PNRP foi projetado para resolver endereços físicos com base, entre outras coisas, em um nome de malha. O PNRP está disponível para Windows XP Service Pack 1 (SP1) com o Advanced Networking Pack, Windows XP SP2 e Windows XP Professional x64 Edition. O Windows Vista também será entregue com a versão 2 do PNRP. No nível mais simples, o próprio PNRP é um aplicativo ponto a ponto na forma de um formulário de serviço Windows e a malha de nós PNRP é usada exclusivamente para descobrir os endereços físicos dos nós participantes em outras malhas. (Consulte a barra lateral "Instalação do PNRP no Windows XP" para obter mais informações.)

PNRP e IPv6

O PNRP se baseia no IPv6 (Protocolo de Internet versão 6). Como o IPv6 é inédito para a maioria dos desenvolvedores, é importante que eu mencione pelo menos um de seus aspectos mais significativos antes de discutir a mecânica do PNRP. No IPv6, o endereço é um valor de 128 bits (o que permite, aproximadamente, 3,4 x 10³⁸ combinações de endereços). O tamanho do pool de endereços do IPv6 habilita um de seus mais importantes recursos, o endereçamento ponta a ponta, mesmo quando os endereços estão gravados em várias sub-redes e contidos atrás de um NAT. Para obter mais informações sobre o IPv6 e as tecnologias que permitem seu uso em uma infra-estrutura IPv4, consulte microsoft.com/technet/itsolutions/network/ipv6/introipv6.mspx.

Um exemplo de PNRP

Os protótipos de função, as estruturas e os códigos de erro do PNRP estão definidos no arquivo de cabeçalho p2p.h do Windows SDK. Se um aplicativo quiser registrar um nome de malha com o PNRP, ele deverá fazê-lo através da API do Windows, via código não gerenciado, ou por código gerenciado através dos recursos P/Invoke do CLR (Common Language Runtime). Atualmente, não há invólucro gerenciado no .NET Framework para o componente PNRP da API do Windows. Contudo, é possível acessar o PRNP usando o utilitário de linha de comando netsh. Por meio do netsh, você pode registrar um novo nome com o PNRP, desta forma:

c:\temp>netsh
netsh>p2p pnrp peer
netsh p2p pnrp peer>add 0.justinsmith
Ok.

O parâmetro de linha de comando 0.

justinsmith é o nome ponto a ponto. Quando esse comando é executado, a infra-estrutura do PNRP gera uma ID PNRP, associa-a ao nome ponto a ponto e atribui-lhe um endereço IPv6 e IPv4. Se você mudar para uma máquina que tiver o PNRP instalado e iniciado, será possível resolver o nome de malha 0.justinsmith com este comando netsh:

netsh p2p pnrp peer>resolve 0.justinsmith
Resolve started...
Found:  Comment:    gonzo
        Addresses:  [0000:0000:0000:0000:0000:0000:0000:0001]:8350 udp
                    192.168.42.100:8350 tcp

A saída do comando de resolução precisa de algumas explicações.

Primeiro, o campo Comment representa o nome da máquina na qual 0.justinsmith foi registrado (eu batizo minhas máquinas com os personagens dos Muppets). Este campo é preenchido automaticamente pelo netsh e não pode ser usado como parte do processo de resolução. Agora, observe os endereços IPv6 e IPv4 atribuídos ao nó. Este é um recurso do netsh e da tecnologia de transição Teredo que permite tráfego de IPv6 em uma rede IPv4. Admito que apenas comecei a esboçar a superfície de PNRP, mas já mostrei que o PNRP permite o uso de um nome ponto a ponto para resolver um endereço IP. Para obter mais informações sobre o PNRP, consulte microsoft.com/technet/prodtechnol/winxppro/deploy/p2pintro.mspx(em inglês).

Início da página

PeerChannel

Um dos maiores benefícios do Windows Communication Foundation é que ele oferece um modelo de programação universal para vários sabores diferentes de aplicativos distribuídos. Por exemplo, o código necessário para escrever um aplicativo distribuído que se comunique via mensagens com codificação binária sobre TCP/IP é muito semelhante ao código necessário para escrever um aplicativo distribuído que se comunique via mensagens interoperáveis compatíveis com WS sobre HTTP. Um dos recursos menos conhecidos do Windows Communication Foundation é seu suporte à criação de aplicativos ponto a ponto usando esse mesmo modelo de programação universal. Devido a seu suporte a aplicativos ponto a ponto, o Windows Communication Foundation pode ser visto como tecnologia de malha, mas, na realidade, somente seu módulo PeerChannel dedica-se à criação de aplicativos ponto a ponto. Por essa razão, é comum que o termo PeerChannel seja usado para se referir aos recursos ponto a ponto do Windows Communication Foundation. Independente de como seja chamado, o PeerChannel do Windows Communication Foundation oculta, virtualmente, toda a complexidade tradicionalmente associada ao desenvolvimento de um aplicativo ponto a ponto e é, a meu ver, uma virada de jogo nesse campo.

A malha do PeerChannel

A malha do PeerChannel foi projetada para inundação de mensagens. Todavia, o PeerChannel contém mecanismos que podem propagar uma mensagem para parte da malha, em vez da malha inteira. Por esse motivo, é mais preciso dizer que uma malha PeerChannel está desenhada para mensagens entre vários participantes.

A estrutura da malha PeerChannel é ditada pelo número de vizinhos a que cada nó está conectado. Por isso, a malha PeerChannel mantém ativamente a sua estrutura. O efeito dessa manutenção é uma malha robusta e uniformemente distribuída. Para ser mais específico, um nó na malha tenta manter entre duas e sete conexões com vizinhos. Esses limites representam uma ação de equilíbrio entre as demandas de recursos no nó local e a manutenção de uma malha robusta.

Se um nó entrar na malha com três vizinhos e dois de seus vizinhos deixarem a malha, esse nó começará um ciclo de manutenção, na tentativa de adquirir novas conexões com vizinhos. Da mesma forma, um nó com menos que sete vizinhos aceitará novas conexões com vizinhos até esse limite de sete. Um nó PeerChannel é considerado idealmente conectado quando tem três vizinhos, mas ele aceitará até sete vizinhos, para que um nó que tenha caído abaixo do limite mínimo possa obter rapidamente novos vizinhos. É importante observar que o código de seu aplicativo não pode alterar esses limites, nem exercer nenhum controle sobre a manutenção da malha. Estes detalhes cuidam da integridade da infra-estrutura PeerChannel segundo uma base nó a nó.

O PeerChannel oferece resolvedores PNRP e personalizados como meio para um nó candidato descobrir o endereço de nós já existentes na malha. Independente do método de resolução escolhido, a idéia geral é a mesma: passar o nome da malha para o resolvedor e receber uma lista de endereços IP de outros nós na malha. Uma vez produzida a lista de endereços pela resolução, o nó PeerChannel candidato se conecta concorrentemente a cada um dos endereços. Quando um nó que já está na malha PeerChannel recebe uma das solicitações de conexão, ele pode aceitá-la ou recusá-la. Se a conexão for aceita, o nó existente enviará ao nó recém-associado uma mensagem de boas-vindas que contém, entre outras coisas, uma lista com os endereços dos outros nós da malha. Se a conexão for recusada, o nó existente enviará ao nó candidato uma mensagem de recusa, contendo o motivo da recusa e uma lista com os endereços dos outros nós da malha.

O ponto importante aqui é que a resolução de nome de malha (via resolvedor PNRP ou personalizado) não é a única maneira de se obter uma lista de endereços para um nó candidato no PeerChannel. Este recurso permite aos nós ficarem idealmente conectados mais rapidamente do que se a resolução de nome de malha fosse o único meio de se obter um endereço para o nó candidato. Este recurso permite, ainda, que os nós na malha exerçam controle sobre a quantidade de nós mantidos pelos vizinhos, o que, por sua vez, tem um impacto sobre a robustez da malha.

A comunicação dentro de uma malha PeerChannel está sintonizada para manter a transmissão de mensagens repetitivas mínima. Quando um nó envia uma mensagem para a malha, ele está, na verdade, enviando-a a seus vizinhos. Ao receber uma mensagem, cada vizinho a inspeciona e a encaminha para seus vizinhos. Se um nó PeerChannel receber uma mensagem de um vizinho, ele não a encaminhará de volta para aquele vizinho. Além disso, se um nó PeerChannel receber com freqüência uma mensagem já recebida e processada de um vizinho, a conexão com tal vizinho será encerrada no próximo ciclo de manutenção. Esses recursos são implementados por um cache local em cada nó. Internamente, cada nó em uma malha PeerChannel faz o cache do valor da ID de Mensagem de endereçamento WS e de um identificador do vizinho que entregou a mensagem. O nó verifica esse cache para decidir a quais vizinhos deve entregar a mensagem. A combinação desses recursos resulta em uma malha sintonizada para entregar mensagens a seus nós com um mínimo de repetição e consumo de largura de banda da rede.

Conforme já mencionei, um nó PeerChannel também pode enviar uma mensagem para um subconjunto dos nós da malha. Isso é feito por meio da atribuição de uma contagem de saltos à mensagem, que é, na verdade, uma maneira de controlar o número de nós pelos quais a mensagem é encaminhada. Não confunda este mecanismo com mensagens direcionais, nas quais a mensagem se destina a um nó em particular. A contagem de saltos é, antes, uma forma de desenhar uma fronteira difusa ao redor dos nós que receberão a mensagem. Por exemplo, se um nó PeerChannel (Nó A) tem três vizinhos e envia uma mensagem para a malha com uma contagem de saltos de 1, a mensagem será entregue a três nós. Da mesma forma, se cada vizinho do Nó A tiver três outros vizinhos e o Nó A enviar uma mensagem à malha com uma contagem de saltos de 2, a mensagem será entregue a nove nós. Entretanto, se houver vizinhos comuns a alguns vizinhos do Nó A, esse número diminuirá proporcionalmente.

Fisicamente, a contagem de saltos é expressa em uma mensagem como um número inteiro em um bloco do cabeçalho. Quando um nó recebe uma mensagem que contém uma contagem de saltos, ele inspeciona o valor indicado. Se o valor for maior que zero, o nó diminuirá a contagem de saltos de forma monotônica e encaminhará a mensagem (com o valor de saltos já reduzido) aos vizinhos apropriados. Se a mensagem recebida contiver uma contagem de saltos igual a zero, ela não será encaminhada. Também é importante observar que o bloco de cabeçalho com a contagem de saltos é excluído da assinatura da mensagem e, portanto, esse valor não tem impacto sobre a integridade da assinatura digital aplicada à mensagem, além de impedir a sobrecarga associada à repetida geração de assinaturas digitais e à sua serialização nos componentes apropriados da mensagem.

Exemplo de PeerChannel

Vamos criar um aplicativo ponto a ponto simples, chamado PictureViewer, usando o PeerChannel e o Windows Forms. A finalidade do aplicativo, como você já deve ter percebido pelo nome, é permitir que todos os nós na malha visualizem a mesma foto. Em um nível mais alto, as etapas necessárias para a criação desse aplicativo são as seguintes:

A Figura 3 mostra o aplicativo pronto. As etapas 1 e 2 são necessárias para o desenvolvimento de qualquer aplicativo Windows Forms; portanto, não vou mostrá-las aqui. Assim como em qualquer aplicativo Windows Communication Foundation, a primeira etapa de desenvolvimento é definir o contrato de serviços. Um contrato de serviços a ser usado pelo PeerChannel é semelhante a outros contratos do Windows Communication Foundation, exceto pelo fato de que o PeerChannel exige que todas as anotações de OperationContractAttribute definam a propriedade da instância IsOneWay como verdadeira. Essa propriedade declara que o receptor da mensagem não deve enviar uma resposta. Se desejar que o receptor envie uma resposta, você poderá definir o contrato de serviços como duplex, mas cada anotação de OperationContractAttribute deve, ainda assim, estar com a propriedade da instância IsOneWay definida como verdadeira. Para os fins deste exemplo, não vou criar um contrato duplex (há vários exemplos deles no Windows SDK). O contrato que usarei é o seguinte:

[ServiceContract]
interface IPictureViewer {
    [OperationContract(IsOneWay = true)]
    void SharePicture(Stream stream);
}

Figura 3 O aplicativo ponto a ponto PictureViewer (clique na imagem para aumentá-la)

Observe que o método de interface SharePicture está anotado com o atributo OperationContractAttribute e a propriedade da instância IsOneWay está definida como verdadeira. A operação SharePicture aceita System.IO.Stream como parâmetro porque ela será usada para propagar os bytes da foto para outros nós na malha.

Definido nosso contrato de serviços, é hora de adicionar o código do Windows Communication Foundation que fará a conexão de nosso aplicativo com a malha PeerChannel e esperará passivamente pelas mensagens da malha. Primeiro, eu implemento no Formulário meu contrato de serviços recém-definido. Em seguida, defino um campo do tipo ServiceHost. As mensagens recebidas serão despachadas para uma instância única do tipo frmPictureViewer. Para indicar essa funcionalidade, preciso atribuir o ServiceBehavior adequado para o tipo frmPictureViewer. Essas duas etapas são mostradas na Figura 4.

Depois, preciso criar uma instância para um ServiceHost, adicionar um ponto de extremidade e começar a escutar a entrada de mensagens. Como estou criando um aplicativo Windows Forms, o lugar lógico para fazer isso é o construtor do formulário, como mostra a Figura 5.

Neste ponto, já fiz tudo o que preciso para fazer a conexão com a malha e escutar mensagens. Em comparação com o código padrão do Windows Communication Foundation, as únicas coisas diferentes são o esquema de URI (net.p2p), a ligação (NetPeerTcpBinding) que estou usando e a adição de segurança baseada em senha. É importante observar que optei por colocar a senha da malha diretamente no código. Não faça isso em seus aplicativos dinâmicos se quiser que a senha da malha fique em segredo.

Assim que eu chamar ServiceHost.Open, nosso aplicativo tentará resolver o nome de malha (pictureView) via PNRP. Neste ponto, posso verificar que nosso aplicativo PeerChannel está usando PNRP por meio da execução de um comando netsh para listar os nomes dos pontos registrados. Se o PNRP conseguir resolver o nome de malha para um ou mais endereços IP, nosso aplicativo tentará se conectar a esses nós. Caso contrário, ele se conectará ao primeiro nó da malha. Como já foi dito, os nós existentes aceitarão ou rejeitarão a conexão, enviando uma mensagem de boas-vindas ou de recusa. O ponto importante aqui é que isso pode acontecer após o retorno da chamada de ServiceHost.Open.

Enviando uma mensagem para outros nós

Para compartilhar uma foto, preciso primeiro carregá-la. O código necessário para fazer isso é o código básico do Windows Forms: primeiro, criar uma instância de uma OpenFileDialog, obter uma Stream, convertê-la em Image e fazer referência a ela através da propriedade PictureBox.Image. Espere um minuto. Não é isso que o método SharePicture faz? Para dizer a verdade, sim. Em essência, tudo o que preciso fazer para carregar a imagem na PictureBox é chamar o método SharePicture e transmitir a Stream retornada pela OpenFileDialog.OpenFile como parâmetro.

Para enviar uma mensagem que contém a foto para outros nós na malha, preciso escrever algumas linhas de código, mas ele é quase idêntico ao código que teria que ser escrito para qualquer outro aplicativo Windows Communication Foundation. Para iniciantes, preciso definir campos no meu formulário dos tipos ChannelFactory<IPictureViewer> e IPictureViewer. Depois, preciso criar instâncias dessas variáveis no construtor do formulário. Essas etapas são mostradas na Figura 6.

Observe que é preciso usar a mesma senha e certificado (usado para criar uma assinatura digital da mensagem) de malha utilizados na configuração do ServiceHost. Fora isso, esse código é idêntico ao código necessário para aplicativos Windows Communication Foundation que não sejam PeerChannel.

Agora que já criei minha infra-estrutura de envio, posso usá-la para enviar uma mensagem para os outros nós na malha. Para fazer isso, basta escrever um manipulador de eventos para o botão de compartilhamento, desta forma:

private void btnShare_Click(object sender, EventArgs e)
{
    using(MemoryStream stream = new MemoryStream())
    {
        Image image = pbView.Image;
        image.Save(stream, ImageFormat.Jpeg); // store image in stream
        stream.Position = 0; // reset the position
        channel.SharePicture(stream); // send a message to the mesh
    }
}

Neste mundo insano, o PeerChannel simplifica bastante o desenvolvimento de aplicativos ponto a ponto. A versão em funcionamento total do PictureViewer tem cerca de 150 linhas de código-fonte, a maior parte delas é dedicada à infra-estrutura do Windows Forms. O aplicativo totalmente funcional contém uma implementação de contagem de saltos e está disponível para download no siteMSDN^®Magazine.

Início da página

Pessoas ao meu Redor

O PNM é uma tecnologia de malha integrada ao Windows Vista que permite que grupos de dispositivos e pessoas próximas se descubram, se conectem, convidem e colaborem umas com as outras. O PNM é bem adequado para tarefas como jogar um jogo em uma cafeteria com várias pessoas ao redor, compartilhar sua área de trabalho com um colega de trabalho ou até mesmo se conectar a um projetor em uma sala de conferências. Os recursos oferecidos pelo PNM são vastos e é de se supor que, uma vez lançados, a comunidade de desenvolvedores encontre maneiras novas e inventivas de utilizar essa tecnologia. É importante observar que o PNM é uma tecnologia de malha que depende completamente de consentimento e encontra-se desativada por padrão.

A arquitetura do PNM é composta, entre outras coisas, por um aplicativo ponto a ponto chamado p2phost.exe. Quando executado, esse processo cria uma malha conectando-se a instâncias do p2phost.exe em outras máquinas. Em geral, a finalidade dessa malha é o envio de mensagens direcionais. Mais especificamente, o PNM foi desenvolvido para resolver nós locais e se comunicar com um subconjunto deles. A API do PNM está disponível como componente da API do Windows e, na maior parte da vezes, se concentra na configuração do comportamento do p2phost.exe.

Falando genericamente, as principais categorias da API do PNM incluem funções, estruturas, eventos e códigos de erro que proporcionam a capacidade de registrar um aplicativo com o PNM, convidar outros a se associarem a uma sessão colaborativa, iniciar um aplicativo registrado, criar um contato persistente e convidar um contato que não seja mais local. A barra lateral "Um exemplo de Pessoas ao meu Redor do mundo real" ilustra o processo. Observe que não há suporte para que um aplicativo se comunique usando PNM. Em termos do PictureViewer, isso significa que a mensagem transmitida entre as instâncias de PictureViewer de José e Jaime explicada na barra lateral ainda é manipulada por PeerChannel.

Início da página

Conclusão

O desenvolvimento de aplicativos ponto a ponto é um tópico muito amplo e, para a maioria dos desenvolvedores, bastante recente. Com o lançamento do Windows Vista e do .NET Framework 3.0, as barreiras tradicionais para entrada no desenvolvimento de aplicativos ponto a ponto serão reduzidas consideravelmente. Minha aposta é que os avanços em tecnologia, como PNRP, IPv6 e o advento de plataformas novas e mais produtivas, como PeerCHannel e PNM, darão início a uma nova era de desenvolvimento de aplicativos ponto a ponto. O resultado final será mais aplicativos colaborativos oferecendo funcionalidades que ainda mal começamos a imaginar.

Justin Smith é instrutor e consultor da Wintellect. Atualmente, está escrevendo o livro Applied Windows Communication Foundation Programming para a Microsoft Press, com publicação prevista para janeiro de 2007 e é autor do curso Wintellect's Mastering Distributed Applications. Justin pode ser contatado pelo email justins@wintellect.com.

Início da página