.NET Channels

1. .NET Channels Presented by: Ramaswamy Krishnan-Chittur

2. Contents • Channel Architecture • Messages: Units of data transfer • Channel Sinks • Custom Sinks • Sink Providers • Sample code • Applications • Reference

3. 1] Channel Architecture

4. 2] Messages: Units of data transfer • When we construct a proxy and make a method call, we generate a Message object, which travels through a series of sinks as it makes round-trips to the server. • The Message class, which is referenced through the IMessage interface within the sinks, contains a dictionary that holds the data representing the call. • The Remoting framework exposes a number of IMessage implementing classes, which represent different messages passed along either during construction (Construction Call, Construction Response) or during a method call (Method Call, Method Response).

5. 3] Channel Sinks • There are two important sinks through which the remoted message passes: • Formatter Sink • Transport Sink • The Formatter Sink does the job of serializing the message into a stream and creating transport headers. • The Transport Sink converts the transport headers into protocol-specific headers and transfers the stream over the wire using the chosen protocol.

6. 3] Channel Sinks: Default Formatter Sinks • Remoting channels are associated with a default chain of sinks. • By default: • The HttpChannel is associated with SoapFormatterSink. • The TcpChannel with is associated with the BinaryFormatterSink.

7. 4] Custom Sinks

8. 4] Custom Sinks • We can put custom sinks both before and after the Formatter Sink. • We can develop Custom Channel Message Sinks, where we can manipulate messages in their raw form. • We can develop Custom Formatter Sinks, where we provide our custom formatting to the messages. • We can also develop Custom Channel Sinks, where we manipulate the serialized messages.

9. 4] Custom Sinks: Custom Message Sinks • We can develop Custom Channel Message Sinks, where we can manipulate messages in their raw form. • Such sinks have to implement the IMessageSink interface, and may derive from IClientChannelSink / IServerChannelSink interface.

10. 4] Custom Sinks: Custom Formatter Sinks • We can develop Custom Formatter Sinks, where we provide our custom formatting to the messages. • The custom formatter sinks have to implement IClientFormatterSink or the IServerFormatterSink interface. • The formatter sink on the client side receives the message on IMessageSink, serializes it, and forwards it on to client channel sinks. • On the server side, it reverses this process, deserializing the message and forwarding it to the stack builder sink.

11. 4] Custom Sinks: Custom Channel Sinks • In the Custom Channel Sinks, where we manipulate the serialized messages. • Custom Channel Sinks implement both IMessageSink and IClientChannelSink / IServerChannelSink by implementing IClientFormatterSink on the client side and IServerFormatterSink on the server side.

12. 5] Sink Providers • Using a configuration file, we can override the sink chain by providing a reference to custom sink providers. • A sink provider implements IClientChannelSinkProvider for creating client-side channel sinks and implements IServerChannelSinkProvider for creating server-side channel sinks. • The provider chain is initialized when the config file is read and the channel initialized. • The order in which the providers are placed in the chain depends on the order in which they are defined in the config file. • The CreateSink method of the provider is called when the proxy is created. It should forward the call to the next provider in the provider chain, and then chain the next sink (obtained after its own channel sink). This order sets up the sink chain through which the message passes.

13. 6] Sample code: Custom Formatter Sink namespace ClientInterceptor { public class MyClientFormatterSink : IClientFormatterSink { // satisfy interface definitions. public IMessageSyncProcessMessage ( IMessage msg ) { // Do custom serialization and processing here. } } }

14. 6] Sample code: Sink Provider namespace ClientInterceptor { public class MyFormatterClientSinkProvider : IClientFormatterSinkProvider { // build the client-side channel sink chain: public IClientChannelSink CreateSink ( IChannelSender channel, string url , object remoteChannelData ) { // our provider --> _Next provider // ask the next provider for the sink chain IClientChannelSink chain = _Next.CreateSink(channel,url,remoteChannelData); // add our formatter to the beginning of the chain IClientChannelSink sinkFormatter =new MyClientFormatterSink(chain); return sinkFormatter; } // satisfy other interface definitions. } }

15. 6] Sample code: Configuration file <configuration> <system.runtime.remoting> <application> <channels> <channelref="http"> <clientProviders> <formattertype="ClientInterceptor.MyFormatterClientSinkProvider, ClientInterceptor"/> </clientProviders> </channel> </channels> </application> </system.runtime.remoting> </configuration>

16. 6] Sample code: Client namespace Client { public class Executive { static void Main( ) { RemotingConfiguration.Configure ("TheClient.exe.config"); // Activate remote object, and other stuff. } } }

17. 7] Application: Encrypting the messages • As discussed, the custom channel sinks get the serialized stream. • These sinks can’t write to the actual stream. But they may choose to replace the original stream with a new one. • The client sinks can therefore be used to read the original stream, and to create an encrypted stream in place of the original one. This would be decrypted at the server side.

18. 7] Application: Message Prioritization • The streams carry transport headers, which can carry information orthogonal to the content of the message. • The channel sinks can use the transport headers to transfer extraneous data. • For instance, the client channel sink can find the priority of the current thread, and encode the info as a transport header. This information can be used by the server-side channel sink to direct the message to a queue of appropriate priority.

19. 7] Application: Message Prioritization namespace ClientInterceptor { public class MyClientFormatterSink : IClientFormatterSink { public void ProcessMessage (IMessage msg, ITransportHeaders requestHeaders, Stream requestStream, out ITransportHeaders responseHeaders, out Stream responseStream ) { requestHeaders["Thread_Priority"] = Thread.CurrentThread.Priority.ToString( ); // other stuff. } // other functions } }

20. 7] Application: Firewalling • All messages carry a destination URL. The client side sink can trace the URL of the message being sent, and may choose to block certain prohibited URLs. namespace Interceptor { class MyChannelSink : BaseChannelSinkWithProperties, IMessageSink, IClientChannelSink { // intercepting function public IMessage SyncProcessMessage(IMessage theMessage) { IMethodCallMessage call = (IMethodCallMessage)theMessage; if (call == null) return (nextMessageSink.SyncProcessMessage(theMessage)); // blocked URL? if (call.Uri == “http://localhost:2020/Clock.binary") return (nextMessageSink.SyncProcessMessage(null)); else return (nextMessageSink.SyncProcessMessage(theMessage)); } // other functions. } }

21. 8] Reference • Remoting with C# and .NET- David Conger • http://www.msdn.microsoft.com/msdnmag/issues/03/11/RemotingChannelSinks/print.asp • MSDN documentation • Advanced .NET Remoting- Ingo Rammer • Microsoft .NET Remoting - Scott McLean, James Naftel, Kim Williams • Essential .NET, volume 1 - Don Box, Chris Sells