Interception Demonstration Presented by: Ramaswamy Krishnan-Chittur
Content In the current presentation, I would like to demonstrate a very simple interception experiment; the purpose being a walk-through for Setting up a remoting interception library. Developing a very basic interception function. Discussing some other relevant points on interception, extraneous to this experiment though.
1] Experiment description The project aims at setting up a server that sends back to the client, the current time at its end. The project is very simple, and hence I didn’t go for a separate communication class. Let us have a quick look at the code.
2] The client-side interceptor: Goal Now let us set up a client side interceptor. The interceptor is supposed to act as a firewall which will block all out-going calls with the following URL: tcp://localhost:2020/Clock.binary
2] The client-side interceptor: Goal
2] The client-side interceptor: Structure We need to develop two classes to set up the interceptor – The Interceptor sink class, MyChannelSink, which does the interception The sink provider class, MySinkProvider, which adds the sink to the sink chain.
2] The client-side interceptor: Class layout
3] The Interceptor Sink class: Code Let us have a look at the Sink class:
3] The Interceptor Sink class: Code As we see, the client interceptor sink class, MyChannelSink, derives from BaseChannelSinkWithProperties, IMessageSink, IClientChannelSink We do all the necessary processing in just one function, public IMessage SyncProcessMessage(IMessage theMessage) We will just stuff in the other functions with some basic code, just for satisfying the interface definitions.
3] The Interceptor Sink class: Processing function
4] The Sink Provider class: Code We have seen the code for the interceptor sink class. Now we need a sink provider class which would add this custom sink to the sink chain. Let us see the code for the sink provider class that we have developed for this application, MySinkProvider.
4] The Sink Provider class: Code
5] The configuration file Now that we have the client interceptor sink, and the sink provider, we need to create a configuration file, which will be used by the client to include the interceptor in the remoting chain.
5] The configuration file The name of the sink provider class. <configuration> <system.runtime.remoting> <application> <channels> <channel ref = "tcp" port = "0"> <clientProviders> <provider type = "Interceptor.MySinkProvider, Interceptor" /> <formatter ref = "binary" /> </clientProviders> </channel> </channels> </application> </system.runtime.remoting> </configuration> Namespace in which the sink provider class resides. Name of the library that defines the sink provider. Need NOT be same as the namespace name.
5] The configuration file: Naming; A weird little problem Config files can have any name. Jeff Prosise, though, advises to name the config file as the < client Exe name > + “.config” i.e., if the client executive is MyClient.exe, the config file would be MyClient.exe.config It works fine with .NET 1.0 .NET 1.1 simply deletes the config file if we name it like that. I realized it the hard way! Bizarre!
6] Including the Config file in the client
7] 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 Programming Microsoft .NET – Jeff Prosise