.NET Reference Guide

Using OneWayAttribute for Remote Calls

Last updated Nov 9, 2007.

Remoting is a very easy way to get a distributed application up and running. However, there are some hidden costs to making remote calls, and if you’re making a lot of remote calls those hidden costs can add up to some serious time. One such cost is that of waiting for a method to return. Remember, when you call a remote method, the .NET Remoting infrastructure packages everything up and calls the server, then waits for the server to execute the method and return. This wait is necessary when the server is returning a value, but if all you want to do is notify the server of an event or pass some data and you don’t need a return value, then there’s no reason to wait around for the server to finish its processing.

OneWayAttribute, defined in the System.Runtime.Remoting.Messaging namespace lets you mark a remote method as "one-way," meaning that it has no return value and that it accepts only in parameters: no out or ref parameters. If you have such a method on your remote interface, marking it with OneWayAttribute tells the Remoting infrastructure to generate a one-way call and not wait around for a return value.

The amount of time this saves can be significant. There is a certain amount of overhead involved with any remote call—network latency, network data transmission time, etc. Depending on the amount of data to be passed, this time can be anywhere from a few milliseconds to tens of milliseconds. Add to that the amount of time it takes the server to decode the remote message, perform any processing, and then return, and you could have a call that requires significant time.

Using OneWayAttribute, your program doesn’t have to wait around for data transmission or server processing, freeing it instead to do other, hopefully more important, things.

One thing that’s unclear is where exactly the Remoting infrastructure takes over and releases the caller. The documentation says that the method can execute synchronously or asynchronously with respect to the caller, and that the caller cannot make assumptions that the one-way call has executed on the server object when thread control returns. My guess is that, in general, the call is processed asynchronously. Testing showed that there was little difference in performance when calling the one-way method asynchronously or synchronously.

Understand, using OneWayAttribute won’t necessarily allow you to make more calls to the remote method. The remote method call still takes the same amount of time to execute, but that time is spent on a separate thread from your program. Your program is off doing something else rather than waiting for an acknowledgement that serves no useful purpose.

One other thing about one-way calls: they can’t throw exceptions. That is, they can’t let exceptions escape. So don’t try to mark a call as one-way if the method you’re calling can throw exceptions. At best, the exception would get swallowed by the Remoting infrastructure. At worst, the exception would bring down the server, or at least the server object with which you’re communicating.