.Net Remoting continued

  • Article

After several frustrating hours troubleshooting issues with objects flowing in both directions (i.e., From Client to Sever and vice versa), I have some more information that may help you. This information is a continuation of the previous post on the subject found here.

 

In my previous posting I was primarily discussing activation of Client objects from a Server. I have also found something interesting about the communication between a Client and a Server over a remoting Channel, where a client object is accessed from a Server (i.e., not activated by the Server but proffered up from the Client to the Server over the remoting channel).

 

Is this confusing enough? Let’s use some pseudo-code to demonstrate the scenarios.

In the previous posting we spoke to the following scenerio.

 

  1. A Host process (let’s call this the “Client”) creates a remoting channel (IPC, TCP)

BinaryServerFormatterSinkProvider serverProvider = new BinaryServerFormatterSinkProvider();

BinaryClientFormatterSinkProvider clientProvider = new BinaryClientFormatterSinkProvider();

System.Collections.IDictionary props = new System.Collections.Hashtable();

props["portName"] = “SomeName”;

ichannel = new IpcChannel(props, clientProvider, serverProvider);

…

  1. The Host/Client starts another process (let’s call this the Server)
    1. The Server application creates a remoting channel

…

ichannel = new IpcChannel(props, clientProvider, serverProvider);

…

    1. The Server publishes a local MarshalByRefObject object (MBRO). Let’s call this ServerObject

RemotingServices.Marshal(ServerObject, @"UniqueIdentifier");

Or RegisterWellknownServiceType

  1. The Client activates the ServerObject and makes calls on the methods

ServerObject serverObj = (ServerObject)Activator.GetObject(Type.GetType(AssemblyQualifiedNameOfObject), @"ipc://" + @"UniqueIdentifier"+ @"/ServerObject"));

serverObj.CallAMethod();

 

  1. If the Sever wishes to activate a MBRO in the Client process we need the following;

    1. The Client needs to create a server provider remoting channel
    2. The Client needs to publishes a local MBRO. Let’s call this ClientObject.

  2. The Server activates the ClientObject and now makes calls on the methods

     

In order to enable this two-way activation we need to set the typeFilterLevel to Full.

props["typeFilterLevel"] = "Full";

ichannel = new IpcChannel(props, clientProvider, serverProvider);

 

In the previous scenerio the Server can create MBRO’s and the Client can access the object methods over the channel. In a new scenerio, where the Client creates a MBRO object and attempts to pass the object to a Server Object, you will receive the following error message – “Because of security restrictions, the type System.Runtime.Remoting.ObjRef cannot be accessed.”

 

Note that this new scenerio the Server is not “activating” the Client object, but rather passing it to a Server object. Surprisingly, even though you have a channel established and you can call in one direction (Client calling on the Server), with an object that is MBRO, it fails. Doh!

 

We determined that we needed the typeFilterLevel property to be set to “Full” for the Server activating a Client object in the first scenerio. In this second scenerio, we also need to set the following;

serverProvider.TypeFilterLevel = System.Runtime.Serialization.Formatters.TypeFilterLevel.Full;

 

Go figure <shrug>

 

It is apparent that there is a difference between the

["typeFilterLevel"] = "Full" property

and

the Serverprovider setting

BinaryServerFormatterSinkProvider serverProvider = new BinaryServerFormatterSinkProvider();

serverProvider.TypeFilterLevel = TypeFilterLevel.Full;

 

I am not sure why these seemingly similar settings behave differently, but they do. This may be a bug or intended behavior. If I receive an answer on why they differ, I will post my findings. In any event, I thought this might save someone else the frustration I experienced and also clear up my last posting where I insinuated that these settings are interchangeable. And besides, you now you have another two-way remoting scenerio to add to your bag of tricks.