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
