.NET Remoting exception

Question

This is about when a .NET remoting exception is thrown. If you take a look at MSDN, it will mention that a remoting exception is thrown when something goes wrong with remoting. If my server is not running, I get a socket exception which is fine.

What I am trying to figure out is: does getting a remoting exception indicate for sure that my server is up and running? If yes, that would solve the problem. If not: Is there a way to figure out if the remoting exception originated on the client side or the server side?

Update:

The problem I am trying to solve is that the server is down initially and then client sends some message to the server. Now I get a socket exception saying "No connection could be made..." which is fine.

There is a thread that is sending messages to the server at regular intervals to see if the server is available. Now, the server comes up, and at that point, you could get the response which is fine or you could get some exception and most probably it will be a remote exception. So, what I am trying to ask is that: in case I don't get a message and I get a remote exception is there a chance that the server is up and running and I am still getting this exception?

All I am doing is just calling a method on the remote object that does nothing and returns. If there is no exception then I am good. Now, if there is a remoting exception and if I knew the remoting exception occurred on the server then I know in spite getting the exception, I am connected to the server.

Answer 1

Try assuring that you send the correct message and the messages received by the server are also correct, e.g. using assertions (it is called Design by Contract). If you have such possibility, try debugging the server side and client side at the same time. (running two VS instances at the same time)

Answer 2

I haven't got access to the source code of my last remoting application, but as far as I can remember we couldn't figure out a way of knowing for definite if the server was up from any of the exceptions we got.
We did check to see if the network was present and warned the user if not (a method on the Environment class I think).

Answer 3

Getting a remoting exception does not guarantee that your server is up and running. If something else happens to be running and listening on that port, the connection will succeed, and you will not get a socket exception. What happens in this case depends on how the application which actually got your connection behaves, but it will probably wind up generating a remoting exception in your client.

It would take a bit more investigation to verify this, but I believe the remoting exception indicates a problem in the communications between the client and the server, so there isn't a "client side" or "server side" that generated it. It means that the two weren't talking happily and it could have been caused by either one.

Answer 4

If the server side application logic threw an exception, it should be able to marshal over to the client to let it know what happened. You can test this by deliberately throwing an exception in one of the remote object's methods. Then call that particular method from the client side expecting an exception:

HttpChannel channel = new HttpChannel();
ChannelServices.RegisterChannel(channel);

IMyRemoteObject obj = (IMyRemoteObject) Activator.GetObject(
 typeof(IMyRemoteObject),
 "http://localhost:1234/MyRemoteObject.soap");
Console.WriteLine("Client.Main(): Reference to rem.obj. acquired");
 int tmp = obj.GetValue();
 Console.WriteLine("Client.Main(): Original server side value: {0}",tmp);
Console.WriteLine("Client.Main(): Will set value to 42");

try
{
 // This method will throw an ApplicationException in the server-side code.
 obj.SetValue(42);
}
catch (Exception ex)
{
 Console.WriteLine("=====");
 Console.WriteLine("Exception type: " + ex.GetType().ToString());
 Console.WriteLine("Message: " + ex.Message);
 Console.WriteLine("Source: " + ex.Source);
 Console.WriteLine("Stack trace: " + ex.StackTrace);
 Console.WriteLine("=====");
}

You can expect an exception received like this

=====
Exception type: System.ApplicationException
Message: testing
Source: Server
Stack trace:
Server stack trace:
   at Server.MyRemoteObject.SetValue(Int32 newval) in i:\projects\remoting.net\ch03\01_singlecallobjects\server\server.cs:line 27
   at System.Runtime.Remoting.Messaging.StackBuilderSink.PrivateProcessMessage(MethodBase mb, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object[]& outArgs)
   at System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMessage msg, Int32 methodPtr, Boolean fExecuteInContext)

Exception rethrown at [0]:
   at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
   at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
   at General.IMyRemoteObject.SetValue(Int32 newval)
   at Client.Client.Main(String[] args) in i:\projects\remoting.net\ch03\01_singlecallobjects\client\client.cs:line 29
=====

It should tell you the Source is at the server, with a server-side stack trace.

Answer 5

If you are intending to use custom exception types to be thrown across the remoting boundray, be sure to mark these types as "[Serializable]". I can't remember the exact error message, but it perplexed me for the better part of a day the first time I saw it.

Also, just a tip, TargetInvocationException often has the REAL exception embedded in its InnerException property. There is nothing more useless than "An exception was thrown by the target of an invocation."

Answer 6

Ok now that you have put it that way, I assume you are use TCP for remoting, for if it was via HTTP, it would be a WebException thrown when failing to connect to the (TCP network port) server. When the server has not launched the application program to register the channel on that designated TCP port, you will get a SocketException. After all, the server is not listening/responding to that port, how can the client ever make a socket connection?

But, if you get a RemotingException it need not necessarily mean the server has its proper Remoting application running fine. You could test by connecting to a wrong URI on a wrong port, like port 80 (IIS).

IMyRemoteObject obj = (IMyRemoteObject) Activator.GetObject(
 typeof(IMyRemoteObject),
 "tcp://localhost:80/MyRemoteObject.rem");

That would result in a RemotingException because while the client can make a TCP connection to port 80, it is IIS responding to the call and not the Remoting app; IIS cannot handle remoting calls directly. Having said that, a RemotingException can also jolly mean a problem at the client side. This blog article may help you understand better.

http://www.cookcomputing.com/blog/archives/000308.html