One question I get from custom channel authors has to do with the various lifetimes of the components involved. Especially since, as per best practice, their heavyweight resources are attached to ChannelFactories and ChannelListeners and simply referenced from the Channel. Nicholas covered the basics in this post. Which to summarize is:

• ChannelFactory created Channels cannot outlive their creator

• channelFactory.Close/Abort will Close/Abort all Channels created by that factory

• channelListener.Close/Abort simply disables the ability to accept new channels; existing channels can continue to be serviced

Which makes life on the ChannelFactory end pretty straightforward.  On the ChannelListener side, there are a few subtleties. 

First, a Channel is owned by the listener from the time of creation until the successful completion of channel.Open.  So if you are writing a custom listener that has offered up channels, you should clean them up if and only if they haven’t been opened.

Second, in order to perform eager disposal, you will need to track active ownership of your heavyweight resources. If there are opened channels, then you need to make sure that the shared resources that they leverage have their ownership transferred from the listener to your active channel(s). This can be accomplished through ref-counting, active transfers, or other mechanisms.

When writing a layered channel, sometime you want to decouple processing without changing the channel shape. One example would be for layered demux purposes. When layering your IInputChannel on top of a "lower" IInputChannel, you have a few options for lifetime management and pumping that are worth noting:

1. When your innerInputChannel.Receive call returns "null", that means that no more messages will arrive on that particular channel. You should Close that channel and then Accept a new one.
2. If the innerListener.AcceptChannel call returns null then your inner listener is completely done providing messages and you need to follow suit when you are through with any added messages that you may have buffered.
3. If someone calls Close/Abort on your IInputChannel, you have the option of holding onto the inner channel within your listener (and providing a new facade on top when a new channel is accepted). Alternatively, you can close the inner channel and create a new one with your new channel. That choice is entirely at your discretion (and at the mercy of your perf tuning results :))

I’ve gotten some questions recently about how our net.tcp transport functions at the memory allocation level. While at its core this is simply an “implementation detail”, this information can be very useful for tuning high performance routers and servers depending on your network topology. 

When writing a service on top of net.tcp, there are a few layers where buffer allocations and copies can occur:

• Buffers passed into socket.Receive()
• Buffers created by the Message class (to support Message copying, etc)
• Buffers created by the Serialization stack (to convert from Message to/from parameters)

In addition, this behavior differs based on your TransferMode (Buffered or Streamed). In general you’ll find that Buffered mode will provide you the highest performance for “small messages” (i.e. < 4MB or so), while Streamed will provide better performance for larger messages (i.e. > 4MB). Usually this switch is combined with a tweak of your MaxBufferPoolSize in order to avoid memory thrashing.

TransferMode.Buffered

In Buffered mode, the transport will reuse a fixed-size buffer on its calls to socket.Receive(). The ConnectionBufferSize setting on TcpTransportBindingElement controls the size of this buffer.

The data read from the wire is incrementally parsed at the .Net Message Framing level, and is copied into a new buffer (allocated by the BufferManager) that is sized to the length of the message. This step always involves a buffer copy, but rarely involves a new allocation for small messages (since BufferManager will cache and recycle previously used buffers).

The message-sized buffer is then passed to the MessageEncoder for Message construction. Again, minimal allocations should occur here since we will pool XmlReader/Writer instances where possible. At this point you have a Message that is backed by a fixed-size buffer and we will share that backing buffer for all copies of the Message created through message.CreateBufferedCopy().

If your contract is Message/Message, then no more deserialization will occur. If you are using Stream parameters, then the allocations are determined by your code (since you are creating byte[]s to pass to stream.Read), and given the nature of the Stream APIs you will entail a buffer copy as well (since we have to fill the caller buffer with data stored in the callee).

If your contract uses CLR object parameters, then the Serializer will process the Message and generate CLR objects as per your Data Contracts. This step often entails a number of allocations (as you would expect since you are generating a completely new set of constructs).

TransferMode.Streamed

There are three main differences that occur when you are using TransferMode.Streamed:

1. The transport will use new variable-sized byte[]s in its calls to socket.Receive. These byte[]s are still allocated from the configured BufferManager. The transport will then offer up a scatter/gather-based stream to the MessageEncoder so there are no extra buffer allocations or copies in this case.
2. The Message created from the Encoder will be a “Streamed” message. This means that if you simply Read() from the Message’s Body in a single-shot then we don’t allocate any extra memory. However, if you call message.CreateBufferedCopy() we will entail some large allocations since we need to fully buffer at that point. Note that some binding elements (such as ReliableSession and certain Security configurations) will call CreateBufferedCopy() under the hood and trigger this situation.
3. Since the backing data may not all be in memory, invoking the Serializer will incur a larger cost since it will be pulling all the data into memory at once (in order to generate the appropriate CLR objects, even if that is simply a byte[]).

As you can see, there is a tension between performance and usability. Hopefully this data will help you make the appropriate tradeoffs.