----- Original Message ----- From: "Joe Cheng" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, September 07, 2004 7:56 PM Subject: Re: [ADVANCED-DOTNET] Aborting long-running remote calls
> > I want to give the user on the client-side the ability to > > cancel long-running and potentially expensive calls. How can > > I cancel such calls? > > I implemented this by passing a MarshalByRefObject-derived object as a > parameter to the server call. The object has an IsCancelled property on it, > and on the server side, is stored in a ThreadStatic field. > > In the course of doing its work, the server code occasionally polls the > object's (proxied) IsCancelled property. If the value is true, then the > server operation cancels (in my case, by throwing an > OperationCancelledException). > > The benefit of this approach is safety (vs. killing the thread) and > simplicity (all the logic happens in the same [virtual] thread of control), > but it does reverse the client/server relationship when the callback is > made. So this would only work in a situation where the network topology > allows the server to call back to the client (in our application, client and > server are always the same machine). I believe the problems is as follows: If you are able to identify the calling client in the server, I think that a bit better solution could be employed. The client may provide an [optional] requestID and call the operation synchronously. Then, if the client decides to abort it, it calls the server again (on another thread) and provides this requestID. The server maps (client ID/client requestID) onto a call being serviced to set 'cancelled' flag for this call. And the server's thread may check the flag as frequently as it needs, with virtually no overhead. Of course, the client is responsible for generating unique request IDs (within its process). Now, how could the server identify the client? We would need the client's IP & its process ID (I believe port numbers in .NET remoting, even if available at the server, are transient and cannot be relied upon). If the .NET remoting does not provide any means for this (I believe it does), the client could explicitly send its IP/process ID in the call's arguments (together with the request ID). Of course, killing a thread is not a good idea. Marek =================================== This list is hosted by DevelopMentor� http://www.develop.com Some .NET courses you may be interested in: Essential .NET: building applications and components with CSharp August 30 - September 3, in Los Angeles http://www.develop.com/courses/edotnet View archives and manage your subscription(s) at http://discuss.develop.com
