Interprocess communication.

[Mufasa]

So I have have this really cool set of programs that will talk to each other
using Message Queueing. Everything works great. Problem is, this machine,
which acts like a kiosk, is dropped on our customers' network and sometime
their IT department has the network so locked down that they won't allow
Message Queueing. Now we can talk them through enabling this but it's a
royal pain; they have to enable the privileges, get the right passwords,
..... So we want to look in to a way that we can have the machine run without
using Message Queueing to have all the programs talk. I've come up with a
couple of solutions but am looking for guidance:

Remoting. I've never done remoting and don't really understand it. Is this
something that can be blocked by policies?

Shared Memory: This is essentially message queueing without the ability to
have multiple messages waiting in the queue.

Named Pipes/TCPIP - this seems like way overkill. And if I were an IT
department I wouldn't think this is very secure.

Files: (yech!) Write each message to a file on the hard drive/RAM disk and
have the programs read them in order. (Archaic but should work.) We have
write privileges to the hard drive (have to have that or this whole thing
doesn't work).


Can anybody make any suggestions and include why they made the suggestion?

Remember we would like to have it such that you put the machine on the
network, turn it on and it just works.

TIA - Jeff.

 

[Peter Bromberg [C# MVP]]

Remoting. I've never done remoting and don't really understand it. Is this
something that can be blocked by policies?

Remoting is now WCF - Windows Communications Foundation. You can block
virtually anything if your policy is restrictive enough. It really
depends on the transport channel / protocol - which could be TCP, named
Pipes, HTTP, etc.

Shared Memory: This is essentially message queueing without the ability to
have multiple messages waiting in the queue.

No, shared memory is not essentially Message Queueing; it is using a file as
a backing store which multiple clients can access at the same time.
Typically however, this will only work on the same machine.

Named Pipes/TCPIP - this seems like way overkill. And if I were an IT
department I wouldn't think this is very secure.

Named Pipes and TCP can both be very secure - it just depends on what level
of authentication / encryption is employed.

Files: (yech!) Write each message to a file on the hard drive/RAM disk and
have the programs read them in order. (Archaic but should work.) We have
write privileges to the hard drive (have to have that or this whole thing
doesn't work).

Yes, Files are ugly.

Can anybody make any suggestions and include why they made the suggestion?

Yes. use a webservice. each client can send their "Stuff" to the webservice
which can store it or process it,
and each client can contact the webservice to update whatever it needs.
Webservices work over HTTP via port 80,
which is the last thing a paranoid network admin would close up.

Peter

 

[Mufasa]

Thanks for the suggestions.

All of these programs run on the same machine so going outside the machine
isn't a concern.

You talk about webservices and I've used them extensively but I don't see
how they could work here for most of the stuff. Aren't web services passive?
They can't instigate some kind of action. I would need to do things like
every 15 minutes check with our home server to see if there are any changes
it needs to be aware. And also every 5 minutes tell the 'software watchdog'
that it's still alive.

It sounds like TCP/IP is the way to go though.

Thanks for the help.

Jeff.

 

[Michael Justin]

You talk about webservices and I've used them extensively but I don't see
how they could work here for most of the stuff. Aren't web services passive?
They can't instigate some kind of action. I would need to do things like
every 15 minutes check with our home server to see if there are any changes
it needs to be aware. And also every 5 minutes tell the 'software watchdog'
that it's still alive.

Message Oriented Middleware might be an option too:

http://en.wikipedia.org/wiki/Message-oriented_middleware

There are many very good (including Open Source implementations) and
most of them support .NET, so you can have active and passive components
on the client. The message broker can notify the client about new
information, and the client can send its status back to the server any time.

I wrote Delphi client libraries for some message brokers. MOM solutions
are easy to implement and very useful in medium and large scale systems.
They are not well known in the developer community yet but with service
oriented architecture they will be more common soon.

Hope this helps(tm)

 

[Mufasa]

It looks like I'm going to do named pipes. Can anybody point me to code
samples (or a class ) that does the pipes for me?

The examples I've seen are .Net 2.0 and are making WinAPI calls.

I'll be using .Net 2.0.

TIA - Jeff.

 

[Dan]

Hi, I also have the same problem.
Have you finalize your work in Named Pipes?
i came across with this two..it may help..
http://msdn.microsoft.com/en-us/library/bb546102.aspx

http://www.eggheadcafe.com/articles/20060404.asp

For me my problem is to know which IPC will be the fastest?
(Pipes, .Net Remoting, WM_COPYDATA, Sockets)
What made you decide to use Pipes?

TIA - Dan

 

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

Dan,

It's impossible to say which one is fastest, unless you give the details
of the messaging pattern, the payload, etc, etc.

Also, you might not have the need for something that is the fastest,
depending on what your goals are. You might find that using named pipes in
WCF is fast enough, while making development easier, which is better than
something that you have to maintain yourself.

In the end, the trade off is something that you will have to decide on.