Net remoting configuration files

Here in this article all samples will use binary channels, tcp. It requires less traffic load and better performance as there is no overhead with XML parsing. For our production projects it is a big plus. As usual for distributed applications, there is a Server and a Client application.

NET Remoting we can have as many clients as we want, and all those Client applications can use the same Server. NET remoting is not just a socket with low level methods. It is framework where you can work remotely with classes with ability to invoke methods, to pass custom types as parameters and get them as return values, to throw Exceptions between processes, to pass Callback delegates and have them invoked later remotely, to do asynchronous calls.

Server that holds the instantiated remoting object of our service type 3 point 2 — client application that can connect to Server and use remoting object. You can see two separate processes. Server is holding a real instance of MyService. This instance can be used by other processes over. NET Remoting. Client process is not instantiating the instance of MyService.

It just has some transparent proxy. When Client application invokes methods of MyService proxy, the proxy redirects those calls to. That remoting layer knows where to send such call — so, call goes over network e.

NET Remoting channel right to our remoted Server process. After that Remoting layer on Server side knows if it should use already existing instance of MyService or create new one. It depends on type of activations. All this will be described later in this article. It consists of three core projects. Almost all samples in this article will have them:. You can start as many Client applications as you want.

All of them will be served by single Server application. You cannot start several Servers at the same time though. This is because there is a port to listen for remote Client applications. You cannot initiate several socket listeners on the same network card and the same port.

Also, I would like to pay your attention at Log and Utils classes. They will be used with all samples. You will find Log useful to print timestamp with each print out. Also, it prints id of current thread — so we can easily see if the same thread was used for group of actions or not. As for Utils class, it dumps information about all registered remoting service and client types.

It helps you to catch some misconfiguration in case something is not working:. Here we describe our remoting type — MyService.

It must be derived from MarshalByRefObject. This parent class tells our MyService class not to be sent by value — it is referred by reference only. As you may guess, we instantiate MyService object in Server application and use it from Client application.

That is why we should expect log message to appear in Server console and not in Client one. The same about MyService constructor. Log message about object creation should appear in Server console. It might surprise you if you really see. NET Remoting for first time.

There is nothing specific and complex here. Why is it working? NET services. So, the only line of code that really turns our regular console application into. Configure "ONXServer. This is nice approach as you can change behavior of your application without need to change and recompile our code. This wellknown section is the place where you describe your service to be available for Client applications. There are 3 attributes for it: 1 full type description — describes, what type to instantiate when we get request for this welknown type from Client.

Full type value consists of type name with full namespace path and after comma there is the name of assembly where this type is. Here we might have several channels defined. It will be listening on port You may notice pretty much similarity between Server and Client configurations.

It makes application understand that when we create instance of MyService we actually want to request this class remotely. So, no actual instance of MyService is created in Client application.

We only create Proxy that knows where to send our call requests whenever we call some method. As you see it is as simple as Server console application. Configure "ONXClient. Then you dump information about all remote types that were registered so far.

As you understand now, there will be only transparent proxy created. This call will go to Server application, get return value from there, deliver it to Client application and print in our log on Client side. Sometimes it is easier to have it in code, but it makes harder to do quick adjustments or modifications to configuration.

But for security or any other reasons still you may store configuration in some files or in database, and then teach your application to read that configuration data and register remoting types inside of your code if you wish. You may want to check MSDN to get more details on. NET Remoting configuration in code. There are 3 types of activation of remote objects: 2 types of Server Side Activation and 1 type of Client Side Activation:.

Nothing happens on a Server when you "create" instance in your Client application. Server acts only when Client application invokes first method of remote object. Even if you create several objects in Client application, still they use the same single object from Server application. So, it does not matter how many Client applications are running. Every method call from any Client application has this life-cycle:. So, now the remote object is available for Garbage Collection.

Client application has full control over this remote object and does NOT share it with other Client applications. Also, if you create 2 or more remote objects in your Client application - yes, there will be created the exact number of remote objects in Server application.

Remote objects, in turn, must be publicly available and bound to a given channel. I'll come back to this point later on. A channel is the element in the. NET Remoting architecture that physically moves bytes from one endpoint to the other. A channel takes a stream of bytes, creates a package according to a particular protocol, and routes it to the final destination across remoting boundaries.

A channel object listens for incoming messages and sends outbound messages. In both cases, the messages it handles can be made of packets written for a variety of protocols. In programming terms, a channel is a.

NET class that implements the IChannel interface. TcpChannel uses a binary formatter to serialize data to a binary stream and transport it to the target object using the TCP protocol. The server object publishes the list of supported channels and, based on this list, the client decides how to actually perform the call. Servers must register at least one channel.

Channels are registered on a per-AppDomain basis and must have unique names in that context. However, on any physical machine only one channel can listen to a given port. In other words, even though channels are AppDomain-specific, you can't have more than one channel registered to work on a given port on a given machine at one time.

Figure 3 details the steps that take a method request down to the server. Let's review what really happens when the execution of a remote method is required, noting that I still owe you several details about the settings that are necessary to enable the client to call into remote servers. A client enabled to make remote calls on a range of objects creates an instance of the desired class using the language-specific operator for instantiation.

As an alternative, it can use the system-provided Activator object. For example, consider the following fragment:. When this code compiles, any calls to RemoteObject are resolved through an external reference added to the project much as you would with Web references.

The underlying code that actually handles method invocation on RemoteObject is an instance of RealProxy, the abstract class that provides base functionality for.

NET Remoting proxies. The proxy works as if it were an object of the same class as the remote object. IMessage has just one property: a dictionary called Properties. The collection of information about the method call is then passed to the proxy's Invoke method. The proxy knows about the channel that the client application has chosen to carry the conversation out. So it delegates Invoke to open the channel and sends data to the remote server.

Opening a channel, though, is just an abstract representation of what really happens. First, the proxy creates an instance of the channel object and begins traversing its sink chain. Both inbound and outbound messages pass through a sequence of channel sinks that actually implement all of the core channel functionality.

The chain normally contains at least two standard sinks that open and close the chain: the formatter sink and the transportation sink. In between the two, programmers can define as many custom sinks as needed.

The stream is then passed down through any custom sinks you may have registered and finally reaches the client transport sink. At this point, the content of the message is sent out towards the destination port.

So who's listening on the server on the specified port? NET remote object must have a host application listening to all the ports supported by the object. Unlike clients, remote objects do not hold channels but declare which ones they plan to support. The object-specific host application receives the inbound message and makes it go up through the server-side sink chain. The first sink to get a handle to the message is the transport sink that actually receives the packets. Custom sinks then get their turn and, finally, the formatter sink rebuilds the original message.

At this point, the host application for the server AppDomain has all the information it needs to execute the call. It looks for the assembly in the remote object's configuration file, instantiates the object, and invokes the method.

The object identification and activation policy deserves more attention, and I'll discuss it shortly. Any return value follows the reverse path and moves from the server to the client in a way that is nearly identical to a client-to-server method call. The formatter sinks are of two basic types: SoapFormatter and BinaryFormatter.

The host app designates the server classes that will be registered to service any incoming call and, along with it, what protocol, port, and name must be used to call the service.

All this data is stored in the host application's configuration file. Other important pieces of information that you'll find there are the object activation and lifetime policies. An instance of an MBR remote class can be activated by either the server or client. Server-activated objects are created by the server only when the client invokes the first method through the local proxy.

By contrast, client-activated objects are created on the server as soon as the client calls New or the Activator object. In addition, server-activated objects can be declared as Singleton or SingleCall objects. A Singleton object has exactly one instance to serve all possible clients. A SingleCall object requires that each incoming call is served by a new instance.

When the client instantiates a server-activated object using new or any other equivalent technique, only the local proxy is actually created. The proxy is made ready for use, but nothing has happened on the server yet. The message for the server is built and forwarded only when the client invokes the first method on that instance of the object. What happens next on the server AppDomain? If the object is registered as a singleton, then the host application attempts to locate the global running instance of the object.

If such an instance exists, the request for execution is processed. Otherwise, the host creates the unique global instance of the remote server and forwards the request to it. What happens if two requests arrive at the same time?

The remoting subsystem provides for them to be automatically serviced by distinct threads. This requires singleton objects to be thread-safe.

This is not a mandatory programming rule, but more of a practical guideline for real-world scenarios. If the object is expected to work as a SingleCall server, then the host simply creates a new instance of the object, executes the method, and routes any return values back to the client. Let's go over some pros and cons for all of these options. Server-activated objects are more efficient and flexible because they give you a chance to control the activation process and implement a laxer policy for instantiation.

On the other hand, if the server object has a nondefault constructor that takes arguments, you can only use it through client activation. The reason for this difference is that for server-activated objects the instantation of the proxy and the actual object occurs at different times so the host application defaults to the standard constructor.

Server-activated objects have two working modes. You can have one instance to service all calls from all clients or one instance for each call. In the latter case, each method call causes the host application to instantiate the object, execute the method, and return. After that, the object instance is left to the garbage collector. Though not completely impossible, preserving state from one call to the next is a bit impractical for SingleCall objects.

In this case, the lifetime of the object instance is short and barely covers the duration of the method call. For singleton objects, state management is possible but must be coded in the body of the object in much the same way as you can do with ASP and ASP. NET Web Services. The idea is that you use a shared cache that all clients can access, unless you invent some sort of filtering mechanism.

Figure 4 lists a comprehensive summary of the features and working modes available for MBR remote objects. If you use client-activated objects, the object's activity follows different guidelines that fall somewhere between the two previous options. Basically, each client-activated instance of a remote class has a mapping with a particular client. The relationship is established upon creation—when the client calls New. The duration of the object's lifetime is subject to other rules that I'll discuss in a moment.

Since each client holds its own personal instance of the remote class, persisting state is straightforward and does not require any special coding or other contrivance. With the sole exception of server-activated SingleCall objects, the object's lifetime is managed by a new module called the lease manager. As mentioned earlier, a SingleCall object has a very short lifetime which is managed automatically by the CLR.

As soon as the method returns, the object goes out of scope and becomes ready for the garbage collector. For singleton and client-activated objects, you need to count object references to determine when it's time to destroy them. In COM, this issue was solved by implementing reference counting.

NET Remoting, the lease manager working on a per-AppDomain basis allows objects to be released even though clients still hold a reference to them. Let's quickly review the trade-offs of the two approaches to understand the rationale behind the change. Reference counting would require clients, including distributed clients, to communicate with the server each time they connect or disconnect. The object maintains the number of currently active client instances, and when the count goes to zero the object destroys itself.

On an unreliable network, chances are good that some object's reference count may never go to zero. The idea behind leasing is that each instance is leased to the client for a given amount of time fixed by the manager. The lease starts when the object is created. By default, each singleton or client-activated object is given a five minute lease. When the interval expires, the object is marked for deletion. During the lifetime, though, any processed client call resets the lease time to a fixed value by default, two minutes , increasing or decreasing the overall lease time as needed.

Note that the leasing is exclusively managed on the server and doesn't require additional network traffic, aside from that needed for normal method execution. The initial lease time and the renewal period can be set both programmatically and declaratively. Another tool that. NET Remoting uses to control the object's lifetime is called sponsorship.

Both client and server objects can register with the AppDomain's lease manager to act as sponsors of a particular object. When the lease of an object expires, prior to releasing the reference the remoting infrastructure gives sponsors a chance to renew the lease. By implementing sponsors, you can control the lifetime of objects based on logical criteria rather than raw ticks of the clock.

It's clear from this discussion of leasing that nothing can guarantee that clients will always find their server objects up and running. When a client attempts to access a server that is no longer available, a RemotingException exception is thrown. One way to resolve the exception is to create a new instance of the remote object and repeat the operation that failed.

Like conflicts in ADO. NET batch update, remoting exceptions require applications to support tailor-made, context-specific coding. It's interesting to note that all creation and working modes discussed so far don't strictly require you to code client-activated objects differently from, say, other objects destined to work as singletons. All options can be set declaratively and, at least in theory, each object can be configured to work in different ways by simply changing a few entries in the server's config file.

However, although intriguing as a possibility, such duality is not realistic in practice because a real-world object might need to delve into the specific features of a given working mode. In other words, you carefully choose the configuration options for your remote object and then stick to those as long as the user's requirements are stable.

For example, a singleton object might need to implement a state management engine for its own purposes. At a later time, if you set this object up to work as SingleCall or client-activated, such an engine becomes redundant, to say the least.

How do you write a remotable object—a. NET class that can be instantiated from external AppDomains? Server-activated objects Listing The examples in this chapter were initially coded using Visual Studio.

NET Beta2. Configure behaves differently in the release candidate. The release candidate, however, threw a "File Not Found" exception. This was unexpected behavior for an assembly in the GAC.

Figure Don't be misled. Conclusion Hope this article would have helped you in understanding. See other articles on the website on. NET and C. View All. C Curator Updated date Sep 29, The book is geared toward the intermediate programmer, but contains enough material to satisfy the advanced developer. Next Recommended Reading. Net Core 6. Create A.