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

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

17. 7] Reference Remoting with C# and .NET - David Conger
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