Remoting (.NET 1.1) Performance Guidelines - Hosts
From Guidance Share
- J.D. Meier, Srinath Vasireddy, Ashish Babbar, and Alex Mackman
Use IIS to Authenticate Calls
IIS is the only surrogate that provides secure authentication for .NET remoting solutions. You must use the HttpChannel with the IIS host. You configure your application's authentication type by using the standard IIS Properties dialog box. When you host .NET components in IIS, a virtual directory is created and you should place a Web.config file in the root of the virtual directory. You use this Web.config file to expose the remote server objects. Generally, you should place your remote object assemblies in the \bin subfolder, beneath your application's virtual directory, although you can also place them in the server's global assembly cache.
The following code fragment shows a sample Web.config file. Note that the object Uniform Resource Identifier (URI) that clients bind to must include the ".soap" extension for IIS to know how to route calls to your objects.
<?xml version="1.0" encoding="utf-8" ?> <configuration> <system.runtime.remoting> <application> <service> <wellknown mode="Singleton" type="Namespace.ClassName,AssemblyName" objectUri="EndpointURI.soap"/> </service> </application> </system.runtime.remoting> </configuration>
Turn Off HTTP Keep-Alives When Using IIS
The HTTP protocol provides a mechanism to prevent browsers from having to open several connections, just to bring back all the data for a page. HTTP keep-alives enable the browser to open one connection with the server and maintain that connection for the life of the communication. This can greatly increase the browser's performance because it can make multiple requests for several different graphics to render a page.
A .NET remote method call does not require the connection to remain open across requests. Instead, each method call is a self-contained request. By turning off HTTP keep-alives, the server is allowed to free unneeded connections as soon as a method call completes.
To turn off HTTP keep-alives in IIS
1. Open the Internet Information Services Microsoft Management Console (MMC) snap-in. 2. Right-click your Web site (not the application's virtual directory), and then click Properties. 3. Clear the HTTP Keep-Alives Enabled checkbox.
Host in IIS if You Need to Load Balance Using NLB
You cannot load balance across a server farm with the TcpChannel, due to the machine affinity of the underlying Transmission Control Protocol (TCP) connection. This severely limits your application's ability to scale out. To provide an architecture that can scale out, use IIS as the host, combined with the HttpChannel. This configuration provides for the greatest scale out ability, because each method call over the HttpChannel only lives for the life of the method call and maintains no machine affinity.
Use a Custom Host Only in Trusted Server Scenarios
A custom host does not have any built-in mechanism to authenticate calls. Therefore, you should use custom hosts only in trusted server scenarios. The combination of using a custom application with the TcpChannel and Binaryformatter is the fastest approach, in comparison to other remoting or Web service options, although security is the main tradeoff.
With additional development effort, you can develop custom security mechanisms by developing custom sinks, although this is not recommended because it will make porting your solutions to future Microsoft remote communication technologies more difficult.
- For more information about developing custom security solutions for .NET remoting, see ".NET Remoting Authentication and Authorization Sample – Part II" on MSDN at http://msdn.microsoft.com/library/en-us/dndotnet/html/remsec.asp?frame=true.
- For more information about how to secure .NET remoting solutions, see Chapter 13, "Building Secure Remoted Components," in Improving Web Application Security: Threats and Countermeasures on MSDN at http://msdn.microsoft.com/library/en-us/dnnetsec/html/THCMCh13.asp.