471,350 Members | 1,828 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,350 software developers and data experts.

General MSMQ and C# question

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


Dec 8 '05 #1
3 1226
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


Dec 8 '05 #2
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*************************@hotmail.com> wrote in message
news:43*********************@news.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

Dec 8 '05 #3
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.

.....

\firstlevelqueue
\secondlevelqueue

Send your initial messages to firstlevelqueue.
Create an object like

public class MyObject
private int m_processorNumber;
public int ProcessorNumber{ get { return this.m_processorNumber;} }
public MyObject (int processorNumber)
{ this.m_processorNumber = 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....where 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**************@tk2msftngp13.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*************************@hotmail.com> wrote in message
news:43*********************@news.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


Jan 31 '06 #4

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

reply views Thread by Andrew Gordon | last post: by
reply views Thread by Chipster | last post: by
reply views Thread by Rudy | last post: by
2 posts views Thread by Przemo | last post: by
5 posts views Thread by Alex Nitulescu | last post: by
3 posts views Thread by Claudia | last post: by
11 posts views Thread by Jon Davis | last post: by
reply views Thread by XIAOLAOHU | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.