Canali

I canali sono oggetti che trasportano messaggi tra applicazioni oltre i limiti di comunicazione remota, tra domini applicazioni, processi o computer. Un canale può attendere i messaggi in arrivo su un endpoint e/o inviare messaggi in uscita a un altro endpoint. In questo modo è possibile inserire una vasta gamma di protocolli, anche se all'estremità opposta del canale non è presente Common Language Runtime.

È necessario che mediante i canali si implementi l'interfaccia IChannel, tramite la quale vengono fornite proprietà informative come ChannelName e ChannelPriority. I canali progettati per attendere un determinato protocollo su una determinata porta consentono di implementare IChannelReceiver, mentre quelli progettati per inviare informazioni consentono di implementare IChannelSender. Per gli oggetti TcpChannel e HttpChannel sono implementate entrambe le interfacce, che in tal modo potranno essere utilizzate per inviare o ricevere informazioni.

È possibile registrare canali con l'infrastruttura di comunicazione remota in due modi:

  • Se si pubblica un oggetto remotizzabile, chiamare ChannelServices.RegisterChannel prima di registrare l'oggetto server.
  • Se si utilizza una funzionalità dell'oggetto remotizzabile, chiamare ChannelServices.RegisterChannel prima di creare un'istanza dell'oggetto server.

È anche possibile caricare i canali dal file di configurazione remota. Per informazioni dettagliate, vedere Configurazione.

Sul lato client, i messaggi sono passati alla catena di sink di canale client dopo avere attraversato la catena di contesto del client. Il primo sink di canale è in genere un sink del formattatore, il quale serializza il messaggio in un flusso che viene passato lungo la catena di sink di canale al sink di trasporto del client. Il sink di trasporto del client scrive quindi il flusso sulla connessione.

Sul lato server, il sink di trasporto del server legge le richieste dalla connessione e passa il flusso di richiesta alla catena di sink di canale del server. Il sink del formattatore del server all'estremità della catena deserializza la richiesta in un messaggio, il quale viene quindi passato all'infrastruttura di comunicazione remota. Per ulteriori informazioni sui sink di canale, vedere Sink e catene dei sink.

Regole dei canali

Quando un metodo viene chiamato da un client su un oggetto remoto, i parametri e altri dettagli relativi alla chiamata vengono trasportati all'oggetto remoto attraverso il canale. Gli eventuali risultati della chiamata sono restituiti nello stesso modo. Un client può selezionare uno dei canali registrati sul server per comunicare con l'oggetto remoto, consentendo così agli sviluppatori di selezionare i canali più adatti alle proprie esigenze. È anche possibile personalizzare qualsiasi canale esistente o generarne di nuovi che utilizzano un altro protocollo di comunicazione. La selezione del canale è soggetta alle regole riportate di seguito.

  • È necessario registrare almeno un canale con il sistema di comunicazione remota sul server prima di poter chiamare un oggetto remoto. È necessario registrare i canali prima di registrare gli oggetti. Se un canale non viene registrato sul client, ne viene scelto o creato uno dal sistema di comunicazione remota per inviare le chiamate in uscita.

    Nota   Se il client prevede una funzione di callback, è necessario registrare un canale di attesa sul client e configurare il server in modo che utilizzi un canale compatibile.

  • I canali sono registrati per dominio applicazione. Un singolo processo può contenere più domini applicazione. Quando un processo termina, tutti i canali da esso registrati sono automaticamente distrutti.

  • I nomi dei canali devono essere univoci all'interno di un dominio applicazione. Poiché ad esempio i canali predefiniti sono contraddistinti da un nome, per registrare due oggetti HttpChannel in un dominio applicazione, è necessario modificare i nomi dei canali prima di registrarli. Nell'esempio di codice C# che segue viene illustrata questa possibilità.

    IDictionary prop = new Hashtable();
    prop["name"] = "http1";
    prop["port"] = "9001";
    ChannelServices.RegisterChannel(new HttpChannel(prop, null, null));
    
  • Non è possibile registrare più di una volta un canale che attende su una porta specifica. Anche se i canali vengono registrati per dominio applicazione, non è possibile che nei diversi domini applicazione sullo stesso computer si registrino lo stesso canale in attesa sulla stessa porta.

  • Se non si è sicuri della disponibilità di una porta, utilizzare 0 (zero) nella configurazione della porta del canale affinché la scelta di una porta disponibile venga operata dal sistema remoto.

  • I client possono comunicare con un oggetto remoto mediante un canale registrato. Mediante il sistema di comunicazione remota viene assicurata la connessione dell'oggetto remoto al canale corretto quando un client tenta di connettersi all'oggetto. Il client è responsabile della chiamata a ChannelServices.RegisterChannel prima del tentativo di comunicazione con un oggetto remoto. Se è prevista una funzione di callback, il client deve registrare un canale e una porta.

Quando un client chiama un metodo su un proxy, la chiamata viene intercettata, inserita in un messaggio e passata a un'istanza della classe RealProxy. Con la classe RealProxy il messaggio viene inoltrato 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 attraverso il canale al dominio applicazione di origine, dove viene eseguito l'unmarshalling del messaggio e la chiamata è effettuata sull'oggetto remoto stesso.

Quando con la comunicazione remota si inizializza un proxy su un oggetto remoto nel dominio del client, un sink dei messaggi in grado di comunicare con l'oggetto remoto viene recuperato dal canale configurato dal client mediante la chiamata a IChannelSender.CreateMessageSink sul canale selezionato.

Un aspetto confuso del sistema di comunicazione remota è la relazione esistente tra oggetti remoti e canali. È interessante, ad esempio, sapere come un oggetto remoto WellKnownObjectMode.SingleCall attenda i client in connessione, se viene attivato solo quando arriva una chiamata.

Questa operazione è possibile in parte perché i canali sono condivisi dagli oggetti remoti; un oggetto remoto non possiede un canale. È necessario che le applicazioni server contenenti oggetti remoti registrino i canali richiesti, nonché gli oggetti da esporre con il sistema di comunicazione remota. Quando viene registrato, un canale inizia automaticamente ad attendere le richieste dei client sulla porta specificata. In caso di chiamate sincrone, viene mantenuta la connessione dal client per la durata della chiamata del messaggio. Poiché ogni connessione client viene gestita nel proprio thread, un solo canale è in grado di servire più client contemporaneamente.

Vedere anche

Cenni preliminari su .NET Remoting | HttpChannel | TcpChannel | Scelta di un canale | Formattatori di serializzazione | Sink e catene di sink