Canali

Articolo
09/01/2008

I canali sono oggetti che trasportano messaggi tra le applicazioni attraverso limiti remoti, quali domini di applicazioni, processi o computer. Un canale può attendere messaggi in ingresso su un endpoint, inviare messaggi in uscita a un altro endpoint o effettuare entrambe le operazioni. In questo modo è possibile collegarsi a un'ampia gamma di protocolli, anche se Common Language Runtime non è presente all'altra estremità del canale.

I canali devono implementare l'interfaccia IChannel che fornisce proprietà informative quali ChannelName e ChannelPriority . I canali progettati per attendere uno specifico protocollo su una specifica porta implementano IChannelReceiver, mentre i canali progettati per inviare informazioni implementano IChannelSender. Entrambi gli oggetti TcpChannel e HttpChannel implementano entrambe queste interfacce, pertanto potranno essere utilizzati per inviare o ricevere informazioni.

È possibile registrare canali con l'infrastruttura .NET Remoting nei seguenti modi:

Se si sta pubblicando un oggetto utilizzabile in remoto, chiamare ChannelServices.RegisterChannel prima di registrare l'oggetto server.
Se si sta utilizzando una funzionalità di un oggetto utilizzabile in remoto, chiamare RegisterChannel prima di creare un'istanza dell'oggetto server.

È inoltre possibile caricare canali dal file di configurazione .NET Remoting. Per ulteriori informazioni, vedere Configurazione.

Sul lato client i messaggi vengono passati alla catena di sink di canale del client dopo essere passati attraverso la catena di contesto del client. Il primo sink di canale è in genere un sink del formattatore, che serializza il messaggio in un flusso che viene quindi passato lungo la catena di sink di canale al sink di trasporto del client. Il sink di trasporto del client inserisce quindi il flusso nel collegamento.

Sul lato server il sink di trasporto del server legge le richieste dal collegamento e passa il flusso di richiesta alla catena di sink di canale del server. Il sink del formattatore del server alla fine della catena deserializza la richiesta in un messaggio. Poi passa questo messaggio all'infrastruttura .NET Remoting. Per ulteriori informazioni sui sink di canale, vedere Sink e catene di sink.

Regole dei canali

Quando un client chiama un metodo su un oggetto remoto, i parametri e gli altri dettagli riferiti alla chiamata vengono trasferiti tramite il canale all'oggetto remoto. Qualsiasi risultato risultante dalla chiamata viene restituito nello stesso modo. Un client può selezionare alcuni dei canali registrati sul server per comunicare con l'oggetto remoto, dando in questo modo agli sviluppatori la libertà di scegliere i canali che soddisfano meglio le loro necessità. È anche possibile personalizzare qualsiasi canale esistente o generarne di nuovi che utilizzano un protocollo di comunicazione diverso. La scelta del canale è soggetta alle regole seguenti:

Almeno un canale deve essere registrato con il sistema remoto nel server prima che un oggetto remoto possa essere chiamato. I canali devono essere registrati prima che gli oggetti vengano registrati. Se un canale non è registrato sul client, il sistema .NET Remoting ne sceglie o ne crea uno per inviare chiamate a destinazioni esterne.

Nota:

Se il client si aspetta una funzione di callback, sul client dev'essere registrato un canale di attesa e il server deve essere configurato per l'utilizzo di un canale compatibile.
I canali vengono registrati per ogni dominio applicazione. In un solo processo possono esistere più domini applicazione. Quando un processo termina, tutti i canali da esso registrati vengono distrutti automaticamente.
I nomi di canale devono essere univoci all'interno di un dominio applicazione. Ad esempio, dal momento che i canali predefiniti hanno dei nomi, per registrare due oggetti HttpChannel in un dominio applicazione, è necessario modificare i nomi dei canali prima della registrazione. Nell'esempio di codice C# seguente viene illustrata questa evenienza.
```
IDictionary prop = new Hashtable();
prop["name"] = "http1";
prop["port"] = "9001";
ChannelServices.RegisterChannel(new HttpChannel(prop, null, null));
```
Non è possibile registrare un canale in attesa su una porta specifica più di una volta. Anche se i canali vengono registrati per ogni dominio applicazione, diversi domini applicazione sullo stesso computer non possono registrare lo stesso canale in attesa sulla stessa porta.
Se non si sa con certezza se una porta è disponibile, utilizzare 0 (zero) durante la configurazione della porta del canale e il sistema .NET Remoting sceglierà una porta disponibile.
I client possono comunicare con un oggetto remoto utilizzando un qualsiasi canale registrato. Il sistema remoto garantisce che l'oggetto remoto sia connesso al canale corretto quando un client tenta di connettersi all'oggetto. Il client si deve occupare di chiamare ChannelServices.RegisterChannel prima di tentare di comunicare con un oggetto remoto. Se si aspetta una funzione di callback, il client deve registrare un canale e una porta.

Nota:
Se il client si aspetta una funzione di callback, sul client dev'essere registrato un canale di attesa e il server deve essere configurato per l'utilizzo di un canale compatibile.

Quando un client chiama un metodo su un proxy, la chiamata viene intercettata, impacchettata in un messaggio e passata a un'istanza della classe RealProxy. La classe RealProxy inoltra il messaggio al sink dei messaggi per l'elaborazione. Un sink dei messaggi stabilisce una connessione con il canale registrato dall'oggetto remoto e invia il messaggio sul canale nel dominio dell'applicazione di origine. Lì viene effettuato l'unmarshalling del messaggio e viene effettuata la chiamata all'oggetto remoto stesso.

Quando .NET Remoting inizializza un proxy a un oggetto remoto nel dominio del client, dal canale configurato dal client viene recuperato un sink dei messaggi capace di comunicare con l'oggetto remoto chiamando IChannelSender.CreateMessageSink sul canale selezionato.

Uno aspetto del sistema .NET Remoting che potrebbe generare confusione è la relazione tra oggetti remoti e canali. Ad esempio, come fa un oggetto remoto WellKnownObjectMode.SingleCall ad attendere le connessioni dei client se l'oggetto viene attivato solo quando arriva una chiamata.

Questo è possibile in parte perché gli oggetti remoti condividono canali: un oggetto remoto non possiede un canale. Applicazioni server che ospitano oggetti remoti devono registrare i canali di cui necessitano così come gli oggetti che espongono con il sistema .NET Remoting. Quando un canale viene registrato, comincia automaticamente ad attendere le richieste di client alla porta specificata. Nel caso di chiamate sincrone, la connessione dal client rimane attiva per tutta la durata della chiamata del messaggio. Siccome ogni connessione client viene gestita in un thread separato, un solo canale può servire simultaneamente più client.

Vedere anche

Footer image

Canali

Regole dei canali

Vedere anche

Riferimenti

Concetti

Altre risorse

Risorse aggiuntive