# Interview Questions
---
### Question 1:
Tell me about a time when you took on something significant outside your area of responsibility. Why was it important? What was the outcome?

#### Situation:
在無人機的網路架構上，為了網路線路的備援，在物理線路上使用環狀網路的方式串連多個 Switches。

如示意圖所示，中間的 switches 在物理上形成迴圈。如此可以在迴圈中某條網路線斷線時，保持整個網路連通。
然而在網路拓樸上，必須保持邏輯上沒有迴圈。因此 switches 會執行 Spanning Tree Protocol(STP) 互相溝通，以完成無迴圈的網路拓樸。

每當網路系統上有新的模組接上 switch、網路線斷裂、某 switch 斷電/重新上電等，導致物理網路拓樸改變的時候，整個網路上的 switches 會重新進行 STP 的計算。計算過程中，整個網路是暫態不穩定的。也就是說可能短暫存在迴圈、有機會產生短暫網路風暴。

>網路風暴：同一個封包在迴圈上一直被傳送，造成瞬間出現大量相同封包。

本次的問題發生在無人機上的==飛控模組==。由於 switch 因為機上供電不穩、大功率射頻干擾等原因，出現重新計算 STP 而導致有機會出現網路風暴。由於飛控模組採用較簡單 RTOS 系統，在網路軟體端保護不足。因此很容易因為大量封包導致接收封包的 thread 異常。

#### Task:
我的主要職責為設計整個網路架構與實作通訊整合模組軟體。

飛控模組屬於機上重要模組。一旦在任務中故障，則必須立刻返航且任務失敗。每次任務失敗後，必須進行檢討、解決失敗原因，才能進行下次飛試。尤其飛控模組屬於直接影響飛安的模組，任何瑕疵都需要慎重看待。

飛機上的 switches 屬於外購件。由於電力不穩等，造成 STP 重算的行為其實並非 bug，switches 會在完成 STP 後恢復穩定。一般帶有 Windows/Linux 的電腦，通常都能抵抗某種程度的網路風暴。

本次任務主要協助解決「因網路風暴造成飛控模組失效」問題。解決問題的方式分成兩部份：
* switch 端：找參數設定等方法，讓 STP 收斂加速，以降低網路風暴的機率
* 飛控模組端：優化接收 thread 的程式

#### Atction:
Step 1: 根據蒐集到的 log 判斷飛控模組是因為瞬間收到大量封包導致異常
* 飛控 log 顯示 buffer overflow。模組的網路相關 error flag 被拉起
* switch 的監控出現短暫 ping 不到某 switch 的現象
* 綜合判斷，物理網路拓樸改變。一定有 STP 重算的行為

Step 2: 在實驗室想辦法重現問題
* 故意重複對同一個 switch 開關電多次，製造重算 STP 的行為
* 經過多次實驗，有機會觸發網路風暴 (用 wireshark 監控瞬間封包量)
* 配合飛控模組聯測，確認可打壞模組程式

Step 3: 尋找加速 STP 收斂的方式。
* 在無法避免 STP 重算的前提下，找出可以快速收斂的設定
* 由於收斂加快，出現網路風暴的機率大幅降低。即使出現網路風暴，瞬間的封包量也大幅減少。

Step 4: 協調飛控模組增加 buffer size
* 在允許範圍增加 buffer size，可以降低 overflow 機會
* 一起討論其他 thread reset 方法

Step 5: 在通訊整合模組中增加 sniffer 監控程式，在飛試過程中蒐集網路資訊，確保網路信任度。

#### Result:
* 找出問題，在實驗室設計出可以重現問題的手段
* 透過修改 switch 的設定改善問題。量化結果如下：
| Column 1 | 修改前 | 修改後 |
| -------- | -------- | -------- |
| 網路風暴機率 | 1次/50次 | 1次/2000次 |
| 瞬間封包數 | 20,000 ～ 60,000 | 1,000 ～ 3,000 |
* 修改後 1/2000 大約的估算
* 實驗一次花費時間約 30 秒
* 我總共做了約 3 天，一天抓 6 小時，只出現 1 次。
* 在原系統中埋網路監控程式，用於監控飛試過程中網路健康度與飛試後數據分析

---
### Question 2:
Give me an example of a tough or critical piece of feedback you received. What was it and what did you do about it?

#### Situation:
在無人機上，一般會有 2~5 種資料鏈路。例如大流量的主鏈路、小流量副鏈路、長距離但高延遲的衛星鏈路等。

最初的資料傳輸規劃是透過 UDP unicast 的方式完成上下傳。如此只要在系統設計之初，將各種資料靜態的分配到各種鏈路上，再分別對每個鏈路的頻寬進行監控並動態調整資料量，以避免無線鏈路因頻寬不足而壅塞即可。

隨著專案進行，發現控制命令僅透過單一特定鏈路傳輸時，掉封包率不可接受。開始朝是否可以把一個封包同時往多個鏈路傳，以此達到降低掉封包率的方向設想。

之後專案需求更進一步，希望在無人機進行任務的過程中，對於特定的資料，可以隨時動態決定傳輸的鏈路。例如：影像走主鏈路、聲音走副鏈路、控制資料同時複製到三個鏈路下傳等。鏈路的選擇須在飛試過程中，根據無線鏈路的品質、頻寬，自動調整切換。

#### Task:
以控制命令為例。假設有 Link_A、Link_B、Link_C 三種無線鏈路。專案需求為「可以任意決定命令下傳要走哪一種組合」。任務目標變成找出達成該需求的實作方法。

假設在三種鏈路下，總共有 7 種組合：
* A
* B
* C
* A, B
* A, C
* B, C
* A, B, C

#### Action:
Step1: 首先，直覺的想法是讓 ==通訊整合系統== 在應用層把資料收下來再轉發。做了一個樣板程式後，由於延遲太高放棄該作法。

Step2: 走群播。遇到了以下問題：一般的群播規則是利用 unicast routing table 決定群播路線 (RPF check)。因此很難讓不同資料走不同的鏈路組合 (因為都是看同一個 routing table)。

Step3: 經過一段時間研究。最終利用 static muticasting route 加上 MUX/DEMUX 的想法完成任務
* 群播路徑除了看 unicast routing table 外，可以額外設定一些靜態的強制路徑 (static multicasting route)
* 選了 `230.1.1.X where X = {1,2,3,4,5,6,7}` 當成七組靜態路徑的 IP
* 事先在 switch/router 的設定上，把靜態路徑規劃好。
> 補充：
> 其中，router 的設定有經過一番研究。因為在作法上違反一般群播設計規則。
>
> 一般群播規則中，router 間會互相溝通，以確認雙方不會收到相同封包。這是因為在一般的網路設計上，收到相同封包等於頻寬浪費。如過 routers 經過溝通後，發現雙方都收到相同封包，則會有規則讓其中一方不再收資料。
>
> 在本任務中，反而需要各 routers 繼續收相同封包，以降低掉封包機率。因此在 router 上把互相溝通的 protocol 關掉。
* MUX 的想法：改變 destination IP ，則可改變傳輸路徑
* bit0 of X 表示 Link_A 走或不走
* bit1 of X 表示 Link_B 走或不走
* bit2 of X 表示 Link_C 走或不走
> Eg:
> 同時傳 {A, B, C} 則 IP = 230.1.1.7 <-- 7 = 0b111
> 同時傳 {A, B} 則 IP = 230.1.1.3 <-- 3 = 0b011

#### Result:
在這個任務中，主要是實現專案要求的功能，並確認路徑切換速度可達到需求。經過這個設計後，路徑切換直接等於改 destination IP，因此切換幾乎是瞬間，非常快速。

補充：
對於無人機上的裝備而言，並不需要記這七組 IP。裝備的資料統一發送給==通訊整合模組==，再由整合模組以 NAT rule 的方式切換群播 IP。因此，即使之後 IP 改動或規則改動，都只須在整合模組進行軟體修改即可。