UDP vs TCP：速度與可靠性的取捨 TCP 保證可靠、有序、無重複傳輸，開銷大。UDP 不保證送達、不保證順序，但速度極快，適合語音、遊戲、報時等容忍少量

傳統 CGI 架構痛點 客戶端無驗證，錯誤資料往返浪費頻寬。 CGI 程式需處理所有邊界情況，產生 HTML 回應頁，伺服器負載重。 使用者在頁面間跳轉，體驗

為何選擇資料報而非 TCP UDP 無連線特性讓單一 DatagramSocket 即可監聽所有客戶請求，無需多執行緒併發控制，也避免多執行緒寫入同一檔案的鎖定

Applet 架構與執行緒模型 NameSender 實作 Runnable，單一類別完成 UI、發送、接收。UI 含 Email 輸入框、送出按鈕、兩個狀態標

專案目錄結構 webstart/ ├── images/ # JNLP 定義的圖示 ├── jar/ # 打包後的 jar 檔 ├──

CPU 佔用問題 伺服器端持續阻塞於 DatagramSocket.receive()，在 Java 1.1 早期實作中會導致 CPU 空轉（忙碌等待）。雖可用

Java 呼叫 CGI 的三大優勢 客戶端驗證：Applet 先行檢查資料格式，減少無效請求浪費頻寬與伺服器負載。 攔截回應：直接讀取 CGI 輸出串流，無需

URL 編碼規則 查詢字串格式：name=value&name2=value2。空格以 + 表示；特殊字元（&、=、% 等）以 %XX 十六進位

Applet 介面與驗證邏輯 NameSender2 提供姓名、Email 兩個輸入欄位。按鈕觸發 action()： 檢查姓名含空格（至少名+姓）。 Ema

可重用 CGI 解析元件：Pair 與 CGI_vector 利用 C++ STL vector 與模板特化，建立型別安全的 CGI 解析類別： Pair：封

GET 的瓶頸與 POST 的解法 GET 將資料放入環境變數 QUERY_STRING，長度受限（約 200 字元）。POST 將編碼後的查詢字串透過標準輸入

資料庫 URL 三要素 jdbc:<subprotocol>:<database_identifier> jdbc：固定前綴。 sub

五步驟建置可執行的 JDBC 環境 尋找驅動類別：JDK 內建 sun.jdbc.odbc.JdbcOdbcDriver，若失敗請查閱線上文件確認新類別名。

需求背景 最佳的查找體驗是：程式常駐運行，需要時切換視窗，輸入關鍵字即可即時看到結果。本文實作一個 Applet/Application 雙模式的郵件查找工具

DatabaseMetaData 龐大介面的由來 JDBC 聯機文件中 DatabaseMetaData 擁有數百個方法（如 supportsANSI92Int

定義遠端介面必須遵守的規則 公開性：介面必須宣告 public，否則客戶端載入失敗。 繼承 Remote：介面需 extends java.rmi.Remot

伺服器實作類別結構 實作類別需： 繼承 UnicastRemoteObject。 實作遠端介面（PerfectTimeI）。 提供拋出 RemoteExcep

為何需要 Stub/Skeleton RMI 基礎設施需將遠端物件偽裝成本地物件。Stub（客戶端代理）負責網路通訊與參數編碼；Skeleton（伺服器端代理）

客戶端核心步驟：查找與呼叫 RMI 讓遠端物件使用如同本地物件。客戶端僅需： 安裝 RMISecurityManager。 以 Naming.lookup()

RMI 的侷限性 RMI 提供純 Java 的遠端物件發布方案，但若專案已有大量非 Java 代碼（C++、CORBA 等），RMI 難以整合現有資產。 兩大