簡介

    在前篇文章，讀者使用重新傳輸處理傳輸錯誤。在這篇文章中，您將使用「確認」以改善前篇文章的方法。透過進行這項活動，您將針對網路中的錯誤控制，學習幾個關鍵的方法和通訊協定。

簡而言之，您將學到：

• 確認的概念
• 自動重覆請求的概念（ARQ）
• 「停止和等待」通訊協定

所以，您將需要：

• 2個micro:bit
• 一位隊友

背景

    前篇文章中，一則訊息被多次傳輸，無論是否接收裝置已收到先前的副本，但這樣太浪費資源了！您可以傳輸新的資訊而非重覆之前的訊息。而對於接收裝置而言，這亦為一種浪費，因為它需要花費時間、資源，丟棄重覆的訊息。為避免這樣情況發生，我們將介紹一個新的概念「確認」。

小知識：確認（ACK）

    確認是指，接收裝置傳回微小的訊息，以告訴傳送裝置它收到訊息了。傳送裝置便知道不需要重新傳輸，並且準備傳送下一則訊息。

    若傳送裝置沒有收到確認訊息，只有在這樣情況下，傳送裝置需要重新傳輸訊息。但傳送裝置需要等候確認訊息多久呢？這由Timeout決定。

小知識：Timeout

    Timeout是指，在傳送裝置放棄等候確認訊息前，允許時間經過的總量。

    換句話說，如果傳送裝置沒有於一次Timeout期間收到確認訊息，它將會決定資料包必定是被丟包了。而確認訊息被用於錯誤控制的方法，稱為「自動重覆請求（Automatic Repeat Request，ARQ）

小知識：自動重覆請求（ARQ）

    自動重覆請求是一項錯誤控制的方法，它使用確認訊息和Timeout，以重新傳輸資料包。直至傳送裝置收到確認訊息，或時間的最大額度被達到，重新傳輸會持續進行。

    ARQ被應用於網際網路和行動網路，其最簡單的形式是使用「停止和等候」ARQ通訊協定。

小知識：停止和等候ARQ通訊協定

    在停止和等候ARQ通訊協定中，傳送裝置：

1. 傳送資料包
2. 等候確認訊息（ACK），或經過一次Timeout期間後，放棄等候。
3. 若經過一次Timeout期間，採取步驟1。
4. 若收到確認訊息（ACK），採取步驟1。

     在「停止和等候」通訊協定中，除非傳送裝置收到先前資料包的確認訊息，否則它無法傳送新的資料包。下方的圖例顯示一個成功重新傳輸的範例。傳送裝置傳送「Hello」，而接收裝置以確認訊息回應。傳送裝置在Timeout結束前，收到確認訊息，所以，傳送裝置知道資料包被正確收到。現在，傳送裝置可開始傳送另外一段訊息。

     現在，讓我們看看一些錯誤的例子。下方的圖例顯示，從傳送裝置發出的第一則訊息被丟包了，所以，接收裝置並未傳送確認訊息。當Timeout終止時，傳送裝置並未收到確認訊息。所以，傳送裝置重新傳輸訊息，而第二次的傳輸成功了，並且傳送裝置及時收到確認訊息（在Timeout終止前）。

      下方的圖例則顯示一個例子，即來自傳送裝置的訊息已被接收裝置收到，但來自於接收裝置的確認訊息被丟包了。一樣的是，當Timeout終止時，傳送裝置並未收到確認訊息，所以，它重新傳輸一次訊息。接收裝置收到重覆的訊息，一樣傳送確認訊息。這次，確認訊息成功被傳達，並且傳送系統可以運作如常。

    這些例子顯示，停止和等候ARQ通訊協定，相當好地處理資料包和確認訊息被丟包的狀況。然而，這個通訊協定總是有效嗎？下方的圖例顯示會發生的問題，即當訊息或確認訊息被延遲。換句話說，Timeout在確認訊息可被收到前便終止了。在這個例子中，當傳送裝置傳送「Hello」，接收裝置收到這則訊息，並且傳送一則確認訊息回去，但傳送裝置的Timeout，在收到確認訊息前便終止了。所以，它重新傳輸一次「Hello」，然後，傳送裝置收到被延遲的確認訊息。但這則確認訊息是針對哪一次「Hello」而發送？第一次或第二次？這樣的情況也混淆了接收裝置，究竟第二次的「Hello」是新的資料包或是重覆的資料包？

       為解決這樣的問題，停止和等候ARQ通訊協定需要使用「序列數字」。

小知識：序列數字

    一個/組序列數字是由傳送裝置挑選的一個/組數字，被包含於資料頭中。當接收裝置傳送確認訊息時，確認訊息包括下一組序列數字，以告訴傳送裝置，它收到先前的資料包了，並且準備接收下一個資料包。

    例如，當傳送裝置傳送「Hello,0」，這便是「Hello」訊息包含著一個序列數字0，當收到資料包時，傳送裝置會傳送「確認訊息,1」，意指：「我收到了資料包0，接下來，傳送給我資料包1」。我們不會在這篇文章的任務中，使用序列數字，但讀者可以試著增加訊列數字，作為延伸練習。

來寫程式囉：停止和等候通訊協定

    為撰寫「停止和等候ARQ通訊協定」的程式，您將與一位隊友合作。如同於《探索micro:bit的奧妙：處理錯誤之重新傳輸》一樣，您將使用客製化的錯誤廣播程式積木，以傳送帶有錯誤的訊息。通訊為單播，所以，您仍將於訊息中，使用來源和目的地的位址。並且別忘了，您的接收裝置需要確認，是否接收到訊息的位址，和接收裝置一樣。

任務一：設計您的資料和確認資料包

描述：在您可傳送和接收任何資料包前，首先，您將決定您的資料和確認資料包應看起來如何。

指引：與同伴討論，您應該至於資料包中的最小資訊是什麼。為您的資料和確認資料包，創造兩個字串的變數。請使用JavaScript程式積木編輯器中的文字（Text）程式積木。

任務二：Timeout和重新傳送

指引：為了撰寫停止和等候通訊協定，您需要一個Timeout的機制。在每次重新傳輸後，您需要等候確認訊息或Timeout。您需要決定的是，Timeout應有多久。

指引：為進行此任務，您可從頭開始進行，或從《探索micro:bit的奧妙：處理錯誤之重新傳輸》的任務中，改變程式碼以供擔任傳送裝置的micro:bit使用。在傳送裝置端，請為如何等候確認訊息撰寫程式。在「基本（Basic）」程式積木工具列中，「暫停…毫秒」程式積木對Timeout機制會起很大作用。如果您的暫停，在您收到確認訊息前終止，那麼您將重新傳輸資料包；若您在暫停結束前就收到確認訊息，您將記得這則訊息，當暫停終止時將運用這則確認訊息，以傳送下一則訊息。

    為測試這個程式，您也需要為接收裝置撰寫程式。接收裝置需要針對每個收到的資料包，傳送確認訊息。

任務三：測試停止和等候通訊協定的可靠性

描述：在這項任務中，您將實驗您所撰寫的停止和等候通訊協定。為進行實驗，您將在傳送裝置端，增加一個計數器，以計算重新傳輸的次數；而於接收裝置端，您亦需要一個計數器，以確認訊息在重新傳輸的影響。

指引：決定暫定的時間。使用停止和等候通訊協定，傳送五個數字至您同伴的micro:bit。您將以設定好的錯誤值（25和75），運作這項通訊協定，然後重複每項實驗三次。

    在下方的表格中，「重新傳輸」是指，一個資料包需要被重新傳輸的次數。「重覆」是指，接收裝置收到不需要的重新傳輸的次數。所以，讓我們假設，傳送裝置送出下列資料：

111223444455

    有7次重新傳輸，而接收裝置收到下列資料：

1223455

    接收裝置收到兩項重覆。填入表格第一行的是個範例，請使用您的實驗結果，以填滿剩餘的表格。並藉由比較重新傳輸和重覆與同伴討論，在處理錯誤上，這個通訊協定的效能如何？