發表文章

[RESTful] Java Servlet API Server ~2 (helloworld)

圖片
在 上一篇文章 中, 我們建立了 Servlet 的編譯環境, 接著, 我們就從最簡單的 helloworld 開始, 介紹如何撰寫第一支 Servlet 程式. 以下是編譯環境中的路徑: 網頁根目錄: /var/lib/tomcat8/webapps/ROOT/ tomcat8 library 目錄: /usr/share/tomcat8/lib/ tomcat8 log 目錄: /var/lib/tomcat8/logs/ 首先, 我們要先定義 Servlet API 的入口, 此文件位於: /var/lib/tomcat8/webapps/ROOT/WEB-INF/web.xml 我們將內容填入如下: <web-app> <servlet> <servlet-name>HelloWorld</servlet-name> <servlet-class>HelloWorld</servlet-class> </servlet> <servlet-mapping> <servlet-name>HelloWorld</servlet-name> <url-pattern>/HelloWorld</url-pattern> </servlet-mapping> </web-app> 在文件中, 定義了 API 的路徑 ( servlet-mapping ) 以及對應的 Servlet 程式 ( servlet ), 透過這兩個設定, 我們就建立了 Servlet 與 API Server 之間的呼叫關係, 接著, 我們進行 helloworld 的 Servlet 程式撰寫, 以下為範例: import java.io.*;  import javax.servlet.ServletException;  import javax.servlet.http.*;  public class HelloWorld extends HttpServlet  {       static ...

[RESTful] Java Servlet API Server ~1 (Servlet 介紹與 tomcat8)

圖片
在 之前的文章 中, 介紹了如何用 node.js 快速建立 API Server,  然而, 由於效率問題, node.js 並不是一個穩定的架構用以作為 API Server, 同時, JSON Server 本身實作的架構, 依賴對檔案的讀寫, 對於大量存取的 API 實作來說, 容易造成 IO 的消耗, 考慮到上述因素, 我們便開始研究其他 API Server 的實作方式, 在本篇介紹中, 便以 Java Servlet + tomcat8 作為實作的平台. 關於 Java Servlet 是 Java 語言中的一種特殊類別, 用 Java 編寫的伺服器端程式, 可以透過與使用者的互動, 動態產生網頁, 對於 API Server 來說, 主要的功能則是繼承自: javax.servlet.http.HttpServlet 另一方面, tomcat 則是一開源的 HTTP 伺服器, 支援 Servlet 與 JSP, 在我們的實作中, 我們使用 ubuntu 16.04 作為基礎的作業系統, 並使用 tomcat8 作為網頁伺服器 (參考: 此文 ). 安裝 tomcat8 的開發環境: sudo apt-get install tomcat8 sudo apt-get install tomcat8-docs tomcat8-examples tomcat8-admin tomcat8 的開啟/關閉/重啟: systemctl start tomcat8 systemctl stop tomcat8 systemctl restart tomcat8 安裝好 tomcat8 之後, 會使用預設的服務埠 (8080), 連入: http://127.0.0.1:8080 之後, 我們可以看到下方頁面: 其中, 紅框處為網頁目錄的位置,  此目錄也是我們之後開發 Servlet 程式的相對根目錄, 藍框處標明了套件安裝的路徑, 其中, 這兩個路徑我們之後都還會用到, /usr/share/tomcat8/lib/ 有用以 compile 的 library, /var/lib/tomcat8/logs/ 則保存紀錄檔, tomcat8-examples 則提供一些 Servlet 的範例程式, 可以參考. 我們在此整理一下開發環境...

LTE筆記: 5G Time Sensitive Communications ~ 802.1AS - Time Propagation

圖片
在 上一篇文章 中, 我們介紹了 802.1AS 如何選擇同步源, 並顯示在一個大型網路中, 如何標定每一個實體埠的角色. 在這篇文章中, 我們將由透過訊號源角色定義的網路拓譜出發,  研讀在此網路拓譜下, 802.1AS 如何提供更精密的同步, 我們先從下圖出發: 來自:  https://www.ieee802.org/1/files/public/docs2008/as-nfinn-fast-master-select-0408-v2.pdf 在圖中, 我們定義了不同埠的角色, 根據這些角色, 我們就可以得知同步訊號的流向, (簡單來說, Master是同步訊號流出, Slave是同步訊號流入) 在定義完每一個埠的不同角色後, 我們可以根據封包的流入/流出定義相對時間, 如下圖所示: 來自:  https://www.ieee802.org/1/files/public/docs2008/as-nfinn-fast-master-select-0408-v2.pdf 在上圖中, 我們可以看到對於時間同步產生延遲的三個因素, 第一, 封包的處理時間, 此時間為節點上處理所需要的時間, 和節點硬體相關, 第二, 封包的排隊延遲, 此時間和每個埠上的流量相關, 越多封包會有越高延遲, 第一個延遲在相同路徑的前提下, 可以透過 NTP 估測並抵銷, 第二個延遲則無法在 NTP 下進行處理. 在 802.1AS 中為了提供更精確地同步機制, 使用硬體計算延遲時間, 其方法為對每一個封包打印進入時間 (T_in) 以及送出時間 (T_egr), 透過其兩個時間差, 以及傳送到該節點的連結延遲 (T_link), 此延遲時間可以利用類似 NTP 的方式估測, 根據上述的量測量以及同步源的時間 (now), 更新送出去的時間 (now'), 此時間就會變成下一節點用以同步的時間. 在 802.1AS 中, 透過每一個節點更新更精確地同步時間 (now'), 對於每一個節點, 都可以參考上一個節點的時間 (now), 因此, 此同步問題就減化成兩節點間的同步問題, 當然, 此描述稍微簡化了 802.1AS 的機制,  事實上, 802.1AS 還會根據震盪器時脈誤差,  提供更精確的時間 (now') 估測.

LTE筆記: 5G Time Sensitive Communications ~ 802.1AS - Grand Master Selection

圖片
在 上一篇文章 中, 我們介紹了 NTP 同步機制, 考慮到 NTP 機制的簡單且能以效率的完成同步, 此機制被實作於電腦網路中, 透過指派同步的時間伺服器,  Windows 和 Linux 就可以利用 NTP 相同機制處理同步系統時間, 此同步的系統時間, 除了顯示於使用者, 也用以防範網路攻擊. 然而, NTP 機制有兩個主要的缺點, 第一, 當有許多同步訊號源 (時間同步伺服器) 時, 要向哪一個對時? 第二, NTP 協定假設封包來回的時間對稱, 這個假設在區域網路中成立 (來回路徑一致, 延遲也會相同),  但在大型網路中, 封包來回的路徑可能不一, 也會造成不同程度的延遲. 在 802.1AS 中就針對這兩個限制進行一些調整, 這邊先提及一下, 802.1AS 的前身是 IEEE 1588, 也稱為 PTP (Precision Time Protocol), 所以當看到 IEEE 1588 和 PTP 時, 事實上, 就想像其類似於 802.1AS 的機制, 802.1AS 針對多個時間源的問題, 稱為: Grand Master selection, 在此機制下, 時間同步伺服器透過發出 Announce 訊號通知, 並有兩個行為: 第一, 在沒有聽到更好的 Announce 訊號時, 發出 Announce 訊號, 第二, 在收到更好訊號源發出的 Announce 訊號時, 作為被同步的裝置, 透過 Announce 訊號的傳播, 便可以選出網路中最好的同步訊號源, 並保有一定的強韌性, 如下圖所示: 圖片生成自:  https://www.ieee802.org/1/files/public/docs2008/as-kbstanton-8021AS-overview-for-dot11aa-1108.pdf 值得注意的是, 在 802.1AS 中, 所謂好的同步訊號源,  可以根據管理者的優先權設定, 以及時間訊號的來源 (例如: GPS) 進行比較, 會將自我認知的好壞, 轉換成一向量 (越小越好), 放在 Announce 訊息中, Announce 訊息中也會包含訊號源的 MAC 位址, 作為識別, 透過此選擇的機制, 網路中的個節點將產生一個樹狀結構 (如下圖),  此樹狀結構將...

Single Root I/O Virtualization (SR-IOV) 介紹

圖片
在虛擬化技術中, 最一開始的技術從硬碟開始, 之後是 CPU 與記憶體的虛擬化, 最後則慢慢走向網路以及各種周邊裝置虛擬化, 其中, 在網路虛擬化的部分, 一開始以軟體方案 (OpenVSwitch) 為主, 此類方法依賴 Host Machine 上的程式進行資料的轉傳, 限制了 Virtual Machine 上的網路的效能. 為了增進其他裝置 (CPU, 記憶體, 硬碟) 的虛擬化程度, Intel 提出了 SR-IOV (Single Root I/O Virtualization) 的機制, 目標是透過對 PCIe 介面的虛擬化, 使一個裝置可以服務多個虛擬機, 其中, SR 代表只有一個 Host Machine, 也就是一般家用電腦狀況, 相對應的有所謂的 MR-IOV (Multi-Root I/O Virtualization), MR-IOV 適用於刀鋒伺服器 (Blade Server) 架構, 在此架構下, 多張刀鋒伺服器共享同一機櫃之 IO 支援 (如對外網路), 因此會出現多台 Host Machine (Multi-Root) 對單一 IO 裝置的存取需求. 考慮到 MR-IOV 可視為 SR-IOV 的延伸, 我們著重介紹 SR-IOV 的部分,  在 SR-IOV 中, 將原本提供 Physical Function (PF),  切割成多個 Virtual Function (VF), 而每個 VF 對應到不同的虛擬網卡, 其框架可以以下圖表示: 來自:  https://www.marvell.com/content/dam/marvell/en/public-collateral/ethernet-adaptersandcontrollers/marvell-ethernet-adapters-fastlinq-concurrent-nic-partitioning-sr-iov-technology-brief-2018-07.pdf 由上圖中可以發現, SR-IOV 需要裝置本身的支援 (PF和VF的功能提供), 以及虛擬層 (hypervisor) 的支援, 其中, PF 可以視為原本裝置的 driver 支援, 負責和 hpervisor 進行溝通, 當虛擬機生成後, 就直接透過 ...

LTE筆記: 5G Time Sensitive Communications ~ NTP 協定

圖片
在5G工業物聯網的應用中, 其中一項重要的應用就是低延遲網路, 低延遲網路可用於智慧工廠中, 特別是對於精密控制的工業機台, 在 3GPP 的架構中, 這些應用屬於工業 4.0 的範疇, 並將需要精密時間同步的工業物聯網服務稱為 Time Sensitive Communications (TSC), https://www.3gpp.org/news-events/2122-tsn_v_lan 其中, 用以支持精密同步的通訊協定為 802.1AS. 802.1AS 繼承自 IEEE 1588v2, 也稱為 PTP (Precision Time Protocol), PTP 的基本同步架構沿襲自 NTP (Network Time Protocol), 但考量了大型網路的複雜度, 對於網路中介裝置 (Bridge 或 Switch), 加入修正的機制, 以及對時鐘 (Grand Master, GM) 的選擇機制, 主要目標在於服務無法以 GPS 對時, 但需要比 NTP 更精確同步的場域, 其同步精確度的設計為 500 ns (七個網路節點, 時脈飄移小於 1PPM). 考慮到 802.1AS 是源自於 NTP 的設計, 我們在此篇文章中, 先介紹 NTP 的對時設計,  在 NTP 的基本想法中, 透過兩裝置封包交換, 計算兩者的通訊延遲, 並透過此延遲時間的估算 (下圖的 \delta), 用以同步兩個裝置的時間, 來自:  https://en.wikipedia.org/wiki/Network_Time_Protocol 在NTP中, 假設兩個裝置互相傳送封包 (上行/下行) 的延遲一致, 因此 \delta = ((t3-t2)+(t1-t0)) = 65 (ms) \delta 代表的是藍色部分的漂移時間 (propagation time), 其值除以二就代表著封包從 Server 到 Client 所需的單向漂移時間, 因此, Client 可以參考從 Server 送出的參考時間, 加上單向漂移時間, 用以作為本地校正的時間數值. 在 NTP 的架構下, 兩點之間的時間同步不成問題, 因為在同一個區網下, 同一網路媒介下, 上行和下行的時間差異不大, 但對於一個大型網路而言, 則會有以下兩個問題: 當有多個裝置想當...

LTE筆記: 3GPP 中的企業專網 (Non-Public Network, NPN) -2

圖片
在 上一篇文章 中, 介紹了企業專網, 以及其在 3GPP 中的角色以及兩種不同的應用情境. 接下來, 我們將從其佈建的方式, 詳細介紹其不同實作方案的差別, 本文主要的圖表和內容來自:  https://www.netmanias.com/en/post/blog/14500/5g-edge-kt-sk-telecom/7-deployment-scenarios-of-private-5g-networks 這篇文章詳細的敘述了7種不同的企業專網架構, 其中, 最為有趣的是 6 和 7 兩個韓國 SK 電信的實作案例. 本文專注於一般性架構 (前5種) 不會談到, 有興趣可以進入連結詳讀. 在之前介紹中, 我們說明了企業專網可以分成兩大類, 第一類是由場域主自行佈建, 維護從基地台至核網所有 5G 單元 (如下圖左), 按照實施者的不同, 在原文中拆成兩個方案討論. 第二類是由電信業者佈建, 此類專網會在一定程度上和電信業者的網路進行整合, 共享網路中的部分元件, 並使用網路分層 (network slicing) 的技術, 來達成場域主對安全性的需求 (如下圖右),  在此架構下, 我們將分成 3 種不同方案進行說明. 來自:  https://www.netmanias.com/en/post/blog/14500/5g-edge-kt-sk-telecom/7-deployment-scenarios-of-private-5g-networks 首先, 是方案一和方案二, 此兩方案在原文中的差異只有實施者是場域主或是電信商, 在網路架構上完全一致, 都是整套的獨立 5G 網路 (黑色部分),  並和電信商的 5G 網路 (藍色部分) 沒有任何實體上的重疊. 方案一, 二: 來自:  https://www.netmanias.com/en/post/blog/14500/5g-edge-kt-sk-telecom/7-deployment-scenarios-of-private-5g-networks   考慮到兩邊網路獨立, 在這兩個方案中, 企業專網必須有專屬頻譜 (圖中的 Local 5G freq.) 將墊高建置成本, 但另一方面, 由於企業專網的網路為實體上獨立, 因此, 有最高等級的...