由傳輸過程中需要面對的問題探討WCF中的“可靠性”

訊息可靠性和傳輸可靠性是WCF區別於WebService的兩大特徵。在前面談到TCP的可靠性的一些基本知識，那麼它和WCF的可靠性有什麼異同點呢？

WCF可以基於各種不同的協議，因此WCF的可靠性並不依賴於TCP協議，而是有自己的協議實現，也就是WS-RM。 在瞭解我們先看下Web環境下，我們所面對的問題:  傳輸通訊可能產生的問題
1.伺服器可能宕掉，或者路由器可能忙於處理大量請求而造成的網路阻塞。
 2.串連丟失。你正在發送一些訊息，但是傳送這些訊息所依靠的串連可能在訊息達到之前就就斷掉了。比如你的網線沒插穩，或者你的無線網卡抽風了，都有可能。當然更重要的是，你如何才能恢複串連？如果你用的是 Http協議，你也知道這玩意是無狀態的吧。當然，你可以寫一堆代碼去解決這個問題。 3.訊息丟失。好吧，你已經發送出了訊息，網路是可用的，而且串連也很穩定。但是由於某些神奇原因，有些資訊還是沒有到達目的地。你怎麼防止這種問題呢？ 4.訊息的順序問題。關於順序的問題。咦，我傳的一副美女切圖怎麼中了面目全非腳？原來是訊息順序有問題……

訊息處理時可能產生的問題
當訊息在service端處理過程中，service端可能會出錯，這是非常正常的事情。因為service端的程式出錯可能會導致什麼樣的問題呢？
1.因為服務端錯誤而導致訊息丟失2.相互關聯的一組訊息被拆開分別處理了:你可能有一組訊息需要作為一個事務來處理（ACID），但是這些訊息卻被你的系統當作單獨的請求來處理了。
3.訊息重發問題  我們解決這些問題要做到的： 1.接收保障接收保障確保從訊息源發送的訊息能夠成功地抵達目的地。2.重複篩選重複篩選意味著訊息的接收端能夠識別每一個接收到的訊息，自動丟棄重複的訊息。3.有序交付有序交付要求訊息的接收端能夠完全按照訊息發送的順序上對訊息進行交付。

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. 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配置節

<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>