Ken Kolda
9/13/2004 3:35:00 PM
"Jay Callas" <JayCallas@hotmail.com> wrote in message
news:ue7okxDmEHA.2380@TK2MSFTNGP14.phx.gbl...
>
> I need to provide two-way communication between the launcher and each
> instance of the viewer. (I would also love communcation between viwers,
but
> could just use the launcher as a relayer.) Types of information passed
back
> and forth would be config settings, symbol subscription requests,
start/stop
> requests, new business object creation requests, etc.
>
> Is remoting the answer to this two-way communication?
Remoting could certainly be a way to do this. I would imagine your launcher
would act as the remoting server and, each time it launched a viewer, it
would pass it as a command line argument the port on which it is receiving
remoting requests (i.e. on which you registered the TcpChannel). You'll need
to do this to support terminal services since you could have multiple
launcher processes running concurrently which can't all listen on the same
port.
The viewer would then user Activator.GetObject() to fetch some server object
from the launcher and they'd communicate back and forth from there.
Another, cheesier alternative which may satisfy your needs depending on what
kinds of messages you have to send back and forth, is to use the standard in
and out of the viewer process for messaging. This would really only be
appropriate if all of your messages are one-way (i.e. don't require a
response from the receiver). If you need two-way messaging (i.e. actual
remote object calls), stick with remoting.
> Would I create a singleton launcher?
By singletone here I assume you mean an app for which only one instance can
be running at a time. In this case, I'd say no -- there's really no need. If
the launcher passed the necessary channel info to its viewers, then they
will communicate only with it. So, multiple launcher/viewer sets could
coexist without a problem.
> Should I be looking at creating different AppDomains? I
> have read that communications between different AppDomains in the same
> process is faster than communications between different process. (Problem
> with that is the single process. I guess that could crash and take
> everything down.)
>
Using remoting between AppDomains in a single process should be faster.
Whether that really matters or not depends on how much data you're pumping
between the launcher and viewer. If you're just passing small bit of info
back and forth, I wouldn't worry about this performance difference.
As for process isolation, the two AppDomains should, ideally, run mostly
independently. You could start up your viewers in AppDomains inside the same
process as the Launcher and, ideally, if the viewer crashes, only that
AppDomain is affected. However, there are two kinds of crash: one which is
caused by an unhandled exception your code and one which is caused by .NET
performing an illegal operation and crashing. Using AppDomains instead of
separate processes protects you against the first type of crash but not the
latter.
> To take this further. What would happen if I wanted to run this
application
> on a terminal server? Multiple traders each with their own launcher and
set
> of viewers? I would guess that making the launcher a singleton would keep
> that from happening.
>
As I mentioned above, I wouldn't worry about trying to prevent multiple
instances of your app. I don't see that it's necessary or advantageous.
Regards -
Ken