180 likes | 369 Views
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.
E N D
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: 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.
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.
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.
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> <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.
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 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