The Remoting channels are objects in the System.Runtine.Remoting
namespace that transport messages between applications across remoting
boundaries such as application domains, processes and computers in the
peer-to-peer manner. The channel is plug-in between the server and client side.
From the abstract point of view, the channel represents a logical connectivity
between two points. The point which listening inbound messages is called
endpoint and it is a logical address of the remote object, knew as URI
(uniform resource identifier). This connectivity is full transparent to the CLR
and "understandable" for open protocol design pattern.

The Remoting namespace includes an implementation of two channels: httpand tcp represented as standard channels. In this article I will
show you how to build and use the custom channel using the System.Messaging
namespace classes to implement the MSMQ channel for Remoting purpose. Before
than we will go to its implementation details, let's start it with usage and
configuration issue. I am assuming that you have a knowledge of the .Net
Remoting.

The Remoting object has no special
requirements to handle the custom remoting channel. It's a full transparently
without any knowledge who and how the messages are transferring. So, we can
administratively switch the channel (endpoint) any time, based on the
application environment.

The situation on the client side is slightly different. The sender needs to
know an URI address (endpoint) of the Remoting object for its activation, see
the following code snippet:

This address can be either hard coded or retrieved from the config file.
Using the config file is more flexible. That's all differences on the client
side. Note that this issue is the same when the application is using two
standard channels (http, tcp).

Each side of the connectivity has own custom properties to configure a channel end in the
properly way.

idspecifies an unique name of the channel that can be used
when referring to it (e.g. id="msmq")

typeis a full name of the channel that will be loaded (e.g. type="RKiss.MSMQChannelLib.MSMQReceiver, MSMQChannelLib"
means a MSMQReceiver class in the assembly MSMQChannelLib), that's why
assembly has to be installed into the GAC

ref is the channel template being referenced (e.g. ref="msmq")

name specifies the name of the channel. Each channel has an
unique name which is used for properly message routing (e.g. name="MyChannel").
Default name is msmq.

priority specifies a preference for the channel. The default
value is 1. Higher numbers mean higher priority. So the messages are queued
based on this number.

listener specifies a path of the existing queue for inbound messages
(MethodCall message). This is a custom channel property. Its format is
corresponding with the MSMQ specification. Note that the listener and remote
object should be located on the same machine (local queue). The default path
is ".\ReqChannel".

respond specifies a path of the existing queue (respond
queue) for a ReturnMessage from the Receiver Channel. This is a
custom channel property. The default path is ".\RspChannel".

admin specifies a path of the existing queue to collect
timed messages from the listener and respond queues. This is a
option custom channel property. If this property is not used, the timed
messages are not collected. The default value is null.

timeout specifies a time in seconds for MethodCall
and ReturnMessage messages to be received. The default value is
60 seconds. The infinite timeout can be setup using the value -1.

Based on the above, the server and client channels can be configured as is
shown in the following pictures:

The following picture shows another example of the server channel to configure two
msmq channels listening on the local queue with the name ReqChannel.
Their priority have a value 20. Each channel has own unique name such as
msmq_1 rsp. msmq_2.

The client channel is represented by the MSMQSender class located in the
MSMQChannelLib asssembly. Its properties are: respond queue is ".\RspChannel"
, administration queue is ".\RspChannel", outbound
message and its return message are timed to be received within 30 seconds and
the channel priority is 10.

The MSMQ Remoting channel requires an existing queue on the sender and receiver
sides. The administration queue on the sender side is an option.
These two queues have to be transactional for the channel using on the
Enterprise Network to guarantee delivering a message (one only) to the
destination queue. There is a special situation - calling a remoting OneWay
attributed method. In this case, there is no return message and the call has a
fire&forget design pattern.

The Custom Remoting MSMQ channel concept is based on the MSMQ technology,
where queues are accessible on the Enterprise Network from anywhere. The
remoting channel using a message passing design pattern between a remote object
and its consumer. It's based on the two parts: Sender and
Receiver with an interface contract ICannelSender resp.
IChannelReceiver from the System.Runtime.Remoting.Channels namespace.
Implementation of these two interfaces allows plug-in a particular channel and
passing a IMessage object through. Note that IMessage object contains a
communication data sent between cooperating message sinks controlled by the
Runtime.Remoting.Messaging namespace classes.

The IChannelSender interface allows to call a channel synchronously or
asynchronously using the delegate design pattern. Let's look at more details for
both options:

The following picture shows an IMessage object flows through the MSMQ
remoting channel in the sync manner.

The IMessage object is passed to the Message Sink calling the
IChannel.Sender.SyncProcessMessage functionwhere is serialized
by a BinaryMessageFormater into the body of the message queue.
Before sending a message to the queue, its properties are setup for a callback
(respond) message. Each an outgoing MSMQ message has own unique Id, which this
design is using as a key to pick-up a callback message from the Respond queue.
So, the Sender is waiting for this message within the specified timeout limit.
Note, that we are blocking the caller, that's a sync call. When the return message
has been received, it's body is de-serialized into the IMessage object
and send it back to our caller as a result of the method call. In the case of
the timeout, the return value is null.

The Receiver side is an event driven class derived from the
IChannelReceiver. It is listening on the Request queue for inbound
messages. When message has been received, the listener thread spawn thread to
the delegate worker. Its responsibility is a de-serializing incoming message
into the IMessage object and then synchronously dispatching this
object to the server - side chain based on the endpoint (URI) address, using
the ChannelServices.SyncDispatchMessage function. This function returns
an IMessage object, which it can be serialized into the callback message body stream. As I
mentioned earlier, the incoming message has been prepared by its sender for a
callback purpose such as a respond queue, acknowledge type, etc., so the
receiver just updating the message correlation Id (a message cookie) by the
message id and send it to the Respond queue. All this process is implemented
implicitly and for a receiver is a full transparently.

Note that the Receiver can handle also one special case - calling the OneWay
attributed remoting method. In this case, the return IMessage object
reference is null and it is done immediately without processing the
remote method body and also there is no respond message to the sender. However,
the client knows (from the assembly metadata) that this message has to be
handled asynchronously without any respond. It's very important to understand
the behaviour of this attribute which has a fire&forget design pattern. The
client in this case doesn't have any information about the remoting method processing such as
an error exceptions.

The following picture shows an IMessage object flows through the MSMQ
remoting channel in the async manner.

To process the IMessage object through channel in the asynchronously
manner is decided by the client. The ISenderChannel supports an
AsyncProcessMessage function which required two arguments: IMessage
and IMessageSink objects. As you can see the Sender is divided into two
isolated parts and the Receiver is identically to the above Sync Call design.

Request part is flowing based on the IMessageSink object
value. In the null case (which it means the OneWay Method Call), the
IMessage object is serialized into the message body stream and send it to
the Request queue. There is no process of waiting for respond message, the
call is immediately returned to the caller with an IMessageCtrl value
equal null. On the other hand, when the IMessageSink object is
valid, the both arguments are delegated to the worker thread using the
BeginInvoke/EndInvoke design pattern and the call is immediately returned to
the caller with an IMessageCtrl value equal null. Note that this
solution doesn't have a possibility to abort an active async call using the
IMessageCtrl object.

Respond part is running in the background and it's very simply. The
first, it is calling the SyncProcessMessage functionto obtain the
IMessage objectfrom the remote method in the synchronously
manner and then updating the AsyncResult object state with this value. Note
that this is a very cool design pattern between the caller (client) and
background process, that's why an async call is passing an IMessageSink
object (replySink). Calling the replySink.SyncProcessMessage function
two things are going to be performed:

updating an AsyncResult shared object state by
the IMessage object state (Return Message)

setting an AsyncResult.ManualResetEvent object
to notify a client that the result of the async call can be retrieved using the
EndInvoke function.

The MSMQ Custom Remoting Channel implementation using the System.Messaging
namespace classes to communicate with the MSMQ, System.Runtime.Remoting
namespace classes to integrated channel into the remoting mechanism and
System.Runtime.Serialization namespace classes to serialize/de-serialize
messages through the channel. All implementation is built by managed code and
package into one assembly named as MSMQChannelLib.

The MSMQChannelLib contains a functionality of the MSMQ remoting
channel for server and client side. Its assembly is required to be installed
into the GAC at the server and client side. Before using the MSMQ
remoting channel, the channel has to be registered either programmatically or
administratively. Note that there is no requirement to register a server channel
in prior to client channel registration, that's the feature of the loosely
coupled connectivity of the MSMQ. However, the MSMQ remoting channel requires in
prior of the registration that the Request respectively Respond queue is existed.

As I mentioned earlier this assembly contains two major classes. The
following are some details how they been implemented:

to check if the specified url can be handled by this channel. If the channel
name is not matching with the url field address, the null is returned. The
walking process is repeated through all registered channels until a successful
match is found, otherwise the error exception is thrown. In the successful case,
the MSMQMessageSink class is instated and its reference is returned to
the caller.

The MSMQMessageSink is derived class from the IMessageSink and
IDictionary interfaces. When a method call is made on the proxy, the
remoting infrastructure passing IMessage object to this class using one
of the following ways:

This is a synchronously invoking a remote method with a waiting for its
return message within a specified time. As you can see the above code snippet,
the outbound message is created and configured for its respond from the endpoint
and then sent to the transactional queue. After this, the helper
function ReceiveReturnMessage is calledto wait for a message with a
specified correlation id on the Respond queue. This function returning a
reference to IMessage object, which it is returned back to the remoting
infrastructure as a ReturnMessage. Note that caller is blocked during the
process of the waiting for the respond message.

If the client wants to be pre-emptive with the remoting object, the process of
the invoking a remote method needs to be implemented by BeginInvoke/EndInvoke
design technique. In this case the following method is called:

This function has a fire&forget design pattern implemented in two ways:
either sending an outbound message without waiting for its respond (OneWay
option) or delegating this call to the worker thread. In the both situation, the
call is immediately return back to the remoting infrastructure. The following
code snippet shows that:

and here is a background process of the asynchronously call. This thread
actually call remote method synchronously and after that it is using a
replySink to update AsyncResult object state included setting its
ManualResetEvent object. After this work the worker thread is going to be
terminated itself.

This is a derived class from the IChannelReceiver interface from the
System.Runtime.Remoting.Channels namespace. The class has several
constructors to config the receiver channel programmatically and one constructor
for administratively configuration using the config file. Their design
implementation is similarly to the MSMQSender.

The implementation of the MSMQReceiver class is simpler than
MSMQSender. The listener run an endless loop in the background thread which
is blocked by m_InQueue.Receive() function. When message arrived into the
queue, this function will retrieve this message and delegate it to the worker
thread in the fire&forget fashion using the BeginInvoke design pattern. The
above is shown in the following code snippet:

The primary goal of the above function is to dispatch an arrived IMessage
object to the remoting infrastructure in the synchronously manner. The
"dispatcher" will
return back a return message represented by IMessage object. If the
return value is null than nothing to do and thread will be exited, that's
the situation of the OneWay attributed remote method. In the other hand, the
IMessage object is serialized into the message body and send it back to the
Respond queue. Note that setting a message CorrelationId by its Id
is very important for the Sender side - this is a callback cookie, which the
Sender waiting for it.

<p2> The server and client are also very straightforward and simply.
Before starting the test the following assemblies have to be installed in the
GAC:

MSMQCannelLib on the both machine

RemoteInterface on the both machine

RemoteObject on the server machine

also you must create manually the following MSMQ queues:

ReqChannel queue on the server machine - transactional

RspChannel queue on the client machine - transactional

AdminChannel queue (option)

Note that this test can be run also using only one machine as a server and
client.

After all the above checks, start the server host program and then
client program. The client program will ask you to write a number of
the test loops, just write 10 and press Enter. You will see all
remoting processes how fast running on the server and client console programs.
Note that client is running test for each remote method synchronously and
asynchronously. After all these test loops, press Enter and the client
console will display a test result. It should by 100 for both of them.

You can play more test such as open more server host programs or more client
programs and also you can change a channel configuration in the their config
files.

In this article has been described how to design, implement and plug-in the
MSMQ into the remoting infrastructure. Beside the standard remoting channel such
as http and tcp, the MSMQ remoting channel allows to call a remoting object in
the loosely coupled design pattern, which is very important in the mobile
application. Design and implementation of the Custom Remoting channel using
.Net Framework classes is simple and straightforward for any kind of physical
channel such can be as serial RS232, USB, X25, modem, etc.

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

I have a requirement to create a windows service which will hit the database on a regular interval to check the record count of a table. This service wud be running on a remote server. When ever there is a increment in the record count, the service has to notify the user.

There wud be an application running on the client system which wud accept the message coming from the service and display it as a pop-up on the desktop. Message communication wud always be from server to client only. Server application is a windows service and the client application wud be windows forms.

I was able to create windows service which hits the DB and checks the count. I’m struck up with sending the message to the client system. I’m not sure abt using socket programming v/s Remoting to achieve this task as this is the first time I’m trying this sort of App.

So any kind of info would be of gr8 help. And thanks a lot of ur patience to read this lengthy mail

hello, im going to make a peer to peer appliaction using remoting in which session are made and user join to particular session as in DirectX's API DirectPlay.plz guide me. is remoting is useful for this application or not?

Enter number of test loops: 3
Hit to see a result of the test
The method was called with a Message of an unexpected type
The method was called with a Message of an unexpected type
The method was called with a Message of an unexpected type

sorry for my english
tha path structure of msmq:// is wrong
when you try SyncProcessMessage(IMessage msgReq)
the line m_OutQueue.Send(outMsg, label, mqtx);
send us a exception queue no exist in this DS
or something like that

There are two types of channels that .NET framework provide 1)TCP and 2)HTTP and there are custom channels that u can create using any stream oriented transfer technology like Sockets, Named Pipes and MSMQ.
My question is which channel is suitable in which situation. Can anybody tell me when should i use named pipes channel and when MSMQ.

My opinion is that, in the presence of a timeout, the code is not correct. The first layer detects the timeout and rethrows it (MSMQSender.cs, approximate line 193), but then the second layer captures the message and discards it (MSMQSender.cs, approximate line 241). Consequently the remoting subsystem throws an exception to the client complaining that the message was an unknown type, rather than any form of timeout exception.

I have modified my code to detect this at the first layer and transform it from a MessageQueueException to a RuntimeRemotingTimeout exception, and, at the second layer, to log the exception as normal but then rethrow it.

The code then behaves in a manner which seems more consistent (i.e. one can catch the timeout exception in the client code).

I can provide this code for anyone (including the author) who is interested, although it's a very easy change to do.

I use the format of url: "msmq://./private$/reqchannel/endpoint";
I try also using Direct format: msmq://FormatName:DIRECT=OS:localhost\private$\ReqChannel\endpoint.
Unfortunately, I can not reach the success!
Your comments are welcome because they help me very much!

If your environment is 'Win2003/XP and MSMQ 3.0' you can broadcast a message using the MULTICAST feature of the MSMQ 3.0.

See my new version of the MSMQ Custom Channel [1], where for example,

msmq://FormatName:MULTICAST=234.1.1.1:4455/endpoint

will send a non-transactional message to all clients those are listening for multicast ip address (in this example 234.1.1.4455). Using either the ACK or NACK response message, the sender can handle an exception logic.

I understand that adding messaging increases reliability of a distributed application. However, it is not clear to me that it is making .NET Remoting more reliable. It seems what it is doing is adding the queuing mechanism in the channel with the benefit of relieving the application of desiging in handler threads for the data transfer. This giving the application a somewhat simpler design. The reliability question is really a related question to how MSMQ is designed to work. (I think) Consider the following scenareo:

For a TCP remoting client/server system, if the server is offline and the client tries to make a call on a remote object then an exception is thrown in the client. In a messaging system when a message is sent if the receiver is off line then the message is just queued up until the receiver comes on line. This is how I understand MTS works. When you merge the MSMQ with Remoting, what happens if the server is offline and a message is sent from the client? Is there an exception?

Thanks for the article and code for this MSMQ integration. Also, as per the posts below, do you have any idea when your next version will be ready?

can this be used with muiltiple remote listeners (queue not on same machine as listener) if the code is modified to not use MSMQ transactions on sender and receiver ? One thing I wish MSMQ supported was remote transactional reads, but since it doesn't we don't use transactions. thanks.

First of all, I would like to point you for my new version of the MSMQ Channel with more features.

- You can modified the code to turn off the transactional features in the channel (it's straightforward), but keep in mind. The MSMQ has been optimized for sending a message locally/remotely and receiving only localy. It's a bad practice to use a remoting read (cross the network), which it can create a problem in the production deployment. For more details, please visit the MSDN/MSMQ.