Interprocess communication.

  • Thread starter Thread starter Mufasa
  • Start date Start date
M

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.
 
Remoting. I've never done remoting and don't really understand it. Is this
something that can be blocked by policies?
Click to expand...

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.
Click to expand...

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.
Click to expand...

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).
Click to expand...

Yes, Files are ugly.
Can anybody make any suggestions and include why they made the suggestion?
Click to expand...

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
 
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.
 
Mufasa said:
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.
Click to expand...

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)
 
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,

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.
 
Back
Top