This article has been archived. It is offered "as is" and will no longer be updated.
This article contains information about the configurations that Microsoft supports for Microsoft .NET Remoting with Network Load Balancing.
Microsoft currently supports .NET Remoting with Network Load Balancing only for SingleCall well-known objects. SingleCall well-known objects do not retain state information that relates to each call in their memory. Additionally, SingleCall well-known objects treat each call as a new call. Therefore, any server remoting system can handle any call, and you can load-balance calls. Microsoft does not support Network Load Balancing for Singleton well-known objects or for client-activated objects. Singleton well-known objects and client-activated objects retain state information that relates to each call in their memory. Therefore, you cannot load-balance these objects.
Note Although the Microsoft .NET Framework supports .NET Remoting with Network Load Balancing for Singleton well-known objects, Microsoft does not consider load-balancing for Singleton well-known objects as efficient as load-balancing for SingleCall well-known objects.
When you use .NET Remoting, the .NET Framework creates a connection with a transport channel for a client remoting system to communicate with a server remoting system. Both the client remoting system and the server remoting system are a combination of an Internet Protocol (IP) address and a port number. Microsoft .NET Remoting uses one connection per application domain for a client remoting system. The .NET Framework keeps a connection open until there are 10 seconds of inactivity. After the .NET Framework closes a connection, a new remoting call causes the .NET Framework to try to create another connection. Based on the Network Load Balancing affinity value settings, the .NET Framework load-balances this connection to any of the other available server remoting systems. If the targeted server remoting system does not respond to this attempt to create a connection, a trappable error occurs. You can write code to handle this trappable error.
Even if you configure Network Load Balancing to use the None affinity value, the same server remoting system services all remoting calls from a client remoting system until the .NET Framework closes a connection. However, if the .NET Framework closes a connection and then a new remoting call occurs, the .NET Framework tries to create a connection to any of the other available server remoting systems. If no server remoting system responds to this attempt, a trappable error occurs.
If you use the .NET Framework support for Network Load Balancing, you can load-balance across multiple server remoting systems. This load-balancing increases redundancy and performance. Also, you can write code that can trap connection errors. However, load-balancing across available server remoting systems may not be as evenly distributed as the load-balancing that you can create by using HTTP.
Microsoft currently supports Network Load Balancing only when you use it as described in this article.
For more information, visit the following Microsoft Developer Network (MSDN) Web sites:
Microsoft .NET Framework 1.1, Microsoft .NET Framework 1.0, Microsoft Visual Studio .NET 2003 Enterprise Architect, Microsoft Visual Studio .NET 2003 Enterprise Developer, Microsoft Visual Studio .NET 2003 Professional Edition, Microsoft Visual Studio .NET 2003 Academic Edition, Microsoft Visual Studio .NET 2002 Enterprise Architect, Microsoft Visual Studio .NET 2002 Enterprise Developer, Microsoft Visual Studio .NET 2002 Professional Edition, Microsoft Visual Studio .NET 2002 Academic Edition