20190909

在有 wireless switch 特性的 Thin AP 無線網路服務中, 使用 IoT 裝置的注意事項

今天跟朋友吃漢堡王的時候聊到 IoT 裝置對 Thin-AP 的使用問題,因為很多 Thin-AP 架構為了效能最佳化的需求,所以原始的設計是把廣播封包全部攔截,控制器只針對需要的廣播風暴做轉送工作,就邏輯上來看就像是乙太網路交換器一樣。

通常要解決這樣的問題最快的方式是在特定範圍使用消費型的無線基地台做單點配置就可以解決,另外一個角度來說,IoT 裝置在有限的記憶體跟處理器規格設計下,針對單一 ESSID 有多重 BSSID 的狀況也是很極端,要不是死黏著一個 BSSID 不放,要不是 BSSID 一直輪跳網路一直瞬間斷線,這個時候可能的解決方案大概是找一個支援 wireless client 或者 wireless bridge 的基地台做乙太網路連線,這樣的問題可能相對簡單一點。

理論上基地台如果支援 wireless client 或者 wireless bridge 的話問題應該不會太大,只是這樣的東西可能比 IoT 裝置貴多了,入門款的無線網路基地台可能還比較便宜一點。

大部分的 IoT 裝置基本上都透過類似 Zero-configuration networking 的技術,像是 uPnP,SSDP, Bonjour,mDNS 等等。共同的特色在於利用廣播封包對區域網路內部的裝置告知自己的 IP,Hoetname,Service 等等。但是這樣也產生了很多問題。廣播封包會對區域網路的封包交換效能產生極大的影響,所以當電腦超過一台交換器實體連接埠數量的時候,就要開始做實體網路拓樸分割,避免廣播封包的數量太多變成廣播封包風暴,這個是有線網路連接的狀態。

同樣的問題在無線網路發生的時候,會變得非常嚴重,因為無線網路在同一個頻道範圍上面等於是單一一條網路線,跟有線網路交換器的每個連接埠是獨立的頻寬不同,所以在無線網路使用的時候,如果要同時間服務很多裝置,無線網路控制器必須要有效率地去判斷什麼封包需要被轉送,所以在無線網路控制器的設計上就會有一個需要被轉送的封包或者服務設定功能,在 Cisco WLC 控制器的設計而言,相關的功能就被稱之為 mDNS Snooping,WLC 會檢查所有 mDNS 相關服務的封包,然後針對管理者的設定去記錄特定的 mDNS 紀錄,再轉送到指定的無線網路介面上,所以一般有 mDNS Snooping 的設備通常也有 mDNS Proxy 的功能,在所有監聽 mDNS 的介面上面記錄並轉送 mDNS 的紀錄。

如果沒有設備支援大量 mDNS 監聽紀錄轉送功能怎麼辦,這個問題我也想過,這個時候就 GOOGLE,我就找到了一個專案叫做 Cluster,透過 gRPC 跟 mDNS 服務的組合,加上主從式架構做出一個監聽所有子網路並且共同維護同一份 mDNS 項目列表的分散式 mDNS ,如果你有需要在為了網路效能做子網路分割跟 mDNS 服務之間並存的狀況下維運你的基礎架構,我相信這個工具可以解決你不少問題。

Cluster
https://github.com/bah2830/cluster/blob/master/README.md
Controller node cluster management using gRPC and mDNS service discovery. Each node will watch for mDNS entries on the network. When the controller entry is found it will send a checkin message with it's details to the controllers gRPC service. From then on the controller and communicate with all nodes that have checked in.


Bonjour is Apple’s service discovery protocol which locates devices such as printers, other computers, and the services that those devices offer on a local network using multicast Domain Name System (mDNS) service records.
https://www.cisco.com/c/en/us/td/docs/wireless/technology/bonjour/7-5/Bonjour_Gateway_Phase-2_WLC_software_release_7-5.html


20190908

What is the purpose of the software development process?

在軟體開發週期的差異上,讓我感覺跟現在最大的不同,在於 20 年前左右我在用 BSD 轉 Linux 的那個時候,大概是 Slackware Linux 1.0,然後 Debian Linux 2.0 的那個時代。

我覺得那個時候的軟體開發重視的是支援功能,就是現有的軟硬體很多,怎麼樣周全的支援現有的軟硬體是那個時候 Linux 相關開發套件的重要問題,也是因為這樣我從 BSD 轉到 Linux 去。會棄用 BSD 的原因就是因為相對於 Linux 來說 BSD 的穩定度更好,但是真的要做伺服器以外的用途是有困難的,桌面應用環境不夠完整。那個時候比較重視穩定度,畢竟功能上都是軟硬體相關的服務。所以開發周期相對長,但是軟體的重大問題比較少,效能也相對穩定,不見得是快,有的時候就是跑不快然後只好花錢用硬體換。而且那個時候的軟體功能沒有這麼多,相對來說對開發人員而言算是一個小確幸時代。

現在的軟體開發週期給我的感覺比較像是沒有新功能沒有梗就要擔心沒人用,但是變成公開測試的模式,然後有一些在內部測試應該要解決的問題到了公開使用的階段才發現。現在的軟體開發應該比以前重視流程呀!但是為什麼發現問題的時候,低級的問題常常出現呢?我覺得問題的本質在於市場節奏感的強度優先於軟體安全性跟完整度的問題,多數的服務都走向消費性的概念,像是作業系統一年一定要有一個大更新,兩個小更新之類的這種概念,然後一個功能要做到完善的話大概要三個小更新或者是兩個大更新之類的。

另外一個現實是現實中的 CI CD 概念,其實有一個重大的盲點在於產品階段的使用者測試,因為 CI CD 階段在大部分的軟體服務中並沒有在其中插入所謂的黑箱測試,都是白箱測試,白箱測試其實有很大的盲點,這些盲點在最後上市之後的使用者黑箱測試階段會一次爆發。你說 Windows Insider Program 的參與者能不能算是黑箱測試人員,在我看來是不能算的,因為會參加這個專案的人基本上都對作業系統有一定的了解或者是目的。

黑箱測試的人員基本上只能就自己的日常基本操作去使用,去確認日常生活中原來沒有問題的事情在新版本的作業系統上有沒有問題,所以如果 Windows 10 1903 開始部屬了,如果應用程式比較常見而且不用太多高效能 API,像是 Office 之類的,可以在新的電腦上面直接部屬 1903 是沒有問題的。但是如果工作環境當中有用到比較小眾的軟體,可能就要往前推到 1809 或者是 1803 的版本上,因為不是所有的軟體開發商都可以跟得上作業系統更新的頻率。

所以現在的軟硬體更新,在我的角度來看,除非有重大的資訊安全漏洞需要處理,不然我都會很保守的等到那個軟體版本的支援周期結束才會更換成新的,或者是新的設備跟新的工作環境直接上新的版本也沒有問題,畢竟更換新的軟硬體環境本質上是沒有生產效益的,在避免影響生產流程的前提下,頻繁的調整軟硬體環境其實不是一個好的做法。如果是網路服務的話,我會偏好做一個版本上線服務之後,做相關的安全性跟功能跟新,提供使用者這個服務最短會支援多久,然後在同時把這個服務使用者的意見收集起來,做下一個版本的服務,但是我不預告下一個版本什麼時候會走到正式上線服務的階段,因為需求改變了,不同的需求沒有辦法用一樣的測試時間去保證有一樣的測試品質。

我必須再次說明,軟體開發跟服務開發的結果是要滿足使用者的需求,讓使用者花錢來買這個東西,CI CD 的概念在我的角度來看比較偏向是滿足軟體跟服務開發流程,還有公司產品預期上市流程用的,但是 CI CD 做好只是保證軟體應該會正常運作,但是不保證軟體真的滿足使用者的需求或者是使用者真的會按照開發人員的想法去使用軟體跟服務。

2007 年 8 月份微軟 tcpip.sys 全球更新導致 skype 全球大斷線那個事情我也是受害者,那個時候工作的公司有功能是用被更新的漏洞開發的,所以有一個月的時間大家在研究用什麼方法可以重新實作那個功能。有的時候你覺得是漏洞別人覺得是功能呀!那個時候 tcpip.sys 的更新是微軟幾乎是強迫派送的,所以沒有關閉更新服務的電腦基本上都會被重開機一次,所以那個時候最早的共享經濟服務 skype 就全球大斷線了。結果現在 skype 變成微軟的產品了,真的是商場上沒有永遠的敵人跟朋友呀。

現在的狀況就變成某一個雲端系統服務障礙,我都開玩笑說雲端打雷了,然後日常生活中的特定服務就全球故障,我們都以為雲端服務應該要比較穩定,終究其然我們只是把自己裝網路線電源線伺服器硬體的事情委託給別人做,然後系望這一套系統不要壞掉,然後以前習慣會作容錯系統的服務就還是繼續作容錯,以前沒有作容錯系統的服務上雲端還是一樣沒有作容錯,會掛掉的還是會掛掉,只是這個時候可以把責任外包說 GCP AWS Azure 掛掉了我也沒辦法這樣。

雲端好棒棒。

我對 Telegram 跟 TON 下一步的看法。

Telegram 其實掌握了人性的矛盾點,到底怎麼樣的隱私才能稱之為安全。 實際上對 Telegram 投錢的人應該是三教九流都有,不管是恐怖分子,毒梟,非政府組織,人道救援組織,甚至於政府情報單位。為什麼我會這麼說呢?因為自己開發一個通訊服務要驗證其隱密性非常困難,如果你的同行有人用了一個服務,然後你們的行業又非常重視保密性,那如果他用了半年一年人都沒事,然後你又找不到好的通訊解決方案的話,你會不會跟著用? 另外一個現實的事情是合法的事情不代表可以被攤在陽光下討論,非法的事情不代表這個事情真的有傷害的別人,每個地區國家都有不同的習俗跟法律框架,如果你要突破這些法律框架,那就必須要有一個對私人訊息群組不審查的通訊服務。 你問我說 TON 會不會成為一個新的電子交易憑證的框架,我個人的看法是這樣的,如果可以維持進入門檻不要太高的話,TON 跟 Telegram 的組合應該在特定的次文化會很流行,這些次文化共同的特色就是在特定地區國家有法律或者道德問題,或者是需要高度隱密性的狀態,但是這樣是壞事嗎?我不確定。因為好事情壞事情的定義是依照人當時的立場去看待的,但是通訊服務跟電子交易憑證其實是工具,工具是中性的。 我個人的邏輯上,我不認同用稀有資源作為資本去建立貨幣系統的概念,例如比特幣挖礦的概念,我比較希望是透過我們對這個制度的信任狀態去建立貨幣系統。我們出生的地區國家政府建立了一個基本的貨幣系統,我們需要跨國購物轉帳所以有了信用卡跟 PayPal 西聯匯款這些服務,到最後如果我們需要一個即時的電子交易系統,可能就是建立在區塊鏈的電子金融商品上面。 到時候的交易方式可能是以基於小時或者基於日的匯率,根據本地本國跟 TON 的匯率去計算 TON 的費用,然後 TON 就會成為全球電子金融系統的一個獨立框架。既有金融系統的詐騙跟帳戶盜用問題 TON 也是會發生的,只能說非政府監管的金融系統都是金融商品的概念,沒有政府保障也是高風險,需要用的時候再大量長期買進比較好。 轉過頭來,各位可以思考,為什麼比特幣最近行情這麼好的原因,是不是有特定地區國家有強力的資產轉移需求,然後特定地區國家的金融管制限制又很強呢?比特幣的漲勢都是一個波段一個波段的,只是有的事情是檯面上看得到的,有的事情是在檯面下運作的,TON 應該會比比特幣更通用一點,現在檯面上的電子交易憑證服務公司應該都感受到壓力了吧? 你說 Telegram 有沒有用到區塊鍊,我會說 Telegram 其實是最早用到區塊鍊或者相近技術概念的應用服務之一,因為分散式的身分驗證技術基本上就是區塊鍊的一個重點,只是那個時候的區塊鍊概念還沒有這麼清楚。而且就現在的角度來說,區塊鍊跟匿名一點關係都沒有,匿名這件事情只建立在電子錢包跟其他的公開資訊沒有建立關係之前,在電子錢包跟其他公開資訊建立關係之後,匿名的狀態就消失了。 就像是現在的雲端管理技術 Kubernetes 在叫 Kubernetes 這個名字之前,Google 給的是一個敘述這個字的一大串概念的解釋,然後在 Kubernetes 這個字本身也是政府 Government 單字的前身,所以你加入不同的 Kubernetes 雲端服務的話,等於是加入不同的政府架構,這個很有趣吧!所以實際上雲端服務跟中央集權是相結合的,所以使用雲端服務就等於去去中心化這個現實是已經確定的,所以大型的網路服務公司怎樣做去去去中心化這個事情就會是一個嚴肅的課題了。 創辦的公司被政府強行收購,「俄羅斯祖克伯」憤而發明加密通訊神器 Telegram https://buzzorange.com/techorange/2019/09/06/the-history-of-telegram/

20190904

40Gb-Thunderbolt3-USB4

USB 4 在我的認知上是 Thunderbolt 3 的實體層加上 USB 4 的協定層,不過被動線路只有 85 公分的長度實在是很慘,要更長就是主動式的光纖了。接下來 CPU 會內建 USB 4 指日可待,不過要低延遲的話,還是用 Thunderbolt 3 ,畢竟 PCIe 匯流排的反應時間比 USB 低得多。


本質上的問題是在於 Thunderbolt 跟 USB 要滿足的客群不同。


Thunderbolt 要滿足的客群基本上是高效能低反應時間的使用者,USB 要滿足的客群是消費型裝置的使用者,而且 USB 裝置的熱插拔裝置驅動程式已經很成熟了,但是 Thunderbolt 裝置做熱插拔這個事情其實到現在還是會遇到問題,所以 Thunderbolt 跟 USB 其實是互補的設計。實際上 Thunderbolt 裝置並沒有辦法像 USB 的設計一樣做頻繁的熱插拔,因為會遇到 Thunderbolt 服務當機的狀態,這個時候只能拔掉 Thunderbolt 裝置之後把電腦重開機,之後就會正常了。


實際上 Thunderbolt 3 的高效能低反應時間有其代價,第一代支援 Thunderbolt 3 的 Windows 筆記型電腦,如果用 i3 CPU 的話,可能會有跑不動的問題,因為 Thunderbolt 3 匯流排全速使用的狀況下,因為那個時候 i3 CPU 的效能不足,所以實際上那個 Thunderbolt 3 介面其實是不實用的,我相信在 USB 20Gb 跟 40Gb 的時代,USB 控制器一定會有硬體的卸載功能去降低 CPU 的負擔,但是 Thunderbolt 是 PCIe 裝置,所以所有的管理成本都會直接加在 CPU 上,然後因為要外接,所以還有一個 kernel message service 的成本,所以 Thunderbolt 沒有 i5 i7 CPU 的話基本上應該是不用期望效能的。


目前 Thunderbolt 3 的硬體規格授權,Intel 也已經在 2018 年完全開放了,不過就 PCIe 的驗證要求而言,短時間低價的整合型產品還很難看到,我們就再等看看吧!


讀者李先生表示:


感覺 USB 4.0 根本是半套版 TB3,Intel 平台將來乾脆直接內建 TB3 支援即可,反而讓 AMD 平台使用 USB 4.0 ( 不如 TB3 )