Brian wrote:
> To clarify my question, the examples I've seen so far have been like
> this:
>
> Server creates a channel exposing Class A.
> Class A contains a handy-dandy method that can multiply two ints.
> Client creates a channel to be able to instantiate a new Class A
> object and call its methods.
You're talking about .NET Remoting?
> But how does Client get a message all the way back to Server?
Well, once the client has instantiated an instance of Class A it has a
proxy to that object. Then all the client does is call a method on the
object proxy.
> I tried creating a client channel in the server itself, but I can't
> make that work. I get an exception saying that there is already a
> registered object for that channel. I also tried creating an instance
> of Class A in the server, but it was a completely separate object
> that did not see messages that the client put into it.
Do you want the server to call methods on the client? If so, then you
need to register a channel on the client to do that. You don't need to
do anything on the server, if the callback to the client is through a
delegate to a client method, or if the client creates a
MarshalByRefObject object and passes that to the server.
> To give some context, I have a Windows service that needs to be
> controlled via a Windows Forms app. As I understand it, to get
> messages to the Windows service, I would create a channel there and
> have the Forms app be the client. But how do I actually retrieve the
> messages from within the service?
I think I understand what you mean. In the service you register a class
to be activated remotely. The client activates an object of that class
and calls its methods. You want these methods to talk to the service,
and want to know how this remoted object talks to the service object
even though they are in the same process.
The problem is that remoting uses threads in the process threadpool, so
the thread that will handle client calls will not be the same as the
thread that runs the service object, so whatever you do, you have to
take inter-thread communication into account. A ReaderWriterLock would
help here.
It all depends on how you are managing state. If the service state is in
a database, then your remoted object can simply access that state
through a database connection.
If the state is maintained in memory, then you will have to take steps
to protect it. I would create a class that has a static member that
gives access to this state. The service object can initialise this
static member when the service starts. The methods of this class needs
to be protected by a ReaderWriterLock so that when one client is writing
data (ie passing data to the service) no other client nor the service
can write data; if no one is trying to write then there will be no lock.
Richard
--
http://www.grimes.demon.co.uk/workshops/fusionWS.htm
http://www.grimes.demon.co.uk/workshops/securityWS.htm
Similar Threads
