Introducing IDefaultCommunicationTimeouts

Today's post is a light entrée covering the IDefaultCommunicationTimeouts interface. This interface bundles up the standard group of timeouts- open, close, receive, and send- into one convenient package. A surprising number of classes implement or consume IDefaultCommunicationTimeouts, usually resulting in a series of several delegations in order to reach where the timeouts are actually set.

 public interface IDefaultCommunicationTimeouts
{
   TimeSpan CloseTimeout { get; }
   TimeSpan OpenTimeout { get; }
   TimeSpan ReceiveTimeout { get; }
   TimeSpan SendTimeout { get; }
}

Methods that take an IDefaultCommunicationTimeouts parameter tend to have a quirky heritage. This usually indicates that they at one point were expecting a more substantial class or interface, but that over time, we whittled away the other requirements until only this interface remained.

I don't get a lot of direct use out of this interface because I primarily program against the channel model. When you use channels directly, you have the ability to explicitly specify timeouts on a per-channel, per-operation, per-whatever basis. Timeouts are very much in your face when using the channel model meaning that they're also very accessible when you want to control them. When you're programming against services and contracts though, timeouts are more in the background and the infrastructure machinery has to flow timeouts from place to place on your behalf. IDefaultCommunicationTimeouts is one mechanism for providing that flow.

Next time: Choosing a Transport

Comments

• Anonymous
  May 23, 2006
  A BufferManager recycles the byte buffers used when reading and writing buffered messages.  There's some...
• Anonymous
  October 17, 2006
  A BufferManager recycles the byte buffers used when reading and writing buffered messages . There's some