Hi, Chris.
The solution itself is far easier than it sounds. :)
I just did a simply test on it. The code is only about 30 lines. I
listed my code here.
Hope it helpful.
//The Generic FilterProvider code:
using System;
using System.Collections;
using System.Runtime.Remoting.Channels;
namespace MChen.LearnCSharp.Remote {
public class UrlFormatFilterProvider :
IClientChannelSinkProvider {
private IClientChannelSinkProvider _next = null;
private string _suffix;
//get the suffix property from configuration
public UrlFormatFilterProvider(IDictionary properties,
ICollection providerData) {
_suffix = (string)properties["suffix"];
}
//standard implementation of Next
public IClientChannelSinkProvider Next {
get {
return _next;
}
set {
_next = value;
}
}
//We don't need to create special sink here, instead,
only filter out url without proper suffix
public IClientChannelSink CreateSink(IChannelSender
channel, string url, object remoteChannelData) {
if (url.EndsWith(_suffix) && _next != null) {
return _next.CreateSink(channel, url,
remoteChannelData);
}
return null;
}
}
}
And here is a sample config file:
<configuration>
<system.runtime.remoting>
<application>
<channels>
<channel ref="http" name="httpbin">
<clientProviders>
<provider ref="urlformat" suffix=".rem" />
<formatter ref="binary"/>
</clientProviders>
</channel>
<channel ref="http" name="httpsoap">
<clientProviders>
<provider ref="urlformat" suffix=".soap" />
<formatter ref="soap"/>
</clientProviders>
</channel>
</channels>
</application>
<channelSinkProviders>
<clientProviders>
<provider id="urlformat"
type="MChen.LearnCSharp.Remote.UrlFormatFilterProvider,
provider"
/>
</clientProviders>
</channelSinkProviders>
</system.runtime.remoting>
</configuration>
I basicly created two http channel, one for binary format while the
other for soap format.
Without using UrlFormatFilter, one of them would never be used and some
invoke of remote object will go wrong.
After using these two filter, all url ends with ".rem" will go to binary
http channel, while url ends with ".soap" will use soap http channel.
Best Regards
Ming Chen
-----Original Message-----
From: Chris Keyser [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, May 29, 2002 9:33 PM
To: [EMAIL PROTECTED]
Subject: Re: [ADVANCED-DOTNET] remoting with http/soap and http/binary
channels within the same client app instance
Thanks for the responses Mike and Ming. Mike - your solution works on
the
server side great - I was able to get the two different channels serving
the same object instances to two different clients - pretty cool. But I
still can't see how to easily get it to work on the client side, since
on
channels for the client side shouldn't be assigned a port - hence up to
the runtime to decide which channel to use when connecting. I was
hoping
for an easier solution, but maybe Ming's suggestion isn't as difficult
as
it sounds - I'll take a look at that approach. I don't understand the
usefulness, at least on the client side, of having multiple channels of
the same type if remoting doesn't have the intelligence to select. I'm
surprised there is no "out of the box" solution to this one. It doesn't
seem like that unlikely of a scenario.
You can read messages from the Advanced DOTNET archive, unsubscribe from
Advanced DOTNET, or
subscribe to other DevelopMentor lists at http://discuss.develop.com.
You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced
DOTNET, or
subscribe to other DevelopMentor lists at http://discuss.develop.com.
