IN THE LAST THREE CHAPTERS you've seen how the .NET Remoting Framework's various layers can be extended. The ultimate example of customization is nevertheless the creation of a specific transport channel.
As you already know by now, the .NET Remoting Framework comes out of the box with two transport channels: HTTP channel and TCP channel. Even though these protocols cover a lot of common scenarios, you might have a special need for other transport channels for some applications. On one hand, protocols like named pipes, for example, could allow for higher performance (with security!) for applications communicating with each other on the same machine. On the other hand, you might have the need for asynchronous communication with MSMQ or even by standard Internet e-mail using SMTP and POP3.
No matter which protocol you choose, you must watch for one thing: most protocols are either synchronous or asynchronous in their nature. As the remoting framework supports both kinds of calls, you'll need to either map asynchronous .NET Remoting calls onto a synchronous protocol like HTTP or TCP or map synchronous .NET Remoting calls onto an asynchronous protocol like MSMQ or SMTP/POP3.
With the former, you will, for example, have to spawn a secondary thread that waits for the reply and notifies the IAsyncResult (as seen in Chapter 7) whenever a response is returned. The latter demands that you block the calling thread and wake it up as soon as the asynchronous response has been received from the underlying protocol.