.Net 海角點部落

這句話是我在『深入淺出 C#』這本書上讀到的，雖然這本書不太符合我的閱讀習慣，這完全是個人偏好，因為我喜歡內容硬一點的技術書籍，無論如何這是一本好書，光這標題上的這句話就值得去看這本書。

在第一篇曾經說到事件就是一個使用委派的常見例子，這篇咱們來探討一下關於委派與事件之間的相關知識。

前兩篇插科打諢的胡說八道了一堆東西，就算你本來不知道委派為何物也應該不會這麼害怕看這個主題了，所以得來真的講講硬底子的玩意兒，回顧一下關於委派所應該知道的基本知識。

前文拿了張無忌當例子說明了單一委派的狀況，這節就用桃谷六仙來聊聊多重委派。

對於初學者來講，委派 (Delegate) 是一個聽起來非常令人迷惑的名詞，不過當我們在撰寫 .Net 程式的時候其實都不知不覺地在使用委派。

終於要來完成整個發送回應的畫面主體程式，基本上這個程式是由 [Serial Port 系列(7) 基本篇 -- 建立一個簡單的純發送程式(多緒型範例)] 改編而來。

Intel AppUpSM Center 誠摯邀請對HTML5 發展App，有興趣之各界人士參與”Up
你的夢想跟我們一起 App”線上研討會, 並且瞭解Intel AppUpSM Center 如何提供
相關資源協助您，將您的創意App 觸角延伸到全世界各個角落。
在課堂中，歡迎您儘管提出問題及想法與講師討論，讓有志成為科技先端的妳/你，不再是
遙不可及的夢想，加入我們就有無限的可能，誠摯的邀請您來一同參與，讓自己成為全球獨
一無二的你。

這部份來處理接收的協定，接收的部份比起發送會更形複雜一些，先初步分解其工作為以下三大區塊。

在建立了通訊協定最上層的類別後，開始來處理發送部份的協定。

從這篇起要開始慢慢以較為複雜的方式來寫程式，開始要進入自訂類別的初步練習，我會儘量地將步驟拆解的詳細一些，這也意味著每一篇產出的間隔時間也可能會拉長。

發送回應模型應該是寫序列埠通訊最常遇到的，從這篇開始會分成幾篇來一步步完成這個模型的程式。

情境三：具備長度資料
有些協定是會帶長度資料的，以下的例子在第一個Byte 所帶的開頭碼為十進位值 249 ，第二個Byte 所代表的是後面資料內容的長度。

這篇是關於 C# 與 ADO.NET 的整理

MSDN 文件庫中其實有一部份是對於初心者建立正確的程式設計基礎很有幫助的內容，也許很多人一看到 MSDN 文件庫龐大的內容就不知所措，完全不知該從何看起，因此就整理一份索引筆記給大夥兒參考參考，或許不盡完善，不過我就是盡力列出來吧。

具備開頭結尾字元 
有一些通訊協的形式是具備了開頭結尾字元形式的，當然不一定是一個字，不過通常的情形是開頭或結尾字元絕不會出現在中間的資料內容段中，以下的圖例是以大寫字母S做為開頭字元；而大寫E字母做為結尾字元的通訊協定形式。 
 

在進入『發送接收模型』的議題之前，先來討論關於接收資料完整性的問題，在我之前的文章中都是接收緩衝區有多少資料就收多少回來，這產生一個問題是我們常常會遇到分段接收的狀況，也就是說傳送端一次傳送了一份完整的資料，但接收端卻未必會一次就收的完，這樣不完整接收的現象不僅在 SerialPort 會發生，在 Socket 也一樣會產生這種狀況，所以必須採用一些技巧來確認資料的完整性。不過這有非常多不同的情境，在這幾篇文章中會舉出幾項例子但請注意未必能完全符合各種情境的需要。

在邊寫這系列文邊和朋友們討論的過程中，璉大跟我提了一個想法『不要使用 DataReceived 事件，而自行用執行緒來檢查緩衝區』，這其實很類似在Socket 程式中利用Thread加上同步接收來達成非同步效果的方法，這篇就來討論如何來完成這樣的功能。

在使用DataReceived事件的時候要避免執行緒暴衝的狀況有幾個簡單的方式可以避免。

DataReceived事件的黑暗面源自於它自己的特性 -- 在次要執行緒上引發 DataReceived 事件，如果你曾經寫過通訊程式會發現一個現象，即使發送端只呼叫一次發送方法，接收端卻有可能會分很多次接收，問題的根源在於傳輸是需要時間的，所以有可能在接收緩衝區還沒收到所有資料前就讀取緩衝區，一個簡單的方式是你可以使用這系列文之前簡單的發送端 與接收端，然後去觀察你每次所收到的資料。

終於進入接收資料的開始，就從DataReceived事件來進入這個階段。
純接收的模型一般來講用DataReceived事件是很方便的，雖然它其實有一些毛病，我們暫且先拋開這些毛病，從最簡單的程式碼看起。