Anytime an object lives in another process (whether it's on the local
machine or somewhere else on a network), remoting is involved because two
processes can't access each-other's memory natively.
In .NET, the remoting infrastructure can detect two scenarios: (1) remote
objects in the same process (but maybe in different app domains), and (2)
remote objects in different process
COM was able to detect a third scenario, which was, a remote object in
another process, but on the same computer. When this happened, COM was able
to marshal the calls around without physically using networking and sockets.
In .NET, anytime an object lives in another process, you are going to have
to resort to networking/socket calls (TCP or HTTP) if you use the default
remoting channels.
Luckily, remoting channels are extensible and you can make your own. A while
back, I created a custom channel that used windowless message pumps on both
sides to signal incoming messages, and serialized the message data to a
memory mapped file. Normally, the binary tcp channel uses a TCP socket to
signal and transmit messages, and serializes the message data to the network
stream. My custom channel bypassed the need to use sockets, and worked a bit
more like the COM scenario. If you wanted to switch the objects out to
another machine, then you could simply configure the TCP remoting channel
instead, and it required no code to swap channel types. I highly suggest
getting the MS Press Remoting book, and checking out Ingo Rammer's site.
Of course, all this might be somewhat overkill depending on what you are
doing. If all you want is to share simple types across two processes on the
same machine, you can try writing them out to a memory mapped file from one
process and reading it from the same memory mapped file on the other
process.
As a side note, Indigo (the next generation infrastructer for "remoting" if
you will) which will ship for both XP and Longhorn later this year or
sometime next year (by all indications... don't quote me on that - even the
MS people don't have a hard date) will simplify this stuff. I hesitate to
talk too much about Indigo because it's still in development and some
features and specs aren't public yet, but I do recommend you start becoming
familiar with it.
-Rob Teixeira [MVP]
