Suggestions for interprocess communication.

[Mufasa]

I have a set of programs that runs on a single machine that need to talk to
each other. I am currently using Message Queueing and that works fine. The
problem is these programs get installed on machines that are part of a
customer's network and some of our customer's don't allow Message Queueing.

So I need to come up with another method which is light weight, and won't be
blocked by security privileges.

Sounds like something like Names Pipes would work right?

Well I would also ideally like it so that if the 'server' isn't there, the
message get's queued somewhere.

So this means that I am essentially writing my own version of Message
Queueing (oh bother!)

But if I am going to go through this process of sending the stuff through
Named Pipes and saving a file if the server isn't there, why not just do
communication through (perish the thought!) files.

Each 'server' would look for files in a specified place with a specified
naming format. Each 'client' would write to that specified location.

The programs are currently all Window's Applications but soon we will be
converting most of them to services. Don't know if that makes any
difference.

It's ugly. It's not very elegant. But it would work.

Anybody have any suggestions/thoughts?

TIA - Jeff.

 

[Nicholas Paldino [.NET/C# MVP]]

Mufasa,

Honestly, make installing MSMQ a requirement, and make sure you lock it
down when they allow it. Doing all of this is just reinventing the wheel,
and that's never a good thing.

 

[Mufasa]

We've tried to make MSMQ required. We've told people it's required. And yet
we get customers who call and say the programs don't work and you find out
they haven't installed MSMQ and when they attempt to install it they can't.
So IT needs to get involved and that causes all kinds of grief.

So that's not really an option.

M.

Mufasa,

Honestly, make installing MSMQ a requirement, and make sure you lock it
down when they allow it. Doing all of this is just reinventing the wheel,
and that's never a good thing.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

I have a set of programs that runs on a single machine that need to talk
to each other. I am currently using Message Queueing and that works fine.
The problem is these programs get installed on machines that are part of a
customer's network and some of our customer's don't allow Message
Queueing.

So I need to come up with another method which is light weight, and won't
be blocked by security privileges.

Sounds like something like Names Pipes would work right?

Well I would also ideally like it so that if the 'server' isn't there,
the message get's queued somewhere.

So this means that I am essentially writing my own version of Message
Queueing (oh bother!)

But if I am going to go through this process of sending the stuff through
Named Pipes and saving a file if the server isn't there, why not just do
communication through (perish the thought!) files.

Each 'server' would look for files in a specified place with a specified
naming format. Each 'client' would write to that specified location.

The programs are currently all Window's Applications but soon we will be
converting most of them to services. Don't know if that makes any
difference.

It's ugly. It's not very elegant. But it would work.

Anybody have any suggestions/thoughts?

TIA - Jeff.

 

[not_a_commie]

Use the named pipe classes in .Net 3.5.