發表文章

目前顯示的是 10月, 2014的文章

我對 OpenFlow APP 的看法

會寫這篇文章最主要的理由在於,我發現很多人(包含我自己的長官以及眾多的指導委員)對於 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: Shared Memory Example

圖片
我個人比較喜歡的 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