APM, EAP and TPL on Socket Programming

Question

I found Difference between […]Async and Begin[…] .net asynchronous APIs question but this answer confused me a little bit.

Talking about these patterns, Stephen said:

Most *Async methods (with corresponding *Completed events) are using the Event-Based Asynchronous Pattern. The older (but still perfectly valid) Begin* and End* is a pattern called the Asynchronous Programming Model.

The Socket class is an exception to this rule; its *Async methods do not have any corresponding events; it's essentially just APM done in a way to avoid excessive memory allocations.

I get it as using *Async methods are more efficient, at least when it comes to sockets. But then he mentioned Task Parallel Library:

However, both APM and EBAP are being replaced with a much more flexible approach based on the Task Parallel Library. Since the TPL can wrap APMs easily, older classes will likely not be updated directly; extension methods are used to provide Task equivalents for the old APM methods.

I found TPL and Traditional .NET Asynchronous Programming on MSDN, I know the basics of TPL, creating tasks, cancellations, continuations, etc but I still fail to understand these:

What are the advantages of Asynchronous Programming Model (APM) and Event-based Asynchronous Pattern (EAP) compared to each other? How does TPL can wrap APMs easily mean that both APM and EAP are being replaced with TPL?

And most importantly: Which should I use in socket programming;

• APM?
• EAP?
• APM or EAP wrapped by a Task?
• TPL by using the blocking methods of Socket class in tasks?
• Other?

Answer 1

How does TPL can wrap APMs easily mean that both APM and EAP are being replaced with TPL?

It doesn't. Wether APM and EAP will be replaced by TAP (Task Asynchronous Pattern) or not in new APIs has nothing to do with this. I would expect TAP to replace APM and EAP for a variety of reasons. The main reason to me is that the code you write for using the TAP composes much better. Doing .ContinueWith(/* ... */).ContinueWith(/* ... */) generally reads much better than the corresponding code you would need to write to chain async calls through Begin/End methods, even if you don't take into account the options you can pass to ContinueWith to determine if the continuation should run. The TPL also provides various combinators for Tasks, such as WaitAll and WaitAny, that can make some scenarios much easier. The language support coming in C# and VB.NET via the async/await keywords will make this even easier.

Being able to wrap APMs in the TAP makes it easier to switch to this pattern because it means you don't have to rewrite existing code to make it fit in the new model.

Which should I use in socket programming?

I would recommend using the TAP wrapping the APM methods on Socket. Unless you can prove that the extra overhead of wrapping the Begin/End methods into a Task are the difference between scalable/fast enough or not, I would take advantage the ease of coding of the TAP.

Answer 2

Gideon had a great answer; I just wanted to provide some more background:

What are the advantages of Asynchronous Programming Model (APM) and Event-based Asynchronous Pattern (EAP) compared to each other?

APM is more common and it has a pretty strictly-defined pattern. e.g., the TPL has generic wrappers for APM methods (TaskFactory.FromAsync), but it can't do the same for EAP because EAP isn't as strictly-defined.

EAP has one great advantage: the event callbacks handle thread marshaling for you. So they're really nice for, e.g., basic background operations for a UI (BackgroundWorker).

TAP combines the best of both worlds: automatic thread marshaling by default and a strictly-defined, common pattern. It also has a nice object representation for an asynchronous operation (Task).

How does "TPL can wrap APMs easily" mean that "both APM and EAP are being replaced with TPL"?

It doesn't.

"However, both APM and EBAP are being replaced with a much more flexible approach based on the Task Parallel Library." - meaning that new code doesn't need to include APM/EAP methods/events; new code should include TAP methods instead.

"Since the TPL can wrap APMs easily, older classes will likely not be updated directly; extension methods are used to provide Task equivalents for the old APM methods." - meaning that you can add TAP methods to an existing APM type using TaskFactory.FromAsync; I figured the TPL team would take this approach rather than modifying a ton of classes in the BCL. However, I was wrong in this conjecture. For performance reasons, the BCL/TPL team did review the entire framework and added TAP methods directly to .NET classes instead of using extension methods. The new TAP methods are included in .NET 4.5, coming soon...