Remoting Channels


Now that you have an understanding of how to set up and use .NET remoting, we ll discuss choosing an appropriate remoting channel for your applications needs. Two remoting channels are currently available in the .NET Framework ” HTTP and TCP.

Note  

The next version of the .NET Framework is expected to include an interprocess communication (IPC) channel that will allow communication between application domains in different processes on the same computer in the most efficient manner possible.

HTTP Channel

The HTTP channel is designed to communicate over the HTTP protocol. The channel features both a client side and a server side to host HTTP-based remoting communication across application domains. The client side of the HTTP channel is also designed to work with Microsoft Internet Information Server (IIS). IIS can substitute for the server side of the HTTP channel. Using IIS as the server allows the HTTP channel to be more secure by using authentication and more scalable where IIS can more efficiently service thousands of HTTP requests per second. The HTTP channel provides two major features for hosting remoting communications ”interoperability and security.

Interoperability

The HTTP channel by default uses SOAP serialization to encode class types for data transmission. Chapter 4 described SOAP serialization in more detail. The advantage of using SOAP is that the other end of communication can be practically any platform or device as long as it understands the SOAP format and understands how to respond to remoting messages accordingly . This makes communications portable. On the downside, however, SOAP requires more data bytes to be transmitted from the client and the server than other serialization formatters. If you do not want to use SOAP as the HTTP channel s default formatter, you can specify another formatter, such as binary serialization, using a remoting configuration file as described earlier.

Another major advantage of using the HTTP channel is that HTTP communications are usually allowed to pass across firewalls. As a result, you can build distributed applications that can run on both sides of a firewall without special protocol configurations. HTTP communication is sometimes by proxy, which means there is a server that makes HTTP requests on your behalf . Web browsers such as Microsoft Internet Explorer allow you to configure proxy settings that enable the browser to reach the Internet from an intranet environment. The HTTP channel also allows you to configure proxy settings through a remoting configuration file.

Security

An advantage of using the HTTP channel is that you can have IIS host the server side of the remoting communications channel. Using IIS to host remoting allows you to authenticate the user attempting to access a remoting class. IIS handles authentication security by allowing you to lock down the published URI that a client attempts to access. For example, we could expose a well-known object type URI of the DemoClass type described earlier and require that the client use Kerberos authentication to access the class. The authentication capability is only available when running IIS hosting. If you decide to provide direct HTTP channel hosting, then you will lose the authentication security functionality.

Properties

The HTTP channel features several channel properties that can control the behavior of both the HTTP server and the client side of the channel. Table 12-1 outlines the available properties that can be specifically configured on the client and the server.

Table 12-1: HTTP Channel Properties

Property

Availability

Description

allowAutoRedirect

Client

A Boolean value that determines whether the client will handle HTTP redirects.

bindTo

Server

A string representing an IP address for the server to bind to.

clientConnectionLimit

Client

An integer defining how many concurrent connections can be opened to the server.

connectionGroupName

Client

A string representing a group name if the unsafeAuthenticatedConnectionSharing property is set.

credentials

Client

An ICredentials instance that allows a client to pass credentials for password- based authentication schemes such as Kerberos authentication.

exclusiveAddressUse

Server

A Boolean value that forces the server to use the listening IP address and port exclusively so that another application cannot steal the listening TCP port.

listen

Server

A Boolean value that determines whether to allow activation to hook into the outside listener service.

machineName

Client and server

A string representing the machine name of the listening server.

name

Client and server

A string representing the name of the channel.

port

Server

An integer value that specifies what TCP port the server will listen on or what port the client will send TCP packets from. If the value 0 is selected, the infrastructure will choose a port automatically.

priority

Client and server

An integer value that defines the priority of the channel when multiple channels are available.

proxyName

Client

A string identifying a proxy if the client communication must pass through a proxy.

proxyPort

Client

An integer identifying the port on which a proxy is listening for communication from a client.

suppressChannelData

Server

A Boolean value that prevents the server channel from returning channel properties.

timeout

Client

An integer that specifies how long the client channel will wait for a server response.

unsafeAuthenticatedConnectionSharing

Client

A Boolean value that indicates the client will supply credentials and a group name for the connection.

useAuthenticatedConnectionSharing

Client

A Boolean value that tells the server to reuse a connection from an authenticated user.

useIpAddress

Server

A Boolean value that forces the channel to use a specific IP address instead of using the machineName property.

In general, channel properties can be configured in an XML configuration file or they can be configured programmatically using a channel constructor when the channel is created. Values specified in a configuration file are represented as strings while values specified programmatically are configured with native data types.

For example, if you needed to configure proxy settings for an HTTP client channel to pass communications through a proxy server, you could do so by setting the proxyName and proxyPort parameters programmatically on the creation of the client side of the HTTP channel. You also could specify values in an XML client configuration file. The following XML configuration demonstrates how to configure proxy settings for the client side of an HTTP channel to remotely access the class Demo.DemoClass .

 <configuration> <system.runtime.remoting> <applicationname="DemoClient"> <clienturl="http://localhost:80"> <activatedtype="Demo.DemoClass,Demo"/> </client> <channels> <channel ref="http" proxyName="MyCorporateProxy" proxyPort="8080" /> </channels> </application> </system.runtime.remoting> </configuration> 

TCP Channel

The TCP channel is a remoting channel that communicates directly over TCP. One of its advantages is that it handles remoting communications in the most efficient manner possible. On the downside, however, the channel does not offer security mechanisms to protect remoted resources.

By default, the TCP channel uses binary serialization to format messages to streams. In Chapter 4 you learned that the advantage of binary serialization is that the resulting serialized stream is compact, whereas the disadvantage is that a binary stream is not very portable. If the computers on both ends of a remoting channel have the same operating system, then using the TCP channel with binary serialization is the way to go. However, if your application needs to interoperate with a different type of computer, you can override the default binary formatter with the SOAP formatter.

A major disadvantage of the TCP channel is that it does not offer any security authentication solutions to protect the server from malicious clients ; anyone can connect to the server and invoke remoted classes. This can be hazardous if you run a TCP channel server on the Internet and expose classes that can perform hazardous operations on your computer, such as adding or removing files.

Note  

The next version of the .NET Framework is expected to offer an authentication mechanism in the TCP channel. This should enable you to safely deploy TCP channel remoting solutions on the Internet.

Properties

The TCP channel features several channel properties that can control the behavior of both the server and the client side of the channel. Table 12-2 outlines the available properties that can be specifically configured on the client and the server.

Table 12-2: TCP Channel Properties

Property

Availability

Description

bindTo

Server

A string representing an IP address for the server to bind to.

exclusiveAddressUse

Server

A Boolean value that forces the server to use the listening IP address and port exclusively so that another application cannot steal the listening TCP port.

machineName

Client and server

A string representing the machine name of the listening server.

Name

Client and server

A string representing the name of the
channel.

Port

Server

An integer value that specifies what TCP port the server will listen on or what port the client will send TCP packets from.

Priority

Client and server

An integer value that defines the priority of the channel when multiple channels are available. A larger value indicates greater priority.

rejectRemoteRequests

Server

A Boolean value that determines whether the server will only accept requests from the local host.

suppressChannelData

Server

A Boolean value that prevents the server channel from returning channel properties.

useIpAddress

Server

A Boolean value that forces the channel to use a specific IP address rather than the machineName property.




Network Programming for the Microsoft. NET Framework
Network Programming for the MicrosoftВ® .NET Framework (Pro-Developer)
ISBN: 073561959X
EAN: 2147483647
Year: 2003
Pages: 121

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net