消息可靠性和传输可靠性是WCF区别于WebService的两大特征。在前面谈到TCP的可靠性的一些基本知识，那么它和WCF的可靠性有什么异同点呢？
WCF可以基于各种不同的协议，因此WCF的可靠性并不依赖于TCP协议，而是有自己的协议实现，也就是WS-RM。
在了解我们先看下Web环境下，我们所面对的问题:
传输通信可能产生的问题
1.服务器可能宕掉，或者路由器可能忙于处理大量请求而造成的网络阻塞。
1.服务器可能宕掉，或者路由器可能忙于处理大量请求而造成的网络阻塞。
2.连接丢失。
你正在发送一些消息，但是传送这些消息所依靠的连接可能在消息达到之前就就断掉了。比如你的网线没插稳，或者你的无线网卡抽风了，都有可能。当然更重要的是，你如何才能恢复连接？如果你用的是Http协议，你也知道这玩意是无状态的吧。当然，你可以写一堆代码去解决这个问题。
3.消息丢失。
好吧，你已经发送出了消息，网络是可用的，而且连接也很稳定。但是由于某些神奇原因，有些信息还是没有到达目的地。你怎么防止这种问题呢？
4.消息的顺序问题。
关于顺序的问题。咦，我传的一副美女切图怎么中了面目全非脚？原来是消息顺序有问题……
消息处理时可能产生的问题
当消息在service端处理过程中，service端可能会出错，这是非常正常的事情。因为service端的程序出错可能会导致什么样的问题呢？
当消息在service端处理过程中，service端可能会出错，这是非常正常的事情。因为service端的程序出错可能会导致什么样的问题呢？
1.因为服务端错误而导致消息丢失
2.相互关联的一组消息被拆开分别处理了:
你可能有一组消息需要作为一个事务来处理（ACID），但是这些消息却被你的系统当作单独的请求来处理了。
3.消息重发问题
我们解决这些问题要做到的：
1.接收保障
接收保障确保从消息源发送的消息能够成功地抵达目的地。
2.重复筛选
重复筛选意味着消息的接收端能够识别每一个接收到的消息，自动丢弃重复的消息。
3.有序交付
有序交付要求消息的接收端能够完全按照消息发送的顺序上对消息进行交付。
WCF能提供给我们的可靠性和配置的灵活性。
WCF能提供给我们的可靠性和配置的灵活性。
值得高兴的是，这些问题不用我们自己亲手写大量代码解决，WCF框架内置对消息可靠性和session可靠性的支持可以让我们轻松解决上述的问题。而我们所需要做的只是简单配置一下就可以了。
WCF的消息可靠性保证了端到端（end to end）级别的可靠性，也就是说无论中间有多少个hop都能保证消息的可靠性。
比如，你可以一开始在binding中设置由TCP作为传输协议，binary作为编码方式来传输你的消息。之后由于需要调整至Http传输协议,text作为编码方式，只需要在config中做相应的修改就可以了，非常简单。
下面这些参数就是可以针对上面的问题进行的调整:
Acknowledgement Interval
This is a TimeSpan property indicating how long the receiver should wait before
sending acknowledgements of messages received. The default value is 00:00:00.
This is a TimeSpan property indicating how long the receiver should wait before
sending acknowledgements of messages received. The default value is 00:00:00.
2000000 (or 0.2 seconds). This property influences only bindings that support
duplex communication because request-reply collects acknowledgements and
returns them with the next available HTTP response.
Flow Control
This boolean property is enabled by default. When enabled, the sender will hold
off on sending messages while the receiver transfer window buffer is full. This
reduces the number of retry attempts necessary when the receiver buffer is full
and thus unable to process an incoming message.
Inactivity Timeout
This is a TimeSpan property that controls the duration of the reliable session
including channel layer activity. If no messages, including infrastructure mes-
sages such as reliable session acknowledgements, are transmitted during this
elapsed time, the session is faulted. The default value is 00:10:00 (or 10 minutes).
Max pending Channels
This int property controls the number of concurrent requests for new reliable
sessions that can queue before rejecting new requests. The default value is 4.
Max Retry Count
This int property controls the number of retry attempts from the sender when a
message has not been acknowledged. The default value is 8, but this can be con-
figured up to 20. After the number of retries is exhausted for a message, the ses-
sion is faulted.
Max Transfer Size Window
This int property controls the number of messages held in the buffer at the
sender or receiver. At the sender, messages are buffered to await acknowledge-
ment. At the receiver, messages are buffered for delivery, optionally to ensure
order. The default setting is 8.
Ordered
This boolean property is enabled by default, which means that if reliable ses-
sions are enabled, messages are delivered in order.
我们可以这样在系统给定的"binding套餐"中这样设置reliableSession配置节
duplex communication because request-reply collects acknowledgements and
returns them with the next available HTTP response.
Flow Control
This boolean property is enabled by default. When enabled, the sender will hold
off on sending messages while the receiver transfer window buffer is full. This
reduces the number of retry attempts necessary when the receiver buffer is full
and thus unable to process an incoming message.
Inactivity Timeout
This is a TimeSpan property that controls the duration of the reliable session
including channel layer activity. If no messages, including infrastructure mes-
sages such as reliable session acknowledgements, are transmitted during this
elapsed time, the session is faulted. The default value is 00:10:00 (or 10 minutes).
Max pending Channels
This int property controls the number of concurrent requests for new reliable
sessions that can queue before rejecting new requests. The default value is 4.
Max Retry Count
This int property controls the number of retry attempts from the sender when a
message has not been acknowledged. The default value is 8, but this can be con-
figured up to 20. After the number of retries is exhausted for a message, the ses-
sion is faulted.
Max Transfer Size Window
This int property controls the number of messages held in the buffer at the
sender or receiver. At the sender, messages are buffered to await acknowledge-
ment. At the receiver, messages are buffered for delivery, optionally to ensure
order. The default setting is 8.
Ordered
This boolean property is enabled by default, which means that if reliable ses-
sions are enabled, messages are delivered in order.
我们可以这样在系统给定的"binding套餐"中这样设置reliableSession配置节
<wsHttpBinding>
<binding name="wsHttpRM">
<reliableSession enabled="true" ordered="true" inactivityTimeout="00:10:00"/>
</binding>
</wsHttpBinding>
也可以通过自定义的binding来设置相应的reliableSession 配置节
<customBinding>
<binding name="wsHttpCustomRM">
<reliableSession acknowledgementInterval="00:00:00.2000000"
flowControlEnabled="true" inactivityTimeout="00:10:00" maxPendingChannels="4"
maxRetryCount="8" maxTransferWindowSize="8" ordered="true"/>
<textMessageEncoding />
<httpTransport/>
</binding>
</customBinding>
