I found a new post about the Silverlight 4 improvements in Duplex Services the other day.  After reading up on Duplex Services a bit: http://msdn.microsoft.com/en-us/library/cc645026(VS.95).aspx and noticing a lot of the timeout issues my project was having I asked a co-worker: "have you seen this Duplex Services thingy?" and he said "oh yeah, I know about that."  I groaned and asked why weren't we using it and he just shrugged.

Since we were already Async WCF heavy, using Duplex Services was easy to switch to.  Now all of our long running processing problems were over.  Seriously.  Duplex Services keeps a channel open to have callback events to the client.  It basically just polls over and over again.  The SL4 improvements (https://blogs.msdn.com/b/silverlightws/archive/2010/06/25/http-duplex-improvements-silverlight-4.aspx) make it performant: http://tomasz.janczuk.org/2010/03/comparison-of-http-polling-duplex-and.html  I do recommend digging in the generated code to manage the DuplexChannel yourself.  The generated code is so nasty. 

Just to verify what was going on, I booted up fiddler2 to see what it showed.  I created made a service just run longer than the timeout then have an event callback.  I could see stuff going on but it was all nonsense since WCF using the .NET Framing Protocol.  Some Microsoftie did write a basic inspector for fiddler2: http://blogs.msdn.com/b/silverlightws/archive/2010/05/10/fiddler-inspector-for-wcf-silverlight-polling-duplex-and-wcf-ria.aspx

The only downside is that you really can't use the Async pattern.  What I've ended up doing is making pairs of one-way calls.  One for the server that the client calls, then the client one that the server uses for the callback.  You've basically have the client call the method then an event is fired on the client when the process is done.  You have to have an instance of a client object that maintains the callback for each call.  I'd rather use the Async pattern and pass state that way.  I guess you can't have everything.