One of the Microsoft. Net Remoting Tutorials:. Net Remoting basics and remoting Basics

One of the Microsoft. Net Remoting Tutorials:. Net Remoting basics and remoting Basics

I. Remoting Basics

What is Remoting? In short, we can regard it as a distributed processing method. From the perspective of Microsoft products, it can be said that Remoting is an upgrade of DCOM, which improves many functions and is well integrated into the. Net platform. Microsoft. NET Remoting provides a framework that allows an object to interact with another object through an application domain. This is exactly why Remoting is used. Why? In Windows, applications are separated into separate processes. This process forms a boundary around the application code and data. If the inter-process communication (RPC) mechanism is not used, the Code executed in one process cannot access another process. This is an operating system's protection mechanism for applications. However, in some cases, We need to cross the application domain and communicate with another application domain, that is, cross the border.

In Remoting, a channel is used to implement object communication between two application domains. :

First, the client uses Remoting to access the channel to obtain the server object, and then parses it as the client object through proxy. This provides a possibility to publish server objects as a service. Remote Object code can run on a server (such as an object activated by the server and an object activated by the client). Then, the client connects to the server through Remoting to obtain the service object and serialize it to the client.

In Remoting, in addition to the channel type and port number, the designer does not need to know the data packet format for the objects to be transmitted. However, it must be noted that when obtaining the server-side object, the client does not obtain the actual server-side object, but obtains its reference. This ensures loose coupling between client and server objects, and optimizes communication performance.

1. Two Remoting Channels

There are two main Remoting channels: Tcp and Http. In. Net, the IChannel interface is defined in System. Runtime. Remoting. Channel. The IChannel interface includes the TcpChannel and Http channel types. They correspond to the two types of Remoting channels respectively.

The TcpChannel type is stored in the namespace System. Runtime. Remoting. Channel. Tcp. The Tcp channel provides a Socket-based transmission tool that uses the Tcp protocol to transmit serialized message streams across the Remoting boundary. The TcpChannel type serializes message objects in binary format by default, so it has higher transmission performance. The HttpChannel type is stored in the namespace System. Runtime. Remoting. Channel. Http. It provides an Http protocol for transmitting serialized message streams over the Internet through the firewall. By default, the HttpChannel type serializes message objects in Soap format, so it has better interoperability. Generally, we use TcpChannel more in the LAN; if we want to cross the firewall, we use HttpChannel.

2. Remote Object Activation Method

Before accessing an object instance of the remote type, you must create it and initialize it through a process named Activation. This client creates a remote object through a channel, which is called object activation. In Remoting, remote object activation can be divided into two categories: server-side activation and client activation.

  (1) server activationIs also called the WellKnow method. Many of them are translated as well-known objects. Why is it called the activation mode of well-known objects? The reason is that the server application will publish this type in a well-known Uniform Resource Identifier (URI) before activating the object instance. The server process then configures a WellKnown object for this type and publishes the object based on the specified port or address .. Net Remoting divides server activation into SingleTon mode and SingleCall mode.

SingleTon mode: stateful mode. If it is set to SingleTon activation mode, Remoting creates the same object instance for all clients. When an object is active, the SingleTon instance processes all subsequent client access requests, regardless of whether they are the same client or other clients. The SingleTon instance will remain in the status of the method call. For example, if a remote object has an accumulation method (I = 0; ++ I), it is called by multiple clients (for example, two. If it is set to SingleTon mode, the first customer gets the value 1, and the second customer gets the value 2 because they get the same object instance. If you are familiar with Asp. Net status management, we can regard it as an Application status.

SingleCall mode: SingleCall is a stateless mode. Once set to SingleCall mode, Remoting creates a remote object instance for each client when the client calls the remote object method. GC automatically manages the destruction of the object instance. In the same example, the two clients accessing the remote object obtain 1. We can still consider Asp. Net as a Session state.

  (2) Client Activation. Unlike the WellKnown mode, Remoting assigns a URI for each client activation type when activating each object instance. Once a client request is obtained in the client activation mode, an instance reference is created for each client. The SingleCall mode differs from the client activation mode: first, the creation time of the object instance is different. The client activation method is instantiated once the customer sends a call request, while the SingleCall method is created when the object method is called. Second, the objects activated in SingleCall mode are stateless, and the object lifecycle is managed by GC, while the objects activated on the client are stateful, and their lifecycles can be customized. Third, the two activation modes have different implementation methods on the server side and the client side. Especially on the client, the SingleCall mode is activated by GetObject (), which calls the default constructor of the object. The client activation mode is activated through CreateInstance (), which can pass parameters, so you can call a custom constructor to create an instance.

Ii. Definitions of remote objects

As mentioned above, when obtaining the server object, the client does not obtain the actual server object, but obtains its reference. Therefore, in Remoting, some definitions of remote objects must be followed.

Since the objects passed by Remoting are referenced, the passed remote object class must inherit MarshalByRefObject. MSDN's description of externalbyrefobject is that externalbyrefobject is the base class of objects that communicate across application domain boundaries through proxy message exchange. Objects not inherited from externalbyrefobject are implicitly sent by value. When a Remote Application references a value-based object, a copy of the object is transferred across the remote processing boundary. Because you want to use the proxy method instead of the copy method for communication, you need to inherit MarshallByRefObject.

The following is the definition of a remote object class:

public class ServerObject: MarshalByRefObject
{
 public Person GetPersonInfo (string name, string sex, int age)
 {
 Person person = new Person ();
 person.Name = name;
 person.Sex = sex;
 person.Age = age;
 return person;
 }
}

This class only implements the simplest method, which is to set a person's basic information and return a Person class object. Note the Person class returned here. Because the Person passed here is completed by value, and Remoting requires that it must be a referenced object, so the Person class must be serialized.

Therefore, in the remote object in Remoting, if you want to call or pass an object, such as a class or structure, the class or structure must be serialized

Attribute [SerializableAttribute]:
[Serializable]
public class Person
{
 public Person ()
 {
 
 }

 private string name;
 private string sex;
 private int age;

 public string Name
 {
 get {return name;}
 set {name = value;}
 }

 public string Sex
 {
 get {return sex;}
 set {sex = value;}
 }

 public int Age
 {
 get {return age;}
 set {age = value;}
 }
}

Compile the remote object into Dll in the form of class library. This Dll will be placed on the server and client respectively to add references.

Remote objects that can be transferred in Remoting can be of various types, including complex DataSet objects, as long as it can be serialized. Remote objects can also contain events, but the handling of events on the server side is special, which I will introduce in the third of this series.

Third, the server

According to the first part, according to the different activation modes, the implementation of different channel types on the server side is also different. In general, the server side should be divided into three steps:

1. Registration channel

To communicate across application domains, channels must be implemented. As mentioned earlier, Remoting provides the IChannel interface, which contains two types of channels, TcpChannel and HttpChannel, respectively. In addition to the different performance and serialized data formats, these two types are implemented in exactly the same way, so we will take TcpChannel as an example.

To register TcpChannel, first add a reference to "System.Runtime.Remoting" in the project, and then use the namespace: System.Runtime.Remoting.Channel.Tcp. code show as below:

TcpChannel channel = new TcpChannel (8080);
ChannelServices.RegisterChannel (channel);
When instantiating the channel object, pass the port number as a parameter. Then call the static method RegisterChannel () to register the channel object.

2. Register a remote object

After the channel is registered, to be able to activate the remote object, the object must be registered in the channel. Depending on the activation mode, the method of registering objects is also different.

(1) SingleTon mode

For the WellKnown object, it can be achieved through the static method RemotingConfiguration.RegisterWellKnownServiceType ():

RemotingConfiguration.RegisterWellKnownServiceType (
 typeof (ServerRemoteObject.ServerObject),
 "ServiceMessage", WellKnownObjectMode.SingleTon);
(2) SingleCall mode

The method of registering objects is basically the same as the SingleTon mode, just change the enumeration parameter WellKnownObjectMode to SingleCall.

RemotingConfiguration.RegisterWellKnownServiceType (
 typeof (ServerRemoteObject.ServerObject),
 "ServiceMessage", WellKnownObjectMode.SingleCall);
(3) Client activation mode

For the client activation mode, the method used is different, but the difference is not large, and the code is clear at a glance.

RemotingConfiguration.ApplicationName = "ServiceMessage";
RemotingConfiguration.RegisterActivatedServiceType (
 typeof (ServerRemoteObject.ServerObject));
Why set the ApplicationName property before registering the object method? In fact, this attribute is the URI of the object. For the WellKnown mode, the URI is placed in the parameters of the RegisterWellKnownServiceType () method. Of course, you can also use it to assign values to the ApplicationName property. In the overload of RegisterActivatedServiceType () method, there is no ApplicationName parameter, so it must be separated.

3. Log off the channel

If you want to close the Remoting service, you need to log off the channel, you can also turn off the monitoring of the channel. When we register a channel in Remoting, the channel monitoring is automatically turned on. If the monitoring of the channel is closed, the channel cannot accept client requests, but the channel still exists. If you want to register the channel again, an exception will be thrown.

// Get the currently registered channel;
IChannel [] channels = ChannelServices.RegisteredChannels;

// Close the channel named MyTcp;
foreach (IChannel eachChannel in channels)
{
 if (eachChannel.ChannelName == "MyTcp")
 {
 TcpChannel tcpChannel = (TcpChannel) eachChannel;

 // Turn off monitoring;
 tcpChannel.StopListening (null);

 // Log off the channel;
 ChannelServices.UnregisterChannel (tcpChannel);
 }
}

In the code, the RegisterdChannel property obtains the currently registered channel. In Remoting, it is allowed to register multiple channels at the same time, which will be explained later.

Fourth, the client

The client mainly does two things, one is to register the channel. This can be seen from Figure 1, in Remoting, both the server and the client must pass messages through the channel to obtain remote objects. The second step is to obtain the remote object.

1. Registration channel:

TcpChannel channel = new TcpChannel ();
ChannelServices.RegisterChannel (channel);
Note that when the client instantiates the channel, it is the default constructor that is called, that is, the port number is not passed. In fact, this port number is indispensable, except that its designation is placed behind as part of Uri.

2. Obtain the remote object.

Same as the server side, different activation modes determine that the client implementation will also be different. However, this difference is only the difference between the WellKnown activation mode and the client activation mode. For SingleTon and SingleCall modes, the client implementation is exactly the same.

(1) WellKnown activation mode

To obtain a well-known remote object on the server side, you can get it through the GetObject () method of the Activator process:

ServerRemoteObject.ServerObject serverObj = (ServerRemoteObject.ServerObject) Activator.GetObject (
 typeof (ServerRemoteObject.ServerObject), "tcp: // localhost: 8080 / ServiceMessage");
First activated in WellKnown mode, the method for the client to get the object is to use GetObject (). The first parameter is the type of the remote object. The second parameter is the uri on the server side. If it is an http channel, it is natural to use http: // localhost: 8080 / ServiceMessage. Because I use a local machine, so here is localhost, you can replace it with a specific server IP address. The port must be the same as the port on the server. Behind is the remote object service name defined by the server, that is, the content of the ApplicationName attribute.

(2) Client activation mode

As mentioned earlier, the WellKnown mode can only call the default constructor when the client creates an object. The above code illustrates this because the GetObject () method cannot pass the constructor parameters. The client activation mode can create a remote object through a custom constructor.

There are two methods of client activation mode:
1) Call the static method RegisterActivatedClientType () of RemotingConfiguration. The return value of this method is Void, it just registers the remote object on the client. The specific instantiation also needs to call the constructor of the object class.

RemotingConfiguration.RegisterActivatedClientType (
 typeof (ServerRemoteObject.ServerObject),
 "tcp: // localhost: 8080 / ServiceMessage");
ServerRemoteObject.ServerObject serverObj = new ServerRemoteObject.ServerObject ();
2) Call the CreateInstance () method of the process Activator. This method will create a class object of the type specified by the method parameter. It differs from the previous GetObject () in that it calls the constructor on the client, while GetObject () just obtains the object, and creating the instance is done on the server. The CreateInstance () method has many overloads, and I will focus on two of them.

a, public static object CreateInstance (Type type, object [] args, object [] activationAttributes);

Parameter Description:
type: The type of object to be created.
args: an array of parameters that matches the number, order, and type of parameters of the constructor to be called. If args is an empty array or a null reference (Nothing in Visual Basic), the constructor with no parameters is called (the default constructor).
activationAttributes: an array containing one or more attributes that can participate in activation.

The parameter args here is an object [] array type. It can pass parameters in the constructor of the object to be created. In fact, we can draw a conclusion from this: the remote object class passed by the WellKnown activation mode can only use the default constructor; while the Activated mode can be customized by the user. The activationAttributes parameter is usually used to pass the server url in this method.
Suppose our remote object class ServerObject has a constructor:
ServerObject (string pName, string pSex, int pAge)
{
 name = pName;
 sex = pSex;
 age = pAge;
}
Then the implemented code is:

object [] attrs = {new UrlAttribute ("tcp: // localhost: 8080 / ServiceMessage")};
object[] objs = new object [3];
objs [0] = "wayfarer";
objs [1] = "male";
objs [2] = 28;
ServerRemoteObject.ServerObject = Activator.CreateInstance (
 typeof (ServerRemoteObject.ServerObject), objs, attrs);
As you can see, the objs [] array passes the constructor parameters.

b. public static ObjectHandle CreateInstance (string assemblyName, string typeName, object [] activationAttribute);

Parameter Description:
assemblyName: The name of the assembly of the type named typeName will be found in it. If assemblyName is a null reference (Nothing in Visual Basic), the assembly being executed is searched.
typeName: The name of the preferred type.
activationAttributes: an array containing one or more attributes that can participate in activation.

The parameter description is clear at a glance. Note that the return value of this method is of type ObjectHandle, so the code is different from the previous one:

object [] attrs = {new UrlAttribute ("tcp: // localhost: 8080 / EchoMessage")};
ObjectHandle handle = Activator.CreateInstance ("ServerRemoteObject",
 "ServerRemoteObject.ServerObject", attrs);
ServerRemoteObject.ServerObject obj = (ServerRemoteObject.ServerObject) handle.Unwrap ();
This method is actually the default constructor called. The ObjectHandle.Unwrap () method returns the wrapped object.

Description: To use UrlAttribute, you also need to add in the namespace: using System.Runtime.Remoting.Activation;

Five, the supplement of Remoting foundation

Through the above description, basically has completed a simplest Remoting program. This is a standard method of creating a Remoting program, but in the actual development process, we may encounter strange situations. If we only master a so-called "standard", we can deliberately "eat a lot of food and eat all over the sky" Is impossible.

1. Register multiple channels

In Remoting, it is allowed to create multiple channels at the same time, that is, create different channels according to different ports. However, Remoting requires that the channel name must be different because it is used as the unique identifier of the channel. Although IChannel has a ChannelName attribute, this attribute is read-only. Therefore, the method of creating channels described above cannot fulfill the requirement of registering multiple channels simultaneously.

At this time, we must use the IDictionary interface in System.Collection:

Register Tcp channel:

IDictionary tcpProp = new Hashtable ();
tcpProp ["name"] = "tcp9090";
tcpProp ["port"] = 9090;
IChannel channel = new TcpChannel (tcpProp,
 new BinaryClientFormatterSinkProvider (),
 new BinaryServerFormatterSinkProvider ());
ChannelServices.RegisterChannel (channel);
Register Http channel:

IDictionary httpProp = new Hashtable ();
httpProp ["name"] = "http8080";
httpProp ["port"] = 8080;
IChannel channel = new HttpChannel (httpProp,
 new SoapClientFormatterSinkProvider (),
 new SoapServerFormatterSinkProvider ());
ChannelServices.RegisterChannel (channel);
In the name attribute, you can define different channel names.

2. Remote object metadata correlation

Because both the server and the client use remote objects, the usual way is to generate two identical objects Dll and add references respectively. However, for code security, and to reduce the client's relevance to the metadata of remote objects, we need to change this method. That is, the remote objects are implemented on the server side, and the metadata of these implementations is deleted on the client side.

Due to the different activation modes, the method of creating objects on the client is also different, so to separate the correlation of metadata, it should also be divided into two cases.

(1) WellKnown activation mode:

Through the interface. On the server side, provide interfaces and concrete class implementations, while on the client side only provide interfaces:

public interface IServerObject
{
 Person GetPersonInfo (string name, string sex, int age);
}

public class ServerObject: MarshalByRefObject, IServerObject
{......}
Note: The name of the assembly that generates the object on both sides must be the same, strictly speaking, the name of the namespace must be the same.
          
(2) Client activation mode:

As mentioned earlier, for the client activation mode, whether it is using a static method or using the CreateInstance () method, you must call the constructor on the client to instantiate the object. Therefore, the remote object we provide on the client cannot provide only the interface without the implementation of the class. In fact, to separate the metadata from the remote object, there are two options:

a. Use WellKnown activation mode to simulate client activation mode:

The method is to use the "abstract factory" in the design pattern. The following class diagram describes the overall solution:

We add the interface and implementation class of the abstract factory to the remote object on the server side:

public interface IServerObject
{
 Person GetPersonInfo (string name, string sex, int age);
}

public interface IServerObjFactory
{
 IServerObject CreateInstance ();
}

public class ServerObject: MarshalByRefObject, IServerObject
{
 public Person GetPersonInfo (string name, string sex, int age)
 {
  Person person = new Person ();
  person.Name = name;
  person.Sex = sex;
  person.Age = age;
  return person;
 }
}

public class ServerObjFactory: MarshalByRefObject, IServerObjFactory
{
 public IServerObject CreateInstance ()
 {
  return new ServerObject ();
 }
}

Then only the factory interface and the original object interface are provided in the remote object of the client:

public interface IServerObject
{
 Person GetPersonInfo (string name, string sex, int age);
}

public interface IServerObjFactory
{
 IServerObject CreateInstance ();
}

We use WellKnown activation mode to register remote objects, on the server side:

// pass the object;
RemotingConfiguration.RegisterWellKnownServiceType (
 typeof (ServerRemoteObject.ServerObjFactory),
 "ServiceMessage", WellKnownObjectMode.SingleCall);
Note that what is registered here is not a ServerObject class object, but a ServerObjFactory class object.

Client:

ServerRemoteObject.IServerObjFactory serverFactory =
 (ServerRemoteObject.IServerObjFactory) Activator.GetObject (
 typeof (ServerRemoteObject.IServerObjFactory),
 "tcp: // localhost: 8080 / ServiceMessage");

ServerRemoteObject.IServerObject serverObj = serverFactory.CreateInstance ();
Why is this a simulation of client activation mode? From the point of view of the activation method, we are using the SingleCall mode to activate the object, but at this time it is not the remote object we want to pass, but the factory object. If the client wants to create a remote object, it should also be obtained through the CreateInstance () method of the factory object. This method is called on the client side. Therefore, its implementation is equivalent to the client activation mode.

b. Use replacement classes to replace metadata of remote objects

In fact, we can use a trick to trick Remoting. The substitute class mentioned here is this trick. Since it is providing services, the implementation details of the remote object passed by Remoting are of course placed on the server side. But to put a copy of the object on the client, it is because the client has to call the constructor, and has taken a helpless move. Since the specific implementation is on the server side, and in order to be instantiated on the client side, then implement these on the client side. As for the details of the implementation, don't worry about it.

If the remote object has a method, the server provides the method implementation, and the client provides this method. OK, as for the implementation, you can throw an exception or return a null value; if the method returns void, then Can be empty. The key is that this client class object must have this method. The implementation of this method is actually similar to the method declaration, so I say it is a trick. If the method is true, so is the constructor.

It is more intuitive to use code to illustrate this "conspiracy":

Service-Terminal:

public class ServerObject: MarshalByRefObject
{
 public ServerObject ()
 {
  
 }

 public Person GetPersonInfo (string name, string sex, int age)
 {
  Person person = new Person ();
  person.Name = name;
  person.Sex = sex;
  person.Age = age;
  return person;
 }
}

Client:

public class ServerObject: MarshalByRefObject
{
 public ServerObj ()
 {
  throw new System.NotImplementedException ();
 }

 public Person GetPersonInfo (string name, string sex, int age)
 {
  throw new System.NotImplementedException ();
 }
}

Comparing the client and server, the client's method GetPersonInfo () has no specific implementation details, but just throws an exception. Or directly write the statement return null, or OK. We call this class of client An alternative class for remote objects.

3. Use configuration files

The method described above, the server uri, port, and activation mode are set by code. In fact, we can also use the configuration file to set. This has an advantage because this configuration file is an Xml document. If you need to change the port or other, we do not need to modify the program and recompile, but only need to change this configuration file.

(1) Configuration file on the server side:

<configuration>
 <system.runtime.remoting>
 <application name = "ServerRemoting">
  <service>
  <wellknown mode = "Singleton" type = "ServerRemoteObject.ServerObject" objectUri = "ServiceMessage" />
  </ service>
  <channels>
   <channel ref = "tcp" port = "8080" />
  </ channels>
 </ application>
 </system.runtime.remoting>
</ configuration>
If it is the client activation mode, change wellknown to activated and delete the mode attribute.

Put the configuration file in the application folder of the server program and name it ServerRemoting.config. Then the previous server-side program can directly use this statement:

RemotingConfiguration.Configure ("ServerRemoting.config");
(2) Client configuration file

If it is the client activation mode, the modification is the same as above. The call also uses the RemotingConfiguration.Configure () method to call the configuration file stored on the client.

The configuration file can also be placed in machine.config. If the client program is a web application, it can be placed in web.config.

4. Turn on / off the specified remote object

Remoting does not provide a method similar to UnregisterWellKnownServiceType (), that is, once a remote object is registered through, if the channel is not closed, the object will always exist in the channel. As soon as the client activates the object, an object instance is created. If there is only one remote object transmitted by Remoting, there is no problem, just close the channel. What if you transfer multiple remote objects? What should I do to close the specified remote object? What if I need to start after closing?

We noticed that Marshal () and Disconnect () methods are provided in Remoting, the answer is here. The Marshal () method is to convert the MarshalByRefObject class object to the ObjRef class object. This object is to store all relevant information needed to generate the agent to communicate with the remote object. In this way, the instance can be serialized for transmission between application domains and over the network, and the client can call it. The Disconnect () method disconnects the specific instance object from the channel.

Methods as below:
First register the channel:

TcpChannel channel = new TcpChannel (8080);
ChannelServices.RegisterChannel (channel);
Then start the service:
First instantiate the remote object on the server side.

ServerObject obj = new ServerObject ();

Then, register the object. Note that instead of RemotingConfiguration.RegisterWellKnownServiceType (), use RemotingServices.Marshal ():

ObjRef objrefWellKnown = RemotingServices.Marshal (obj, "ServiceMessage");

If you want to unregister the object, then:

RemotingServices.Disconnect (obj);

Note that the Disconnect class object must be the one instantiated earlier. Because of this, we can create the specified remote object as needed, and when closed, the object instantiated before Disconnect.

As for the call of the client, it is the same as the method of the previous WellKnown mode, and it is still obtained through Activator.GetObject (). But from the point of view of the implementation code, we will notice a problem. Because the server side explicitly instantiates the remote object, no matter how many clients are the same, they call the same remote object. Therefore, we call this method the simulated SingleTon mode.

Client activation mode

We can also simulate the client activation mode through Marshal () and Disconnect (). First, let's review the "Remote Object Metadata Relevance" section. In this section, I talked about using the design pattern's "abstract factory" to create object instances, which uses the SingleCall pattern to simulate the client activation pattern. Think carefully about the previous simulated SingleTon mode. Is the answer coming out?

In the "simulated SingleTon" mode, we Marshal the specific remote object instance, so that the client can obtain the reference information of the object. Then we change the way of thinking, when we use an abstract factory to provide an interface, the factory class implements the method of creating a remote object. Then we create a factory class instance on the server side. Then Marshal this factory class instance. When the client obtains an object, it does not obtain a specific remote object, but a specific factory object. Then call the CreateInstance () method to create a specific remote object instance. At this time, for multiple clients, the same factory class object is called; however, the remote object is created by each client itself, so for the remote object, it is activated by the client and created differently Object.

When we want to start / close the specified object, we only need to use the Disconnet () method to cancel the factory class object.

6. Summary

Microsoft.Net Remoting is really broad and profound. The content of the whole Remoting is not what I can describe in this small article, nor is it something that my beginner of Remoting can master. Wang Guowei wrote in "The Words of the World": Ancient and modern scholars must pass through three realms. "Last night the west wind withered the green trees and walked up the tall buildings alone, looking at the end of the world." This first realm also. "The belt gradually widens, and I don't regret it. It makes people haggard for Iraq." This second realm also. "People searched him for thousands of Baidus, and looked back suddenly, but the man was in the dim light." This third realm also. If I use this to describe my study of Remoting, I was still in the "lonely high-rise building, looking at the end of the world", it can be said that he has not yet entered the room.

Maybe you need to get "the belt becomes wider", and learn Remoting "finally don't regret it" before you can "suddenly look back".

The above is all the contents of .Net Remoting basics, I hope to give you a reference, and I hope you can support the home of helpers.