One-Way operations vs Asynchronous calls

Question

As stated in the first section of this article (.chm file - see note below)

One-way calls do not equate to asynchronous calls. When one-way calls reach the service, they may not be dispatched all at once and may be queued up on the service side to be dispatched one at a time... If the number of queued messages has exceeded the queue's capacity, then the client will block, even when issuing a one-way call.

If a one-way call is invoked, when does it return control to the caller? The introduction of the same article states that one-way calls are used for fire-and-forget operations , thereby simulating a kind of asynchronous call. If a sessionful WCF service has a Login() one-way method which starts the session, when does this method return control to the caller? Does it return before the method is actually executed on the service? If so, how can I be sure that the method was performed on service?

If I wanted the service to return to the client the possible errors that occur during the login procedure, would be an asynchronous call the only way to achieve a fire-and-forget behaviour?

---

Note: The quote above is taken from an article called WCF Essentials - What You Need To Know About One-Way Calls, Callbacks, And Events by Juval Lowy, and can be found in the October 2006 issue of MSDN magazine. The link above is to a help file (.chm) format on MSDN. If you can't get the linked CHM file to work (I couldn't) you can open it with 7zip.

Answer 1

If a sessionful WCF service has a Login one-way method which starts the session, when does this method return control to the caller?

For OneWay calls: The caller will continue to execute as soon as the service call is dispatched or queued. Basically as soon as the service successfully receives the call.

how can I be sure that the method was performed on service?

If the client does not get an exception, the service call was (or will be) performed. When the service call actual runs or whether it succeeded or threw an exception is unknown to the client.

If I wanted the service to return to the client the possible errors that occur during the login procedure, would be an asynchronous call the only way to achieve a fire-and-forget behaviour?

This does not make sense. Fire-and-forget by definition means forget the result. It does not return any values or errors to the client. However an asynchronous call is not fire-and-forget and would return errors.