Mike, I'm sure I'm overcomplicating everything by "leveraging" sample code from MSDN. That was probably my first mistake; I should have been using my course materials from the Guerrilla .NET class you taught in LA. :)
I guess my eyes must have glazed over after the first 12 hour day or something, sorry, but...all I'm really trying to do is create a "hello world" type of remoting app using binary/tcp between the client and server with an asycn callback to the client. I strayed from the path too many times, obviously, because I ended up using http/soap and it doesn't even work (at least on my end). Maybe I'll just start over. :) Sean -----Original Message----- From: Moderated discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED]] On Behalf Of Mike Woodring (DevelopMentor) Sent: Wednesday, February 12, 2003 10:18 AM To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] Asynch Remoting Call Fails BTW, the [OneWay] attribute you have applied to your client code: > public class TheClient > { > public delegate string MyDelegate(); > public static ManualResetEvent e; > > [OneWayAttribute] > public static void MyCallBack(IAsyncResult ar) > { > MyDelegate d = > (MyDelegate)((AsyncResult)ar).AsyncDelegate; > Console.WriteLine(d.EndInvoke(ar)); > e.Set(); > } > isn't doing anything and is unncessary. The [OneWay] attribute is applied to methods that are to be called via remoting across process boundaries, and causes the sending channel to skip waiting for a reply message and the receiving channel to skip sending an reply message. In your code, MyCallback is just a local method that's being called by the in-process thread pool once the async delegate invocation the local TimeConsumingRemoteCall method on the proxy returns. Your use of BeginInvoke isn't really specific to remoting. You're just using a local thread pool thread to call the TimeConsumingRemoteCall method on the proxy, which takes a "long" time to return. You don't want to block yourself for that amount of time, so you're borrowing a thread from the thread pool to do the job (ostensibly so you can go do other things in the meantime). When that thread returns from its call to TimeConsumingRemoteCall, it will then invoke TheClient.MyCallback to let you know the call completed. Also, you might have just wanted to familiarize yourself with how to use BeginInvoke to request a callback when the method completes, but if you want to block yourself until that call completes, you don't need to go to the trouble of creating & signaling a manual reset event. That functionality is built-in to the IAsyncResult interface. IOW, instead of doing this: IAsyncResult ar = d.BeginInvoke(cb, null); // do other things e.WaitOne(); where e is a reference to a ManualResetEvent that's signaled by the callback referred to by 'cb', you can instead just do this: IAsyncResult ar = d.BeginInvoke(null, null); // do other things ar.AsyncWaitHandle.WaitOne(); If the entire point of your callback is to signal an event telling you the call completed, you can just skip that altogether and use the built-in mechanism for waiting until the call completes. -Mike DevelopMentor http://staff.develop.com/woodring
