Start a New Journey

會寫這篇文章最主要的理由在於，我發現很多人（包含我自己的長官以及眾多的指導委員）對於 OpenFlow APP的看法和我不一樣（這是客氣的說法，其實是 我認為他們的想法是錯誤 的）。所以囉，我決定整理一下自己的想法並寫在這裡，希望有興趣的人可以一起參與討論（雖然沒多少人看吧），一方面可以檢討自己的想法；二方面可以宣傳自己的理念。在這邊要先說明一件事，SDN 是一個概念而非實作上的技術，因此幾乎所有的東西都可以套入 SDN 的概念，因此我在這裡不談 SDN APP，而只單單著重在 OpenFlow APP。 很多人都期待 OpenFlow 可以帶來新的網路應用服務，well ... 單單這件事就有點問題，OpenFlow 算是一種 網路基礎建設的新型態架構 ，那麼我要問問，網路基礎建設所負責最主要的功能是什麼？答案很簡單，就是確保網路中的用戶端設備彼此之間能夠順利的連通，不管是 L2 switching 或是 L3 routing，那我們回到最基本的問題，請問目前的網路設備（我是指 L2/L3 的 switch 和 router）沒有辦法達成這一類的功能嗎？答案是，當然可以，不然我們現在用的網路是假的嗎？既然如此，那使用 OpenFlow 到底有什麼好處？使用 OpenFlow 最大的價值在於，我可以用新的想法來處理 L2 switching 和 L3 routing，藉由新的巧思，來達到比過去更好的網路效能或是使用率。有沒有例子？最簡單的一個例子就是 Broadcast 的封包處理概念，相關的細節可以參考下面的連結。 如何利用 OpenFlow 打造一個「無廣播」的網路環境 在這裡我可以斷言， 如果使用了 OpenFlow 的架構卻在思考網路問題上停留在傳統網路的思維，下場是網路的效能只會變得比過去還差。 現在面對的問題是，很多人問說，我可以不可以用 OpenFlow 來做到一些網路應用服務功能，如 Firewall、IDS/IPS 等，然後說用 OpenFlow Switch 會比較便宜，他們的理由是硬體規統、功能統一化，而且不用被網路大廠所把持。事實上，我也看到有台灣廠商投入在這一塊的發展（如果他們問我的話，我一定會加以勸阻），為了不想惹麻煩上身，姑且保留公司名稱不提。我為什麼認為這種發展方向是有問題的呢？第一， 你會期待網路基礎建設中每台設備都...

我個人比較喜歡的 IPC 技術是 Unix Domain Socket，因為可以 統一透過 File Descriptor 的處理機制來進行管理 ，如 epoll 或是 select 等。但即便是這樣，還是很多人會跟我說：「你有考慮過 Shared Memory 的方法嗎？效能應該會比較好唷。」我當然知道囉，不過隨著年紀增長，已經不再像以前一樣汲汲於效能上微小的差異（I mean ... 人的感受程度），而會把開發、維護的容易程度放在考量的第一位。所以我的第1選項目前都是：Unix Domain Socket，不但如此，之後也很 容易直接改成網路的 socket 程式 ，何樂而不為。但因為以後可能還是有遇到必須使用 Shared Memory 的情況，所以還是寫篇文章來紀錄相關的資訊。 Shared Memory 的 IPC 方式，顧名思義，就是兩個 Process 直接存取同樣一塊的記憶體空間。一般來說，兩個獨立的 Process 都會有各自的 Virtual Memory 位址管理，彼此之間是無法互相存取到的。而使用了 Shared Memory 的機制，系統核心就會準備一塊記憶體位置並讓兩個 Process 都能互相存取。用下圖可以表示 Shared Memory 和 Unix Domain Socket 的不同： 上圖左邊雖然是寫 Unix Domain Socket，但其實用 lo 來做 UDP socket communication 也是同一類。我個人認為上圖很明顯的說明了兩種方式的效率差異。在網路上看到一篇很不錯的效能比較文章，連結如下： Tcp Socket vs. Unix Domain Socket vs. Pipes vs. Shared Memory 這個網頁只有一個小缺點， 他不應該用 TCP Socket 來比較而應該採用 UDP Socket ，理由是 TCP 的 Overhead 大於 UDP，而本機端的溝通應該用不到那些機制。考量到外部網頁連結不一定會持續存在，因此我將相關的圖節錄如下： 接下來就是撰寫範例程式了。在這裡會撰寫兩隻程式，一支負責傳送資料，另外一支負責接受資料。範例的參考連結在下面： http://www.cs.cf.ac.uk/Dave/C/node27.html...