If a blocking call deadlocks, it will not affect any other calls. On the end responding to the call, the method is run on a separate thread. The worst-case scenario is that the server has an extra thread that doesn’t terminate. (And the other end, of course, never receives a response.)

> Even if it is thread-safe, I would probably want an assertion that void functions never block.

Void functions are just as capable of throwing exceptions as any other function. In cases where this is desired, they must block.

> For those times when you want a bit more control I think it would also be useful to provide a “traditional” Async pattern as well: make it easy to follow the Begin*/End* pattern via IAsyncResult.

Because the proxy object is implementing a specific interface, this would not make sense as things stand. One option might be that you can define such Begin/End methods on the interface and the proxy class will hook them up for you.

It’s also not too hard to use a Func<> or Action<> and BeginInvoke/EndInvoke.

And yes, comments are always helpful.

Even if it is thread-safe, I would probably want an assertion that void functions never block.

For those times when you want a bit more control (or conversely when you are making a very rare call and don’t need to setup an additional, explicit thread) I think it would also be useful to provide a “traditional” Async pattern as well: make it easy to follow the Begin*/End* pattern via IAsyncResult. (Possibly you could do some Proxy casting magic to do this. Of course things like that will be easier when C# gets the dynamic keyword.)

Just a few thoughts, hopefully they are useful.

Hey, my protocol isn’t SOAP. That’s gotta be worth something.

Granted, TCP’s enormous headers will probably dwarf that, but if you have a lot of updates that chatter may add up..