Home Contact Sitemap
What is thinktecture? thinktecture is a European software development support company. We help software development and architecture teams with an influx of in-depth technical knowledge and expertise in the areas of application design, scalability, security and maintainability.

Location: Home > Resources > HowManyChannels

Question: How many channels should be registered?

2002
Ingo Rammer

Question

Is it advisable to open a channel per object in an app domain? So if I have a client exe that potentially uses 30 objects that can make remote calls, should I just use one channel for the client side or thirty?

Answer

You can just register a single channel, no matter how many object you are intending to use.

The reason for this is that the registered channel is actually only a "template" (or, to use Remoting-speak, a chain of ChannelSinkProviders) for the real means of communication. As soon as a transparent proxy is created (i.e. by calling Activator.GetObject(), Activator.CreateInstance() or as a MarshalByRefObject return value of a method call), a real sink chain will be created for your proxy.

This sink chain consists of different sinks objects for each and every of your proxies. That is, one sink chain is associated to exactly one proxy.

The end of this sink chain is some transport sink (by default either TcpClientTransportSink or HttpClientTransportSink). This transport sink will take care of sending the data over to a remote process. Fortunately enough, this sink "knows" of any exisiting network connections to the target server and will re-use them if there's a currently unused connection available or will transparently create a new connection to your server.

Therefore it really doesn't matter how many channels you register in your application. I normally recommend to simply register exactly one TcpChannel or HttpChannel during startup of your application. The number of real connections to the server is independent of the number of registered channels.

However, please note that there is a property called clientConnectionLimit on the HttpChannel. This property can be set on the client and is supposed to specify the maximum number of connections which will exist to a given server at any given time. (Note: At the current version of the .NET Framework 1.0, the Remoting framework doesn't honor this limit in all cases). The default value is 2 (more information about Remoting configuration files can be found at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/remotingconfig.asp).

This setting is however only relevant if you are working with multiple threads in your client application because, as described above, the underlying network connection is independent of the target object. It will simply be re-used as needed.

So, to allow a higher number of concurrent connections to a single server (in a multithreaded client scenario, f.e. when using ASP.NET as a client), you could use the following entry in your client side configuration file:

<configuration>
  <system.runtime.remoting>
    <application>
      <channels> 
        <channel ref="http" clientConnectionLimit="200">
          <clientProviders>
            <formatter ref="binary" />
          </clientProviders>
        </channel>
      </channels>
    </application>
  </system.runtime.remoting>
</configuration>

Or, to specify similar behavior via code:

IDictionary props = new Hashtable();
props["name"] = "MyHttpChannel";
props["clientConnectionLimit"] = 0;

BinaryServerFormatterSinkProvider srv = new BinaryServerFormatterSinkProvider();
BinaryClientFormatterSinkProvider clnt = new BinaryClientFormatterSinkProvider();
HttpChannel channel = new HttpChannel(props,clnt,srv);
ChannelServices.RegisterChannel(channel);

Please note again that this property is a client-side property and does not affect the server-side of your application. I.e. it is not a limit of concurrent connections which you can set at your server.

 

 

 
© 2002-2008 by thinktecture, Ingo Rammer and Christian Weyer. All rights reserved. Contact | Impressum