INFO: Configurations That Microsoft Supports for Microsoft .NET Remoting with Network Load Balancing (830217)
The information in this article applies to:
- Microsoft .NET Framework 1.1
- Microsoft .NET Framework 1.0
- Microsoft Visual Studio .NET (2003), Enterprise Architect Edition
- Microsoft Visual Studio .NET (2003), Enterprise Developer Edition
- Microsoft Visual Studio .NET (2003), Professional Edition
- Microsoft Visual Studio .NET (2003), Academic Edition
- Microsoft Visual Studio .NET (2002), Enterprise Architect Edition
- Microsoft Visual Studio .NET (2002), Enterprise Developer Edition
- Microsoft Visual Studio .NET (2002), Professional Edition
- Microsoft Visual Studio .NET (2002), Academic Edition
SUMMARYThis article contains information about the configurations
that Microsoft supports for Microsoft .NET Remoting with Network Load
Balancing.MORE INFORMATIONMicrosoft 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.
REFERENCESFor more information, visit the following Microsoft
Developer Network (MSDN) Web sites:
Modification Type: | Major | Last Reviewed: | 10/27/2003 |
---|
Keywords: | kbFaultTolerance KbClientServer kbChannels kbNLB kbRemoting kbinfo KB830217 kbAudDeveloper |
---|
|