.NET Remoting & RTD

[Nick]

Hi there,

Can anyone tell me what RTD is? And can it be used for simple
interprocess communication? I am just interested in sending strings to a
previous instance.

I am currently using .NET Remoting via the "Windows Application
Framework", but unfortunately McAfee's crappy firewall is capable of
blocking the internal connection and causing any application that utilises
it to crash, it doesn't even raise an unhandled exception via the
"UnhandledException" event.

I had originally taken the .NET Remoting route a while back now as I
read that it was much preferable than DDE, which apparently now is a
deprecated technology.

Anyone got any advice on this? Thanks in advance.

Nick.

 

[Guest]

Since you mentioned the "Application Framework", I'm assuming you're using
2005. If you want to communicate with a previous instance, you can check out
the System.Runtime.Remoting.Channels.Ipc namespace. You get all the benefits
of .NET Remoting without having to go through a network card to do it. It's
only for communicating with a process on the same machine.

http://msdn2.microsoft.com/en-us/library/system.runtime.remoting.channels.ipc.aspx

 

[NickP]

Hey Dave,

Thanks a bunch, I didn't know this one existed. Great stuff, any ideas
why the Application Framework doesn't use this? It uses TCP unfortunately,
hence the firewall issues :-(

Nick.

 

[Guest]

Probably because IPC is limited to communication inside the same machine.
It's faster, but far less flexible. Going over the TCP/IP stack gives you
the flexibility of talking with another app on the same machine or on a
remote.

Some of the services I've written open up a TCP port so a management app can
talk to it. The service is used on workstations, but since I'm doing the
Remoting over TCP, I have the option of connecting my management app to any
machine and administering each service remotely.

 

[NickP]

Hi Dave,

I understand what your saying but that's hardly relevant of the
application framework, as far as I am aware if only uses the communication
channel to pass arguments from a secondary instance does it not? Your code
is all custom made for the tasks that you mentioned here isn't it? I see
the benefit of talking across the network of course but just for multiple
instances it hardle seems worth it...

Or am I missing something?

Nick.

 

[Guest]

I don't know what their reasoning was, but from what I can make an educated
guess at is they used TCP by default because of it's flexibility. One
solution that works for communicating with remote processes acrossed
AppDomain boundries and network boundries, without having to change anything
in the code.