This post will walk you through the implementation of a simple client-server application that establishes remoting communication in two directions while using infrastructure components and templates that extract the common remoting related tasks from the application.
Introduction
Establishing inter-process communication via remoting is pretty straight forward for applications that require one way communication. In those kinds of applications, a client requires to initiate a method execution on a server object, while the server object is stateless and has no way to initiate communication with the client.
Unfortunately, things get pretty messy when clients also need to listen to server events. This requirement turns the table because now the server object needs to be able to initiate method execution on the client objects. Consequently, the server object cannot be stateless because it must hold references to the registered clients, each client object that register to server event should be MarshalByRefObject and its assembly should be referenced by the server.
This post demonstrates how server objects can be made state-full and how clients can register to server events without having to be MarshalByRefObject nor referenced by the server.
Drawbacks
Before going any further, it’s important to understand that the “remote events feature has its drawbacks.
If the client and the server reside in different machines – the guidance is to not use remote events in cases where there are many clients. The main problem is that the server’s default behavior is to dispatch events synchronously, as request time of the results is increased by a magnitude and exceptions are hard to handle. Though events can be raised asynchronously, it is not recommended for reasons such as ThreadPool starvation and possible event lost. Applications that are being designed for scalability should probably use some other mechanism (such as sockets) to get notifications from the server.
What’s left? Use remote events if the clients and the server reside on the same machine or if there are restricted amount of reliable clients. I use it in middle size intranet style applications, there are no more than 3 well known reliable clients.
Two way client/server application
The following client/server applications enable multiple clients to establish two way communication with a single server.
Components
The client includes a “ClientHost” component that requires (and uses) the “IChat” interface which resides in a shared component called ‘RemotingTemplate.Globals’. The server includes a ‘ServerHost’ component that uses the “Library” component which contains the distributed server object which implements the “IChat” interface. The “ServerHost” component utilizes remoting in order to publish the sever object, while the “ClientHost” component utilizes remoting in order to retrieve an automatically generated remote proxy (which also implements the “IChat” interface) through which it will be able to initiate remote invocations on the sever object.
