Uri definitions for the different transports in .NET

Remoting SDK
1

Hello,

I’m looking into adding a different client channel transport for my app, and I would like to keep the door open to different protocols without having to do much changes to the code.

I was thinking into adding, for instance, a NamedPipes and TCP channels, and decide which one to use in Runtime based on an URL on the config, but then I saw that there is a function from ClientChannel that already does that (or so it seems), based on a TargetUri: ChannelMatchingTargetUri. So, as far as I can see, I don’t need to do anything except calling that function to create a ClientChannel for the specified transport, exactly what I was looking.

But I don’t know what are the possible values for the TargetUri. The only examples I’ve seen in the documentation are for supertcp. I tried looking into the source but so far I haven’t had luck finding where they are defined, and I’m no familiar at all with the source code, to begin with…

So, any idea, guide, or similar, for the different channels and their expected Uri values?

Thanks

2

Hello

The default supported values are

  • http
  • https
  • tcp
  • superhttp
  • superhttps
  • supertcp

You can add your own values to this list by defining custom client channels. F.e.

[Protocol("namedpipe")]
[ClientChannel]
public class CustomNamedPipeChannel : NamedPipeClientChannel
{
...		
}

Notice the Protocol and ClientChannel attributes. Classes marked by both these attributes are recognized by the schema Uri infrastructure.

Regards

3

Thanks for the list Anton,

Any specific reason why NamedPipes is not included by default? As my RO-Server and the Web-Server will be most of the time in the same machine I was looking into using NamedPipes as the default transport. Right now I have it working fine with TCP, but I wonder if there is a reason for you to not include the default NamedPipes transport into that list?

Thanks for your help

4

Hello

The main reason is that the NamedPipes doesn’t fit well with the naming scheme

[protocol]://[server hostname]:[port]/[message]
5

Ok. Thanks for the info.