General MSMQ and C# question

[Claudia]

Hi all...

I'm working on a project that uses MSMQ as its core for inter-process
communication. At the moment there is a single process that listens for
inbound TCP-based messages on a socket, and when something is received it
gets packaged up and sent to an MSMQ queue for further processing.

The process on the listening end of this queue will process the message and
either (a) send a response to the originator, or, (b) send an "internal"
message to another process for further work.

(a) is achieved by sending to a general "outbound" MSMQ queue which then
responds via TCP to the originator of the message.
(b) is achieved by sending the message onto the relevant queue for the
process to do the further work...
(I hope i haven't lost anyone by now! ;) )

Now, if I have, say, 40 processors, that means 40 queues (plus the general
"outbound" queue). The single TCP-listener process will have a hashtable of
40 MessageQueue objects, each ready to send to the appropriate worker
process.

Each worker process will listen to its own queue and send to the general
"outbound" queue.

For inter-process communications, each worker process has a hashtable of 39
MessageQueue objects, each ready to send to any of the other worker
processes...

I'm not sure if this is the best way of doing this... any suggestions???

Thanks!
Claudia

[Peter Bromberg [C# MVP]]

Claudia,
From your description it isn't entirely clear why you feel you need such a
complicated (and potentially resource-intensive) setup. Wouldn't it be
possible to have a single MessageQueue and use something like - for example
-- the Message label to tell the processor which process it is destined for?
Then you could have a sort of "broker" class that would read the message
label and based on a simple switch statement, send it on to the respective
class to handle that specific processing.

if each message is derived from an Interface that has a generic "Execute"
method, all you would need to do is read out the payload and deserialize it
to an instance of the Interface and call the method...

Just my 2 cents.
Peter

--
Co-founder, Eggheadcafe.com developer portal:
http://www.eggheadcafe.com
UnBlog:
http://petesbloggerama.blogspot.com


"Claudia" wrote:

Hi all...

I'm working on a project that uses MSMQ as its core for inter-process
communication. At the moment there is a single process that listens for
inbound TCP-based messages on a socket, and when something is received it
gets packaged up and sent to an MSMQ queue for further processing.

The process on the listening end of this queue will process the message and
either (a) send a response to the originator, or, (b) send an "internal"
message to another process for further work.

(a) is achieved by sending to a general "outbound" MSMQ queue which then
responds via TCP to the originator of the message.
(b) is achieved by sending the message onto the relevant queue for the
process to do the further work...
(I hope i haven't lost anyone by now! ;) )

Now, if I have, say, 40 processors, that means 40 queues (plus the general
"outbound" queue). The single TCP-listener process will have a hashtable of
40 MessageQueue objects, each ready to send to the appropriate worker
process.

Each worker process will listen to its own queue and send to the general
"outbound" queue.

For inter-process communications, each worker process has a hashtable of 39
MessageQueue objects, each ready to send to any of the other worker
processes...

I'm not sure if this is the best way of doing this... any suggestions???

Thanks!
Claudia

[Alvin Bruney - ASP.NET MVP]

Why do you have a TCP listener? It seems to be unnecessary over head. One
approach is to configure the Queue with remote access and send the messages
directly to the queue. Since the queue already implements message
confirmation, you can eliminate that part of your application that is
responsible for notification.

Configure the queue with triggers so that messages that need to be forwarded
on internally are automatically forwarded or handled by the queue framework.
The thing is, you've built a lot of functionality into your applications
that are already robustly implemented in the queue framework.

--
Regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
The Microsoft Office Web Components Black Book with .NET
Now Available @ www.lulu.com/owc
Forth-coming VSTO.NET - Wrox/Wiley 2006
-------------------------------------------------------

"Claudia" <cl************ *************@h otmail.com> wrote in message
news:43******** *************@n ews.zen.co.uk.. .

Hi all...

I'm working on a project that uses MSMQ as its core for inter-process
communication. At the moment there is a single process that listens for
inbound TCP-based messages on a socket, and when something is received it
gets packaged up and sent to an MSMQ queue for further processing.

The process on the listening end of this queue will process the message and either (a) send a response to the originator, or, (b) send an "internal"
message to another process for further work.

(a) is achieved by sending to a general "outbound" MSMQ queue which then
responds via TCP to the originator of the message.
(b) is achieved by sending the message onto the relevant queue for the
process to do the further work...
(I hope i haven't lost anyone by now! ;) )

Now, if I have, say, 40 processors, that means 40 queues (plus the general
"outbound" queue). The single TCP-listener process will have a hashtable of 40 MessageQueue objects, each ready to send to the appropriate worker
process.

Each worker process will listen to its own queue and send to the general
"outbound" queue.

For inter-process communications, each worker process has a hashtable of 39 MessageQueue objects, each ready to send to any of the other worker
processes...

I'm not sure if this is the best way of doing this... any suggestions???

Thanks!
Claudia

[sloan]

http://www.apress.com/book/supplemen...10003&sID=3050

Check the Chapter 8 example.
You could do 1 queue, or maybe 2. Put not >2.

You need to just label each messgae with a machine name.

.....

\firstlevelqueu e
\secondlevelque ue

Send your initial messages to firstlevelqueue .
Create an object like

public class MyObject
private int m_processorNumb er;
public int ProcessorNumber { get { return this.m_processo rNumber;} }
public MyObject (int processorNumber )
{ this.m_processo rNumber = processorNumber ; }

And then you can put an instance of MyObject into the BODY of the Q message.

....

Then you write a Windows Service, which is your "Poller" (aka, polls the
firstlevelqueue every X seconds)

You write your businesslogic to handle your if/else.

The reason I advocate 2 queues...is that it is a little easier ....when you
read the messages from the Q.. and you have to cast them as MyObject.

Check the sample in that zip download (top of this email).

You may have to rewrite it a little if you have 1.1, but you can do this.

I think the example has public class Document....whe re this would become
your MyObject.
...

I think a different N queue for every N processor you have .... is a bad
design.
(aka, 40 processors = 40 queues....)

"Alvin Bruney - ASP.NET MVP" <www.lulu.com/owc> wrote in message
news:eZ******** ******@tk2msftn gp13.phx.gbl...

Why do you have a TCP listener? It seems to be unnecessary over head. One
approach is to configure the Queue with remote access and send the
messages
directly to the queue. Since the queue already implements message
confirmation, you can eliminate that part of your application that is
responsible for notification.

Configure the queue with triggers so that messages that need to be
forwarded
on internally are automatically forwarded or handled by the queue
framework.
The thing is, you've built a lot of functionality into your applications
that are already robustly implemented in the queue framework.

--
Regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
The Microsoft Office Web Components Black Book with .NET
Now Available @ www.lulu.com/owc
Forth-coming VSTO.NET - Wrox/Wiley 2006
-------------------------------------------------------

"Claudia" <cl************ *************@h otmail.com> wrote in message
news:43******** *************@n ews.zen.co.uk.. .

Hi all...

I'm working on a project that uses MSMQ as its core for inter-process
communication. At the moment there is a single process that listens for
inbound TCP-based messages on a socket, and when something is received it
gets packaged up and sent to an MSMQ queue for further processing.

The process on the listening end of this queue will process the message

and

either (a) send a response to the originator, or, (b) send an "internal"
message to another process for further work.

(a) is achieved by sending to a general "outbound" MSMQ queue which then
responds via TCP to the originator of the message.
(b) is achieved by sending the message onto the relevant queue for the
process to do the further work...
(I hope i haven't lost anyone by now! ;) )

Now, if I have, say, 40 processors, that means 40 queues (plus the
general
"outbound" queue). The single TCP-listener process will have a hashtable

of

40 MessageQueue objects, each ready to send to the appropriate worker
process.

Each worker process will listen to its own queue and send to the general
"outbound" queue.

For inter-process communications, each worker process has a hashtable of

39

MessageQueue objects, each ready to send to any of the other worker
processes...

I'm not sure if this is the best way of doing this... any suggestions???

Thanks!
Claudia