<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="http://blogs.msdn.com/utility/FeedStylesheets/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>...Can Also Come Out (IOutputChannel)</title><link>http://blogs.msdn.com/drnick/archive/2006/03/14/550989.aspx</link><description>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</description><dc:language>en</dc:language><generator>CommunityServer 2.1 SP1 (Build: 61025.2)</generator><item><title>What Goes In... (IInputChannel)</title><link>http://blogs.msdn.com/drnick/archive/2006/03/14/550989.aspx#551254</link><pubDate>Tue, 14 Mar 2006 18:56:15 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:551254</guid><dc:creator>Nicholas Allen's Indigo Blog</dc:creator><description>Last week I introduced the different kinds of channel shapes that are available with WCF.&amp;amp;amp;nbsp; This...</description></item><item><title>It Makes the WWW Go Round, Part 1: IRequestChannel</title><link>http://blogs.msdn.com/drnick/archive/2006/03/14/550989.aspx#553821</link><pubDate>Fri, 17 Mar 2006 19:05:32 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:553821</guid><dc:creator>Nicholas Allen's Indigo Blog</dc:creator><description>The final WCF message exchange pattern that I'm going to look at is the request-reply version of two-way...</description></item><item><title>It Makes the WWW Go Round, Part 2: IReplyChannel</title><link>http://blogs.msdn.com/drnick/archive/2006/03/14/550989.aspx#555611</link><pubDate>Mon, 20 Mar 2006 19:12:29 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:555611</guid><dc:creator>Nicholas Allen's Indigo Blog</dc:creator><description>After a short break, let's continue looking at the request-reply message pattern.&amp;amp;amp;nbsp; In the previous...</description></item><item><title>It Makes the WWW Go Round, Part 3: IRequestContext</title><link>http://blogs.msdn.com/drnick/archive/2006/03/14/550989.aspx#556668</link><pubDate>Tue, 21 Mar 2006 19:03:36 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:556668</guid><dc:creator>Nicholas Allen's Indigo Blog</dc:creator><description>The final player in the drama between IRequestChannel and IReplyChannel is the link connecting requests...</description></item><item><title>re: ...Can Also Come Out (IOutputChannel)</title><link>http://blogs.msdn.com/drnick/archive/2006/03/14/550989.aspx#557050</link><pubDate>Tue, 21 Mar 2006 23:46:16 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:557050</guid><dc:creator>Dave</dc:creator><description>Thanks for the work on your blog. &amp;nbsp;It really provides some great insight into WCF's not so beaten path.&lt;br&gt;&lt;br&gt;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. &lt;br&gt;&lt;br&gt;Thanks&lt;br&gt;</description></item><item><title>re: ...Can Also Come Out (IOutputChannel)</title><link>http://blogs.msdn.com/drnick/archive/2006/03/14/550989.aspx#557480</link><pubDate>Wed, 22 Mar 2006 04:21:28 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:557480</guid><dc:creator>Nicholas Allen</dc:creator><description>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. &amp;nbsp;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. &amp;nbsp;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.&lt;br&gt;&lt;br&gt;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). &amp;nbsp;Then, you can see where timeout aborts occur. &amp;nbsp;You'll get the original exception from the innermost layer that contains the operation.</description></item><item><title>Creating Channels for Talking</title><link>http://blogs.msdn.com/drnick/archive/2006/03/14/550989.aspx#558135</link><pubDate>Wed, 22 Mar 2006 19:58:14 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:558135</guid><dc:creator>Nicholas Allen's Indigo Blog</dc:creator><description>When we last left the IChannel interface, there was a brief introduction of the concept of a channel...</description></item></channel></rss>