1. Interception Demonstration Presented by: Ramaswamy Krishnan-Chittur

2. 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.

3. 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.

4. 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

5. 2] The client-side interceptor: Goal

6. 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.

7. 2] The client-side interceptor: Class layout

8. 3] The Interceptor Sink class: Code • Let us have a look at the Sink class:

9. 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.

10. 3] The Interceptor Sink class: Processing function

11. 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.

12. 4] The Sink Provider class: Code

13. 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.

14. 5] The configuration file The name of the sink provider class. <configuration> <system.runtime.remoting> <application> <channels> <channelref="tcp"port="0"> <clientProviders> <providertype="Interceptor.MySinkProvider, Interceptor"/> <formatterref="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.

15. 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!

16. 6] Including the Config file in the client Including the Config file in the client

17. 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