|
From the while you've been out-department.
Don found a cool feature in Remoting: MarshalByRefObjects can implement IMessageSink. In this case, when accessed via a transparent proxy, instead of calling the real method, the object's IMessageSink.SyncProcessMessage() will be called by the Remoting framework. Damn, that's cool! [1] Maybe that's how I can even intercept calls to ServicedComponents. I'll try this later ...
However, Don notes that "The one thing this doesn't enable is allowing you to catch BeginInvoke requests.". I'm glad to say that this is not 100% true. For the more curious readers of my blog can find a sample on how to do this here.
The reason why some async calls are handled by SyncProcessMessage() is the following: depending on the kind of Remoting boundary you are crossing, the server has no chance of knowing whether the client sent the call synchronously or asynchronously (and also doesn't care because the thread detachment has already happend on the side of the caller anyway). For example, for a process boundary, everything the server sees is an incoming HTTP request, no matter if the client used a direct call or .BeginInvoke(). However, when you're just working on a context boundary, everything is fine because this boundary is obviously only virtual and the server knows in this case if you're using .BeginInvoke() or not. An AppDomain boundary is somewhat in between .. even though it's virtual, the parameters are marshalled. In this case, the server also has no notion of sync or async calls on the client side ... maybe this should be different, but anyway.
[1] And yes, I didn't know about it before ;)
|