Chat sicura su un canale del peer

In questo esempio viene illustrato l'utilizzo dell'associazione NetPeerTcpBindingcon autenticazione basata su password, che fornisce la comunicazione a più parti tramite il canale peer. Questo esempio è una variante di Esempio della guida introduttiva. Per una panoramica di Windows Communication Foundation (WCF), vedere Esempio della guida introduttiva.

In questo esempio le istanze dell'applicazione sono applicazioni console indipendenti.

A differenza di altri esempi di associazioni di trasporto, in questo esempio viene utilizzata l'interfaccia di contratto IChat per illustrare le comunicazioni a più parti. Tutte le istanze implementano questo contratto per ricevere messaggi e creare proxy con lo stesso contratto per l'invio dei messaggi alla mesh. Questo processo viene illustrato creando un DuplexChannel nella mesh.

Nota

La procedura di installazione e le istruzioni di compilazione per questo esempio si trovano alla fine di questo argomento.

La comprensione del processo di configurazione dell'associazione descritto nell'esempio implica la conoscenza dei concetti relativi canale peer seguenti:

  • Il resolver del peer è responsabile della risoluzione di un ID di mesh negli indirizzi degli endpoint di alcuni nodi della mesh.
  • Una mesh è un insieme denominato di nodi del peer identificati dall'ID della mesh.
  • Un nodo del peer è un'istanza di un'applicazione che fa parte della mesh.
  • Gli ID di mesh identificano la parte dell'host dell'indirizzo di un endpoint nella mesh. Sono esempi di questi indirizzi "net.p2p://chatMesh/servicemodelsamples/chat" e "net.p2p://broadcastMesh/servicemodelsamples/announcements". chatMesh e broadcastMesh sono ID di mesh.
  • Tutti i client che fanno parte di una mesh utilizzano lo stesso ID di mesh, ma potrebbero utilizzare anche percorsi e servizi diversi. Un messaggio indirizzato a un indirizzo di un endpoint specifico viene recapitato a tutti i canali del peer con tale indirizzo.

Quando viene aperto un nodo del peer, come conseguenza dell'apertura del canale del peer, il nodo utilizza un resolver del peer per risolvere un ID di mesh negli indirizzi di altri nodi del peer a cui deve essere effettuata la connessione. In questo modo viene creata una mesh di nodi interconnessi e viene consentita la propagazione dei messaggi in tutta la mesh.

PeerTransportCredentialType specifica come vengono autenticati reciprocamente i peer della mesh. Questa proprietà può essere specificata nella configurazione dell'associazione, nell'oggetto NetPeerTcpBinding o utilizzando PeerTransportBindingElement. Un'istanza di ClientCredentialSettings o ServiceCredentialSettings con credenziali appropriate specificate nella proprietà Peer deve essere aggiunta all'insieme dei comportamenti nella channel factory o in ServiceHost, a seconda dell'utilizzo.

  1. In questo esempio viene utilizzata la modalità di autenticazione con password per la protezione del canale peer, che rappresenta la modalità predefinita. Questa operazione viene eseguita stabilendo una connessione sicura tra elementi adiacenti e scambiando una trasformazione di questa password. Se è specificato Password, la proprietà ClientCredentialSettings.Peer deve disporre di una password valida e facoltativamente di un'istanza di X509Certificate2 con SetSelfCertificate.

L'associazione è specificata nel file di configurazione dell'applicazione. Il tipo di associazione è specificato nell'attributo Binding dell'elemento endpoint, come illustrato nell'esempio riportato di seguito.

<client>
   <!-- chat instance participating in the mesh -->
   <endpoint name="SecureChatEndpoint"
            address="net.p2p://SecureChatMesh/servicemodelsamples/chat"
             binding="netPeerTcpBinding"
             bindingConfiguration="SecureChatBinding"
             contract="Microsoft.ServiceModel.Samples.IChat">
   </endpoint>
 </client>

Se si utilizza l'associazione NetPeerTcpBinding con il comportamento predefinito, viene abilitata la sicurezza basata sulla password. L'elemento dell'associazione fornisce attributi per impostare la porta, l'indirizzo IP di ascolto, il tipo di resolver, la dimensione massima dei messaggi, la dimensione massima del pool di buffer, le quote dei lettori, la modalità di autenticazione dei nodi dei peer, l'autenticazione dei messaggi e i timeout di chiusura, apertura, invio e ricezione.

Nota: in questo esempio viene utilizzato il resolver del peer predefinito (PNRP), che non è disponibile in Windows Server 2003. Per eseguire questo esempio in Windows Server 2003, è necessario pertanto utilizzare un resolver del peer personalizzato. Per un esempio in cui viene utilizzato un resolver del peer personalizzato, vedere Chat del canale peer, ad esempio:

<netPeerTcpBinding>
   <binding configurationName="Binding1"> 
    <resolver mode="Custom">
       <customResolver 
            type="MyAppNameSpace.MyCustomPeerResolver, myApp"/>
    </resolver>
   </binding>
</netPeerTcpBinding>

Il file contenente MyCustomPeerResolver deve essere compilato con l'applicazione. Si noti che se l'esempio viene eseguito in più computer con piattaforme diverse, è necessario che venga utilizzato lo stesso resolver.

In questa implementazione di chat viene illustrato inoltre come recuperare il nodo del peer associato all'istanza del destinatario o del mittente e come eseguire la registrazione per i relativi eventi in linea e non in linea. Un evento in linea viene generato quando il nodo del peer è connesso ad almeno un altro nodo del peer nella mesh. Un evento non in linea viene generato invece quando il nodo del peer non è più connesso ad altri nodi del peer nella mesh.

A questo punto, il canale del peer non è più integrato con Service Model Metadata Utility Tool (Svcutil.exe). Per questo motivo non è possibile utilizzare Svcutil.exe per generare un canale tipizzato per il mittente.

Quando si esegue l'esempio, nel client viene chiesto di specificare un nome alternativo e una password e quindi viene visualizzato un messaggio in cui viene indicato che il client è pronto per inviare messaggi. I messaggi di chat verranno visualizzati nelle altre finestre della console client. Per terminare il client, premere Q seguito da INVIO nelle finestre della console di un client.

Se si abilita l'analisi o la registrazione dei messaggi, è possibile controllare l'attività del mittente e del destinatario a un livello più profondo. Nella sezione relativa alle procedure viene illustrato come abilitare l'analisi e la registrazione dei messaggi.

Nota

È importante notare che attualmente nell'esempio non vengono gestite tutte le eccezioni che possono essere generate dall'infrastruttura. Se si utilizzano questi esempi in un ambiente commerciale o di produzione, seguire le procedure consigliate per una corretta gestione delle eccezioni.

Per impostare, compilare ed eseguire l'esempio

  1. Assicurarsi di aver eseguito Procedura di installazione singola per gli esempi di Windows Communication Foundation.

  2. Per generare l'edizione Visual C# .NET o Visual Basic .NET della soluzione, seguire le istruzioni in Generazione degli esempi Windows Communication Foundation.

  3. Per eseguire l'esempio in un solo computer, seguire le istruzioni in Esecuzione degli esempi di Windows Communication Foundation.

  4. Per installare PNRP in Windows XP SP2 (installazione singola):

    1. Nel Pannello di controllo fare doppio clic su Installazione applicazioni.
    2. Nella finestra di dialogo Installazione applicazioni scegliere Installazione componenti di Windows.
    3. Nell'Aggiunta guidata componenti di Windows selezionare la casella di controllo "Servizi di rete" e fare clic su "Dettagli".
    4. Selezionare la casella di controllo "Peer-to-peer" e fare clic su "OK."
    5. Nell'Aggiunta guidata componenti di Windows fare clic su "Avanti".
    6. Al termine dell'installazione, fare clic su "Fine".
    7. Dal prompt della shell dei comandi avviare il servizio PNRP con il comando seguente: net start pnrpsvc.
  5. Avviare più istanze dell'esempio, ogni volta specificando un nome alternativo e una password. Il nome alternativo deve essere diverso per ogni client, mentre la password deve rimanere la stessa per tutte le istanze. I messaggi di chat inviati da un'istanza dell'applicazione vengono ricevuti da tutte le altre, purché i nomi alternativi siano diversi e la password corrisponda. Sono consentiti più client con lo stesso nome alternativo, ma i messaggi inviati da client con lo stesso nome alternativo non vengono visualizzati.

Send comments about this topic to Microsoft.
© 2007 Microsoft Corporation. All rights reserved.