Remoting Programming Know

xiaoxiao2021-03-06  63

Remoting foundation

Basic Principles When the client creates an instance of remote RemotableClass, the .NET Framework generates a proxy in the client application domain. The agent look like an actual object. After the agent receives the call, connect to a remote object through the channel.

First, write steps

first step

Write a DLL that contains the class you want Remottable

Public Class RemotableClass: MarshalByrefObject: MarshalByrefObject

{

.

}

Second step

The server process registers the Remotable class so that other applications can be activated. Depending on how the object is activated, the server is registered by two static methods: RegisterActiVatedServiceTy or RegisterWellkNownServiceType. The following statement is registered using REGISTERWELLKNOWNSERVICEPE to register remotely.

RemotingConfiguration.registerWellkNownServiceType

TypeOf (RemotableClass), // Remotable class

"RemoteObject", // Remotable class URI

WellknownObjectMode.singlecall); // activation mode

The first parameter refers to a class that can be remote.

The second means that the client uses to activate the object's URI ---- that is, the client tells the server to activate

The URI of the RemotableClass instance.

The third parameter specifies the activation mode. There are two options. WellknownObjectMode.singlecall is a new instance that creates every call for the client. WellknownObjectMode.singleton refers to a RemotableClass instance to process all client calls.

third step

In order to enable the client to use RemotableClass, the server process must be created and registered a channel. This channel provides a channel for objects and remote client communications. In the server side, the .NET framework provides two channels:

System.Runtime.Remoting.Channels.tcp.tcpserverChannel: You can accept TCP connections for remote clients.

System.Runtime.Remoting.channels.http.httpserverchannel: Accept HTTP connection.

The following statement creates a TCPSerChannel channel listening to the 1234 port, and registration with .NET framework:

TcpserverChannel Channel = New TCPServerChannel (1234);

ChannelServices.RegisterChannel (Channel);

The following statement registers an HTTP channel listening to 1234 port:

HttpServiceChannel Channel = New HttpserverChannel (1234);

ChannelServices.RegisterChannel (Channel);

TCPServerChannel is more efficient. HTTPServerChannel is the option to use when IIS is used as a remote activation agent.

the fourth step

Do some registration must be made in the client to create an instance of the remote class.

The first must register a client channel. The .NET framework provides two types of client channels: TCPClientChannel and HttpClientChannel, corresponding to the server-side channels.

Second, if the client wants to use the New operator to produce a remote object, you must register the remote object to your local application domain.

RemotingConfiguration.registerWellkNownClientType is a class that is registered at the client.

RemotingConfiguration.registerWellkNownServiceType is a class that is registered on the server. The following code registers a TCP channel in the client, and also registers RemotableClass to the local application domain:

TcpClientChannel Channel = New TcpClientChannel ();

ChannelServices.RegisterChannel (Channel);

RemotingConfiguration.registerWellknownClientType

TypeOf (RemotableClass),

"TCP: // Localhost: 1234 / RemoteObject");

The second parameter refers to the URL of the remote object.

The protocol must match the channel protocol registered by the application.

You can use the machine name or IP address to replace LocalHost.

The port number must be the same as the number of ports listened to the server.

Object URI, must be matched with the server with RegisterWellkNownServiceType.

the fifth step

Use New to generate a proxy at the client:

RemotableClass RC = New RemotableClass ();

This operation generates a proxy in the client application domain, returns a reference to RemotableClass.

Second, the actual example

ClockServer.cs

Using system;

Public Class Clock: MarshalByrefObject

{

Public String getcurrenttime ()

{

Return DateTime.now.tolongTimeString ();

}

}

TimeServer.cs

Using system;

Using system.runtime.remoting;

Using system.runtime.remoting.channels;

Using system.runtime.remoting.channels.tcp;

Class myapp

{

Static void main ()

{

TcpserverChannel Channel = New TCPServerChannel (1234);

ChannelServices.RegisterChannel (Channel);

RemotingConfiguration.registerwellknownServiceType

(Typeof, "Clock", WellknownObjectMode.singlecAlL;

Console.WriteLine ("Press Enter to Terminate ...");

Console.readline ();

}

}

TimeClient.cs

Using system;

Using system.runtime.remoting;

Using system.runtime.remoting.channels;

Using system.runtime.remoting.channels.tcp;

Class myapp

{

Static void main ()

{

TcpClientChannel Channel = New TcpClientChannel ();

ChannelServices.RegisterChannel (Channel);

RemotingConfiguration.registerwellknownClientType

(TypeOf (Clock), "TCP: // localhost: 1234 / clock");

Clock clock = new clock ();

Console.writeline (Clock.getCurrentTime ());

}

}

Compile:

1. CSC / T: Library ClockServer.cs

2. CSC /R: clockserver.dll TimeServer.cs

3. CSC /R: ClockServer.dll TimeClient.cs

Copy ClockServer.dll to the client. Because when you create a proxy for a remote object, the .NET framework needs to describe the original data of the Clock class. It can get the original data from the DLL.

Third, configuration method

TimeServer and TimeClient registered channels and remote classes within their source code. This has a disadvantage that once any registration data changes, you must modify the source code and recompile.

This is why the .NET framework supports another form of registration. Disclaimer registration is called static

RemotingConfiguration.configure method is to get information from the config file.

Examples are as follows:

ClockServer.cs

Using system;

Public Class Clock: MarshalByrefObject

{

Public String getcurrenttime ()

{

Return DateTime.now.tolongTimeString ();

}

}

TimeServer.cs

Using system;

Using system.runtime.remoting;

Class myapp

{

Static void main ()

{

RemotingConfiguration.configure ("TimeServer.exe.config");

Console.WriteLine ("Press Enter to Terminate ...");

Console.readline ();

}

}

TimeServer.exe.config

Objecturi = "clock" />

TimeClient.cs

Using system;

Using system.runtime.remoting;

Class myapp

{

Static void main ()

{

RemotingConfiguration.configure ("TimeClient.exe.config");

Clock clock = new clock ();

Console.writeline (Clock.getCurrentTime ());

}

}

TimeClient.exe.config

URL = "TCP: // localhost: 1234 / clock" />

The disadvantage of this means is that the configuration file can be modified and deleted.

Fourth, activation

The .NET framework divides a remote object into two: Server activates objects and client activation objects. The server-side activation object is through RemotingConfiguration'SregiSterwellkNownServiceType and

RegisterWellknownClientType method is registered. The above example is a server-side activation object. Client activation objects are registered by RegisteractiVateServiceType and RegisteractiVatedClientType.

Server-side activation objects are called server activation, because when the client uses New, only one agent is created. The actual object knows (activation) when you call a method through a proxy. In other words, it is not the client to decide when to create a physical true object. The client activation object is created on the server when the client uses New. This is the first difference.

The second difference is that the client activation object can be activated using a non-default constructor (with parameter constructor). Server-side opportunity objects do not support non-default constructors, because using new only creates a proxy and does not create a corresponding actual object. Client activation objects can create proxy and objects at the same time through NEW.

The third difference is how the client and object are associated. When the server activates the object, you can specify an activation mode to determine all requests for each request or create an object instance to serve all requests. The activation mode in these two is:

WellkNownObjectMode.singlecall: Creates a unique object instance for each request.

WellkonwnObjectMode.singleton: Create an object instance to serve all requests

The appropriate activation mode is typically selected according to the environment. For example, if a remote-shot service provides a "one-shot" service, it is not necessary to keep the state between multiple calls or do not need to be shared in all clients, then SingleCall is a correct choice. Because each request is generated a new object instance. If you want to pass data between the client, use Singleton.

Singleton objects A payable place is the synchronization problem of threads. When two clients call the object at the same time, an error may occur, and the synchronization mechanism to be provided using the .NET framework.

The client activation object provides a third choice. When using a client activation object, the object is only a state of the client service, and can be held between multiple calls.

Single-Call server activates objects, Singleton server activation objects and client activation objects provide three different activation modes. Single-call is used when you do not need to share status in all clients. Singleton is used when you want to share status in all clients. When all clients are not required to connect to the same object, just keep the client's own state, use the client activation object.

Program example:

StopWatch.cs

Using system;

Public Class StopWatch: MarshalByrefObject

{

DateTime Mark = datetime.now;

Public void start ()

{

Mark = datetime.now;

}

Public int stop ()

{

Return (Int) ((DateTime.Now - Mark) .totalmilliseConds;

}

StopWatchServer.cs

Using system;

Using system.runtime.remoting;

Using system.runtime.remoting.channels;

Using system.runtime.remoting.channels.tcp;

Class myapp

{

Static void main ()

{

TcpserverChannel Channel = New TCPServerChannel (1234);

ChannelServices.RegisterChannel (Channel);

RemotingConfiguration.registerActiVatedServiceType

(TypeOf (stopwatch));

Console.WriteLine ("Press Enter to Terminate ...");

Console.readline ();

}

}

StopWatchClient.cs

Using system;

Using system.runtime.remoting;

Using system.runtime.remoting.channels;

Using system.runtime.remoting.channels.tcp;

Class myapp

{

Static void main ()

{

TcpClientChannel Channel = New TcpClientChannel ();

ChannelServices.RegisterChannel (Channel);

RemotingConfiguration.RegisterActiVatedClientType

(TypeOf (stopwatch), "TCP: // localhost: 1234");

StopWatch SW = new stopwatch ();

Sw.start ();

Console.writeline ("Press Enter to show Elapsed Time ...");

Console.readline ();

Console.writeline (sw.stop () "Millseconds");

}

}

5. Activator.getObject and activator.createInstance method

The NEW operator is not the only way to activate the remote object. The .NET framework provides other activation methods: GetObject and CreateInstance. They are all members of the System.Activator class. GetObject is used to activate objects activated on the server, while CreateInstance is used to activate objects activated at the client.

When using getObject or createInstance to activate a remote object, it is no longer necessary to call RegisterActiVatedClientType or RegisterWellkNownClientType to register the remotely-managed class on the server. For example: activation When the object activated in the server:

RemotingConfiguration.registerwellknownClientType (TypeOf (Clock), "TCP: // localhost: 1234 / clock");

Clock clock = new clock ();

You can use the following method

Clock Clock = (Clock) Activator.getObject (TypeOf (Clock, "TCP: // LocalHost: 1234 / Clock");

Activate client objects:

RemotingConfiguration.registeractiVatedClientType (TYPWATCH), "TCP: // localhost: 1234"); stopwatch sw = new stopwatch ();

It can be the way:

Object [] URL = {New Urlattribute ("TCP: // localhost: 1234")}

StopWatch SW = (stopwatch) Activator.createInstance (Typeof (StopWatch), NULL, URL);

Why use them to replace NEW? Because when you only know the URL and interface, getObject and CreateInstance can still be used. Assume that the Clock class is changed, it implements an ICLOCK interface.

When using getObject:

IClock IC = (iClock) Activator.getObject (TypeOf (ICLOCK), "TCP: // localhost: 1234 / clock");

If you use new, a compile error occurs because NEW can't accept an interface name:

RemotingConfiguration.registerwellknownClientType

(TypeOf (ICLOCK), "TCP: // localhost: 1234 / clock");

Iclock IC = New iClock ();

Sixth, object survival and rent period

A Single-Call server-side activation object is only survive during method calls. Thereafter, the garbage collector is marked as deleted. Singleton server activation objects and client activation objects are different, and their survival is leased. Rent is an object that implements the ILASE interface that defines the system.runtime.remoting.lifetime namespace.

Singleton server-side activation objects and client activation objects The default leased object has a 5-minute InitialLeasetime, 2 minutes of RenewonCallTime, 5 minutes of Currentleasetime. If the object is not called, it is cleared when the currentleasetime is 0, which is cleared after 5 minutes.

转载请注明原文地址:https://www.9cbs.com/read-85180.html

New Post(0)