.Net Remoting uses only one connection ?

Question

Does .Net Remoting opens multiple connections or just one ? let say I have a server and a client. if the client creates multiple SingleCall objects. then for every object is there going to be a new connection or there going to be a single connection for every object ?

I can't find the answer anywhere.

Answer 1

Long answer is: it depends on many things. Short answer is yes. Yes Yes.

Let's make an experiment and see the most common default situation. We have 2 console apps and 1 common class library which is referred by both console apps. The 1st console app has the role of the client and the 2nd one has that of the server.

First, here's what the commonly depended upon class library contains:

public interface IFactory {

    string Hello(string name);

}

Now for some server code. Here's the start up:

private static TcpChannel channel;

static void Main(string[] args) {

  BinaryClientFormatterSinkProvider clientProv = new BinaryClientFormatterSinkProvider();
  BinaryServerFormatterSinkProvider serverProv = new BinaryServerFormatterSinkProvider();
  serverProv.TypeFilterLevel = TypeFilterLevel.Full;

  channel = new TcpChannel(
    properties: new Hashtable {
      { @"port", 2013 }
    },
    clientSinkProvider: clientProv,
    serverSinkProvider: serverProv
  );
  ChannelServices.RegisterChannel(channel, false);
  RemotingConfiguration.RegisterWellKnownServiceType(typeof(Factory), "Factory.rem", WellKnownObjectMode.SingleCall);

  Console.WriteLine("Server started...");
  Console.WriteLine("Press any key to stop...");
  Console.ReadKey(intercept: true);

}

We just mentioned a class called Factory.

RemotingConfiguration.RegisterWellKnownServiceType(typeof(Factory), "Factory.rem", WellKnownObjectMode.SingleCall);

You guessed it. It's the IFactory implementation:

private sealed class Factory : MarshalByRefObject, IFactory {

  #region IFactory Members

  string IFactory.Hello(string name) {
    return @"Hello " + name + @" !";
  }

  #endregion

}

Now for some client:

static void Main(string[] args) {

  Console.WriteLine("Press any key to connect...");
  Console.ReadKey(intercept: true);

  IFactory factory = Activator.GetObject(typeof(IFactory), @"tcp://127.0.0.1:2013/Factory.rem") as IFactory;

  EventWaitHandle signal = new EventWaitHandle(initialState: false, mode: EventResetMode.ManualReset);

  ThreadStart action = () => {

    signal.WaitOne();
    var result = factory.Hello("Eduard");
    Console.WriteLine(result);

  };

  foreach (var i in Enumerable.Range(0, 99))
    new Thread(action) { IsBackground = true }.Start();

  Console.WriteLine("Press any key to bombard server...");
  Console.ReadKey(intercept: true);

  signal.Set();


  Console.ReadKey(intercept: true);
}

You already know all of these things, I'm sure. We obtain a transparent proxy to the SingleCall service on the other side (they're both on the same machine and we're using TCP port 2013):

IFactory factory = Activator.GetObject(typeof(IFactory), @"tcp://127.0.0.1:2013/Factory.rem") as IFactory;

Then, for "simulataneous-ness" reasons we create 100 threads, start them (which can take some time), but "hold them in a leash" (a signal is an essential means of synchronization of the OS) until we "pull the trigger":

EventWaitHandle signal = new EventWaitHandle(initialState: false, mode: EventResetMode.ManualReset);

ThreadStart action = () => {

  signal.WaitOne();
  var result = factory.Hello("Eduard");
  Console.WriteLine(result);

};

foreach (var i in Enumerable.Range(0, 99))
  new Thread(action) { IsBackground = true }.Start();

So although all 100 threads have been created AND started, they are all waiting in the following invocation:

signal.WaitOne();

That way we can get the to start at the same time better, otherwise the creation and starting of threads itself would have made their actual execution more or less sequential.

We ask the user to decide when to "bombard the server" with 100 Hello invocations:

Console.WriteLine("Press any key to bombard server...");
Console.ReadKey(intercept: true);

signal.Set();

And this is what happens:

1) We start the server console app and let it run in peace:

2) We start the client console app, "make the connection" by pressing any key (which is only a logical connection since it just creates a transparent proxy) but we postpone the "bombardment":

3) We start up Mark Russinovich's Process Explorer and use it to discover the client process in the process list, and while doing that we open it's properties window and select the TCP/IP tab:

4) We hit any key in the client console app, and .. TA DAA !! You get a lot of connections in Process Explorer. Are they a hundred ? Sometimes yes, sometimes no. It's a connection pool, that's for sure. After a short while (5 to 10 seconds) of idleness they close down which is a very good thing (because the .NET Remoting stack is implemented that way).

I hope this experiment generally answered your question.

In more specific cases and in a more rigorous sense you should check out the documentation and read about the various channels that you might use in your .NET Remoting apps (there are loads of them out there, what you've seen here is just the regular TcpChannel officially provided by Microsoft, it depends on what your .NET Remoting configuration says, on whether you're hosting the server in IIS or not, etc).