日前我開發的服裝DRP需要用到即時通信方面的技術，比如當下級店鋪開出零售單時上級機構能實時收到XX店鋪XX時XX分賣出XX款衣服X件之類的信息，當然在上級發貨時，店鋪里也能收到已經發貨的提醒。即時通信技術能運用到DRP系統的很多方面，若深入下去，甚至可以開發一個系統內部的通訊模塊，類似于QQ。當前大部分的企業管理系統開發類似功能，使用的都是效率及其低下的定時拉數據的方式，即每隔一段預定時間去數據存儲區（一般為數據庫）讀取數據，然后在代碼層判斷，若數據同內存數據一致則丟棄，否則更新內存數據并同步更新UI。這種方式的缺點顯而易見：效率低；服務器壓力大；數據實時性不強。因此我花時間了解了我可能用到的關于真正意義上的即時通信技術的一些知識，作為開發之前的知識儲備。有關這個功能的開發我會詳細記錄日志供其他朋友和自己以后參考學習。

• P2P傳輸協議選擇:

一般集中在TCP和UDP上，這兩種各有優劣，說簡單點就是TCP安全穩健效率低，而UDP效率高但可能會丟三落四（視網絡情況定，丟包的概率不高）。說些題外話，有時寫代碼寫著寫著就會想到哲學方面的東西，比如TCP和UDP的比較會發現，效率高且安全可靠的傳輸協議并不存在，這種情況屢見不鮮，所謂魚和熊掌不可兼得，也許這就是宇宙的法則吧。我選擇UDP，首先UDP丟包的概率不高，其次若選擇TCP還要考慮連接數啥啥的問題，不勝煩惱。 

• “打洞”

這個詞讓人浮想聯翩，對搞網絡通信的人來說卻毫無吸引力。這種體力活源自IP地址太少，各種NAT設備（俗稱路由器）應運而生，解決了僧多粥少的問題，但引入了另一個問題，即任意連網的電腦并不能確保可以直接通信，假如它們隱藏在各自的NAT之后，并沒有確切的網絡地址，地址都不知道，談何通信。雖然隱藏在NAT后面電腦沒有公網地址，但NAT知道哪些消息是發給誰并知道怎么把這些消息送達，前提是這個消息是受信任的。

“打洞”（我不知道為什么要叫這個名詞）簡單的說就是在兩端NAT建立起信任的連接。這個過程首先需要一臺擁有公網地址的機器S作為媒介，現在假設處于某個局域網內部的機器A想同另一個局域網內的機器B通信，那么如下操作就是一次“打洞”：

1. A連接S獲取B的公網地址（通過B局域網的NAT對外公布）

2. A按照這個地址向B隨便發一點東西（東西不重要，目的是讓對方對你有一定的印象），A的NAT將B地址列入信任列表

3. 毫無疑問，B的NAT把關很嚴，這種套近乎的方式他見得多了，大部分是圖謀不軌，因此他并未理會，也未告知B這個事情。

4. A告知S他想認識B，希望S幫忙撮合

5. S當然是B的NAT熟悉的人，這個媒人已經幫B促成千萬次的約會了，因此S被準許將A的意圖告知B，并給了A的公網地址（通過A的NAT對外公布），B答應考慮A的請求

6. 若B對A有意，那么她可以按照A的地址隨便發一點東西過去，此時B的NAT將A地址列入信任列表。此時“打洞”完畢。

少年們于是不淡定了，啥都沒有發生呢，怎么就完了呢。其實“打洞”過程就是相互建立信任的過程，相互加入各自的信任列表之后，以后就能按照各自NAT的公網地址進行直連通信了，這又是另外的故事了。上述過程對少數NAT設備來說可能并不準確。

UDP組播通信似乎用不著“打洞”（假如路由器支持IGMP協議的話），不知道我的這個理解有沒有問題，待以后驗證。

• 為WCF增加UDP綁定

我的服裝DRP采用WCF作為服務提供者。本來我想繞過WCF，直接操作Socket來進行UDP通信。后來想說順便熟悉下WCF這個框架的底層機制，于是下載了微軟的一個示例，并研讀了蔣大牛的《WCF技術剖析》，這本書寫的非常好。兩者結合，許多困惑之處往往能柳暗花明。現將這兩天的學習做一總結。（聽說WCF4.5加入了UDP綁定，具體看What’s new in WCF 4.5? UDP transport support）  

1. 一個綁定由若干綁定元素構成，每個綁定元素負責客戶端和服務器端的信道管理器ChannelManager的創建，信道管理器在客戶端和服務器端有不同的名稱，前者為信道工廠ChannelFactory，后者為信道監聽器ChannelListener，他倆有個共同的責任就是創建各自對應（即在客戶端和服務器端分別創建）的信道。一個信道管理器創建相應類型的信道（由于一般對同一個連接來說，一個類型在所在的信道棧里只有一個的信道，因此我們可以說信道管理器和信道一一對應，有信道棧，即有信道管理器棧）。一個信道有所謂的“信道形狀”，表示它是什么類型的信道，即輸出、輸入、請求、回復還是雙工。另外信道從會話角度還分為數據包信道（筆者注：該名詞取自《WCF技術剖析》一書，但個人覺得應該是非會話信道更準確，因為數據包和傳輸信道而非所有種類信道更相關，而任何傳輸信道傳送的都是數據包）和會話信道（此處所謂的會話包括協議本身的會話機制如tcp協議，也包括WCF框架提供的會話機制），很明顯，UDP使用的就應該是數據包信道(按前面所述，這句話雖然無錯，但也無意義。任何傳輸信道都可以附加會話機制以實現相關消息的來回傳送)。

2. 綁定元素構成綁定的次序也很重要，按上一條所述可得，綁定元素的次序決定了信道的次序，而信道的次序本質上決定了綁定的特性與能力。消息在信道棧中應該是自上而下逐信道處理的。

3. WCF的終結點三要素中，我們可以只通過綁定和終結點地址進行客戶端和服務器端的[消息]通信，服務接口要素只是借助通信的功能調用服務端的方法并返回而已（這句話并不確切，確切地說，服務契約中的操作契約本質上定義了操作（而非信道）采用的消息交換模式，以及消息的格式，這個作用主要在發布元數據生成WSDL時用到。）。

4. 終結點有邏輯地址和物理地址之分，一般說的終結點地址是邏輯地址，我個人理解邏輯地址就是SOAP的To，可以指定物理地址從而忽略邏輯地址，否則WCF會有自己的一套映射機制從邏輯地址得到物理地址。最終的調用地址是物理地址。 假設我們為一個服務（同一個服務接口）指定了3個終結點地址（邏輯地址），其中兩個終結點地址分配同一個監聽地址（物理地址），此時有兩個監聽地址。那么當服務被成功寄宿時，WCF會創建兩個信道分發器ChannelDispatcher對象，每個信道分發器各擁有屬于自己的信道監聽器對象，它們分別綁定到兩個監聽地址進行服務調用請求的監聽。此外，WCF還會為3個終結點地址創建3個終結點分發器EndpointDispatcher。當信道分發器通過信道監聽器接收到消息時，將會根據消息自身攜帶的信息按照終結點分發器的指定規則選擇與之相匹配的終結點分發器，這一過程稱為消息篩選MessageFilter。

5. 操作約束OperationContract指定的Action應該對應的是SOAP的Action，作為上述的篩選規則供信道分發器將消息路由到終結點分發器。

6. 在WCF中有一種服務操作能處理所有的消息類型，叫做非匹配處理器，它接受一個Message類型的參數（因為所有的服務調用最終都轉化為Message抵達服務器），返回Message或void，且Action被指定為“*”。對一個服務契約來說，這樣的操作契約只能有一個。同理，ReplyAction=”*” 可以使用一個Operation處理所有的返回消息。

7. WCF終結點信息最終要被轉化為WSDL方才能被客戶端理解調用，這涉及到WsdlExporter這個類，具體可看WCF技術剖析之二十六:如何導出WCF服務的元數據(Metadata)[實現篇]。為了讓我們自定義的綁定元素被WsdlExporter導出為對應的WSDL元素，我們需要讓自定義綁定元素實現WSDL導出擴展（WSDL Export Extension）和策略導出擴展（Policy Export Extension）。關于策略一說可閱讀Understanding Web Services Policy。簡單地說，策略描述的是服務的能力和要求（目前我只看到要求），假如沒有導出相關策略，客戶端就不知道這一部分的具體要求，可能會導致請求得不到服務的正確響應。因此，策略導出是自定義綁定的一個職責。策略屬于WSDL的一部分。關于策略導出請參看Extending WSDL and Policy, Part 1. Exporting custom policy assertions。有導出就有導入，導入是在客戶端進行的。對于自定義策略來說，我們要實現IPolicyImportExtension接口，以便獲取導出的策略并將其按照預期應用到綁定或其它地方，具體步驟請參看IPolicyImportExtension接口。

8. 補充第7條：WSDL元數據擴展（自定義）導入（包括自定義策略導入），是在客戶端通過客戶端配置文件或Svcutil.exe配置文件或通過編程方式將其添加到System.ServiceModel.Description.WsdlImporter構造函數加載進行的。

下一篇我會參照上面給出的微軟的那個示例，在WCF下實現UDP通信，并增加P2P功能。 

ps：這篇是從百度空間搬過來的，由于百度喜歡和諧，導致很多超鏈接丟失，偶爾還有丟失語句的情況。我粗粗查看了一遍，修復了幾處。關于丟失的鏈接，若讀者有興趣則可根據文本谷歌，應該能找到對應的資料。 另目前的通信設備基本上都支持UPnP協議，能實現自動端口映射，所以UDP打洞的方式也不常用了。。。

轉載請注明本文出處：http://www.rzrgm.cn/newton/archive/2012/11/29/2793929.html