...Can Also Come Out (IOutputChannel)

Yesterday, we got a look at the reader side of the one-way communication pattern, which is implemented using IInputChannel.  Today, we're looking at the writer side of that pattern.

IOutputChannel bears a striking resemblance to IInputChannel but with only one of the three varieties of methods that we saw previously.  I won't repeat all of the references again, so go back to yesterday's post if you need a copy.

 public interface IOutputChannel : IChannel, ICommunicationObject, IDisposable
{
   EndpointAddress RemoteAddress { get; }
   Uri Via { get; }

   IAsyncResult BeginSend(Message message, AsyncCallback callback, object state);
   IAsyncResult BeginSend(Message message, TimeSpan timeout, AsyncCallback callback, object state);
   void EndSend(IAsyncResult result);
   void Send(Message message);
   void Send(Message message, TimeSpan timeout);
}

We just have the imperative variety of Send because it doesn't really make sense to TryToSend a message or to WaitToSend a message.  That's a little asymmetry between sending and receiving, but there's no reason to put those extra methods in if they don't do anything useful.  We do offer both synchronous and asynchronous flavors of Send, as well as explicit timeout and default timeout flavors.  I say this a lot, but I'll say it again: use the version with explicit timeouts.

One other difference that you might have noticed is that in addition to the RemoteAddress, which is where messages sent through this channel will end up, is that there is a Via property.  The via is the first hop that a message should take on its way to the remote address.  In most standard Internet scenarios, the via is the same as the final address.  You only need to change this when you're doing some kind of manual routing.  I'll have more to say about endpoints and vias in the future.

And remember, as a totally free bonus, by combining an IInputChannel and IOutputChannel, we've produced an IDuplexChannel that implements one of our two-way communication patterns.  Here's that diagram again.

It really is as simple as the picture shows.

Next time: It Makes the WWW Go Round, Part 1: IRequestChannel

Comments

• Anonymous
  March 14, 2006
  Last week I introduced the different kinds of channel shapes that are available with WCF.  This...
• Anonymous
  March 17, 2006
  The final WCF message exchange pattern that I'm going to look at is the request-reply version of two-way...
• Anonymous
  March 20, 2006
  After a short break, let's continue looking at the request-reply message pattern.  In the previous...
• Anonymous
  March 21, 2006
  The final player in the drama between IRequestChannel and IReplyChannel is the link connecting requests...
• Anonymous
  March 21, 2006
  Thanks for the work on your blog.  It really provides some great insight into WCF's not so beaten path.
  
  One question, what is the timeout specifically waiting for on a TCP IOutputChannel's send? Is it the connection establishment, it seems from my naive eye that it blocks until a return has been executed from the intended one way service.
  
  Thanks
  
• Anonymous
  March 21, 2006
  At the transport level, the timer for TCP send is typically going to start a little before the message is encoded and stop a little after shoving all of the data into the underlying buffers.  The end point is actually a bit nebulous since we'll be in the process of cleaning up after the send but not have finished cleanup at every level of the stack.  Once you start layering channels on top of the transport, they're going to start imposing their own interpretation of what it means for the operation to be finished.
  
  A good way to explore the details here is to block during a particular operation (either with the debugger or by writing a custom implementation).  Then, you can see where timeout aborts occur.  You'll get the original exception from the innermost layer that contains the operation.
• Anonymous
  March 22, 2006
  When we last left the IChannel interface, there was a brief introduction of the concept of a channel...