Share via

2.1.6 .NET Remoting

  • Article

The following diagram shows the typical architecture of a distributed application that is built by using the .NET remoting framework.

Typical architecture of a distributed application that uses the .NET remoting framework

Figure 10: Typical architecture of a distributed application that uses the .NET remoting framework

By using .NET remoting, objects executing within the logical subdivisions of application domains and contexts can interact with one another across .NET remoting boundaries.

With .NET remoting, client applications can be built that use objects in other processes on the same computer or on any other computer that is reachable over its network. The .NET remoting framework can also be used to communicate with other application domains in the same process. The .NET remoting framework provides an approach to interprocess communication that abstracts the remotable object from a specific client or server application domain and from a specific mechanism of communication.

To use .NET remoting to build an application in which two components communicate directly across an application domain boundary, the following components are required:

  • A remotable object, which is referred to as ServerObject in the typical architecture of a distributed application diagram.

  • A host application domain to listen for requests for that object (Application Domain 2 in the typical architecture of a distributed application diagram).

  • A client application domain that makes requests for that object (Application Domain 1 in the typical architecture of a distributed application diagram).

On the client side, the remoting infrastructure creates a proxy that stands in as a pseudo-instantiation of the remotable object and returns to the client object a reference to the proxy. It does not implement the functionality of the remotable object, but instead presents a similar interface. When a client calls a method, the remoting infrastructure handles the call, checks the type information, and sends the call over the channel to the server process. On the server side, the listening channel picks up the request and makes the call to the remotable object on behalf of the client. The results are serialized and transferred by way of the sink to the client, where the proxy reads them and hands them over to the calling application.

The .NET remoting infrastructure manages transferring the required information over the wire. The following diagram shows the protocol stack of the remoting infrastructure.

Protocol stack of the .NET remoting infrastructure

Figure 11: Protocol stack of the .NET remoting infrastructure

The .NET remoting framework supports two transport protocols, namely TCP and HTTP, but a user can add any transport to the .NET remoting stack.

The .NET remoting core protocol ([MS-NRTP]) specifies a mechanism whereby a calling program can invoke a method in a different address space over the network.

The .NET Remote Lifetime Services Extension ([MS-NRLS]) extends the .NET Remoting: Core Protocol [MS-NRTP] to add a mechanism allowing clients to explicitly create Server Objects, and adds another mechanism allowing clients and servers to control the lifetime of Server Objects. The .NET Remote Lifetime Services Extension adds new methods and semantics for activation and lifetime management.

Encoding

A .NET remoting application can use either a binary encoding for .NET remoting as specified in the .NET Remoting Binary Format ([MS-NRBF]), or SOAP encoding, as specified in [SOAP1.1], with the .NET remoting-specific portions of the mapping specified in SOAP Serialization Format ([MS-NRTP] section 2.2.4).

Binding

The .NET remoting framework can be bound to either TCP ([RFC793]) or HTTP ([RFC2616]). The TCP binding for binary encoding is specified in TCP Transport ([MS-NRTP] section 2.1.1), and the HTTP binding is specified in HTTP Transport ([MS-NRTP] section 2.1.2). The TCP binding to SOAP is specified in SOAP on TCP ([MS-NRTP] section 2.1.3.2), and the HTTP binding can be found in [SOAP1.1] section 6, with .NET remoting-specific portions of the mapping specified in SOAP on HTTP ([MS-NRTP] section 2.1.3.1).

Security

Over a TCP connection, optional security can be provided by .NET NegotiateStream Protocol ([MS-NNS]). This protocol enables:

  • Client and/or server authentication

  • Data confidentiality and integrity

The .NET NegotiateStream Protocol provides mutually authenticated and confidential communication as specified in [MS-NNS].

A key benefit is that authentication in [MS-NNS] is accomplished without the use of digital certificates. Other protocols, such as Transport Layer Security (TLS, [RFC5246]), require the use of digital certificates.

Over an HTTP connection, NTLM Authentication ([MS-NLMP]) or HTTP authentication ([RFC2617]) can be used. The NTLM Over HTTP Protocol ([MS-NTHT]) specifies how NTLM authentication is used over an HTTP connection.

Interoperability Between CLR and COM

The IManagedObject Interface Protocol ([MS-IOI]) provides interoperability for CLR. It defines the IManagedObject, IRemoteDispatch, and IServicedComponentInfo interfaces.

  • The IManagedObject interface is useful as part of the infrastructure for allowing the CLR to interoperate with COM.

  • The IRemoteDispatch interface is used for method-call dispatch and deactivation.

  • The IServicedComponentInfo interface is used for determining Server Object instance identity.

The following diagram shows the relationship among .NET remoting protocols.

.NET remoting protocol relationships

Figure 12: .NET remoting protocol relationships