.NET remoting

from Wikipedia, the free encyclopedia

.NET Remoting is a comprehensive, extensible framework for developing distributed applications and, as such, is part of Microsoft's .NET Framework . It is used for seamless communication between objects that are located in different application domains or processes or on different computers. It enables, so to speak, communication between applications that are locally on the same computer, on different computers in the same network, or even on computers across multiple networks. .NET Remoting was built into the Common Language Runtime (CLR). This gives uniform interfaces to other technologies in .NET.

.NET Remoting is now referred to as outdated technology by Microsoft and is no longer recommended for developing distributed applications. The recommended successor technology was initially the Windows Communication Foundation , which also belongs to .NET . However, since this is not available for .NET Core, Microsoft recommends gRPC instead , which has the advantage of being available across platforms.

The history of .NET communication

In the past, interactive communication between programs was carried out using DCOM (Distributed COM), which works quickly and easily with computers that are located on the same network. However, if communication takes place over the Internet, enormous hurdles must be overcome with DCOM. In addition, it is hardly possible to operate DCOM over a firewall, since DCOM tries to establish its connection over several ports, which are usually blocked by default on a firewall.

.NET Remoting eliminates the problems of DCOM by supporting multiple protocols.

MarshalByRefObject

As mentioned above, with remoting it is possible to create distributed RPC-based object systems. Using remoting is very easy. The class library defines a class MarshalByRefObject, which is the base class for all distributed objects. If you want to use an object reference to access an instance of a class across process boundaries, it is sufficient to derive the class from MarshalByRefObject, as the following example shows: 

public class Foo: MarshalByRefObject
{
	…
}

RPC

The basic communication in remoting systems is Remote Procedure Call (RPC) -based. The architecture of remoting names as essential elements:

  • Distributed objects,
  • Proxies and
  • Transport channels

Each of these elements can be individually adapted and expanded. Unlike DCOM, distributed elements are no longer registered in the Windows registry, but are published by a so-called service host. A service could for example

  • a simple console or Windows program,
  • a Windows system service or
  • be the Internet Information Server (IIS).

Interfaces

In contrast to DCOM, the interfaces of the distributed objects no longer have to be described in an IDL (Interface Definition Language). It is possible to use interfaces or simply to transport the class of distributed objects to the clients. The use of interfaces is particularly attractive because the interface concept is an elementary component of the platforms and can therefore be understood by all .NET-compliant languages.

z. E.g. a C # interface could also be represented by a Visual Basic.NET interface. It has the same effect: 

public interface IFoo
{
	void MachWas(string doit);
}

Public Interface IFoo
	Sub MachWas(ByVal doit As String)
End Interface

It is important that the C # interface z. B. can be implemented in a Visual Basic.NET class or vice versa. Due to the language interoperability of the .NET platform, interfaces can to a certain extent completely replace an IDL.

Proxy objects

Proxy objects are created when a client activates a remote object. The proxy object acts like a proxy for the remote object. It ensures that all calls made for the proxy are directed to the correct remote object instance. When a client activates a remote object, the framework creates a local instance of the TransparentProxy class that contains a list of all classes and the interface methods of the remote object. Because the TransparentProxy class is registered when the CLR is created, all method calls on the proxy are intercepted by the CLR. Here the call is examined to determine whether it is a valid method of the remote object and whether an instance of the remote object is in the same application domain as the proxy. If this is the case, a simple method call is forwarded to the actual object. If the object is in a different application domain, the call parameters are packed in a stack in an IMessage object and passed on to the RealProxy class by calling its Invoke method. This class (or rather an internal implementation of the class) is responsible for forwarding the messages to the remote object. Both the TransparentProxy and RealProxy classes are created securely when a remote object is activated, but only TransparentProxy is returned to the client. TransparentProxy is an internal class that cannot be replaced or extended. The RealProxy class and the ObjRef class are again public and can be expanded and adapted if necessary. The RealProxy class is e.g. B. an ideal candidate for load balancing because it handles all function calls on a remote object. When Invoke is called, a RealProxy-derived class can get information about the load on servers on the network and forward the call to the appropriate server.

Channel

Remote objects are accessed using so-called channels. Channels transport the message to or from the object. There are two channels that are important: TcpChannel and HttpChannel. These can also be derived so that your own channel can be created according to your needs.

Creation of distant objects

As already mentioned at the beginning, there is the MarshalByRefObject, from which the class must be derived. However, there are two distinguishable ways in which remote objects can be created:

  • Object generation by server (server-activated objects)
  • Object generation by client (client-activated objects)

In the case of server-activated objects (SAO), the object instances are generated in the server. Alternative methods would be:

  • Single-call object
    • each time it is called, a new object is created and then destroyed
    • This allows the load to be distributed across server farms
  • Singleton object
    • there is a single object instance for all clients
    • The object is created when the server starts
  • Published object

In the case of client-activated objects (CAO), the client creates the objects: Alternative methods would be:

  • direct generation
  • Production via factory (Factory)

.NET Remoting 2.0

A newer version (.NET Remoting 2.0) is already available, which offers support for IPv6 addresses and the exchange of generic types. Another new feature is the IPC remoting channel for local inter-process communication without using a network protocol stack.

literature

Web links

Individual evidence

  1. ↑ shirhatti: Introduction: GrpC for WCF developers. Retrieved November 28, 2019 (German).