※ 引述《[email protected] (不停向前看的生活)》之銘言： > > 不好意思 > > 這個問題我有點不知怎麼描述，與UPnP有關 > > 若能描述問題，應該就很好解了 窘 > > 問題大致如下： > > a client subscribe event notifications(a request) > > if the server apply, the server will response 200 ok > > 那之後server發出的事件通知，client要怎麼收呀？ > > 不知道有什麼關鍵字可以查? > > > > 謝謝 > > HTTP 協定以兩種方式來協調半雙工動作: 1. 檔案大小. 2. 無檔案大小的斷線法. 斷線法是HTTP1.0 的作法. 一旦伺服器完成傳送. 會立刻斷線. 用戶端以斷線訊號為準. 確認已收完. 較新的HTTP版本會使用 "檔案大小" 來作區塊是否完成的依據. 用戶端必須從HTTP回應的表頭來得知伺服器要送多少資料. 並 持續計算收到的位元組, 來確認已經傳完.(伺服器會依指定維 持同一條連線而不斷線.) 如果伺服器無法確認自己應送多少資料 (常見於動態網頁),那 它就會使用斷線法來作為訊號控制.(此時表頭不存在資料大小 的訊息) 用戶端和伺服端之間的交握協定是半雙工的. 也就是未完成一 動作前不會有另一個控制訊息. 在需求與回覆之間是很清楚的! ( 一個需求只會有一個回覆 ). 唯一的例外是忙碌逾時! 如果因為任何原因太忙, 使得傳送費時太久, 用戶端必須自行 掌握逾時控制. 任何超過自己設定的逾時時間, 用戶端必須自 行斷線再重連, 以斷線訊號來 "重置" 傳遞狀態. 以免收到新 舊交混的封包. 這些事情是用戶端自己要知道的.(伺服端會知 道你切線了, 因為TCP 會給它訊號.) 你文中所描述的原文段說明的是伺服器應有的行為. 此時伺服 器會將表頭與資料一併傳送回來. 不會有另一個事件通知! 因 為 "用戶端" 的需求已經在 "一次回覆" 中, 全部回答完了! 原文段說明的 200 ok 是存在HTTP回應表頭中的. 如果用戶端 要求的是一個網頁, 那跟隨表頭資料的將是網頁資料, 不會需 要另一個事件處理. 伺服端回應需求之後, 一次回傳完HTTP表頭及內容. 然後就會 斷線.(舊協定) 或是 "安靜" 等候你的新需求命令.(新版HTTP 協定). 客戶端一定要檢查表頭的回應狀態, 才能知道所回傳的 "整批 資料" 是否已是 "全部資料". 伺服器不會主動回傳新的事件通知, 和Windows 或其它事件系 統的CallBack模型不同. HTTP是採Client-Server 主從系統模 型的. 也就是推一次動一下這種. 最後. HTTP斷線重傳方式是採用表頭需求命令來控制的, 不是同一次 連線, 因為已經 "斷線" 了! 用戶端要指明接續資料的起點與 範圍, 如此伺服器才能決定從哪裡開始回傳. 這已是第二個新 行程. 不是前一個. 同樣的, 當伺服器開始回應後, 一定會等它所有能做的都做完 才有客戶端的發言權. 這就是半雙工系統. ( " 半" 的意思就是一次只有半邊發言, 不能 "同時" 搶話. " 雙工" 是許可 "雙向" 傳遞. ) 對前端的 "新起點" 而言: 只有兩種情況: 1. 斷線. 2. 資料已傳送表頭所明示的位元組. 任何前端程式使用這兩種狀況來起始下一個新需求. 而伺服器會針對需求作反應. 直到主動斷線或送完待機為止. 總之客戶端一定要檢查HTTP回應表頭所含的訊號, 並計算所收 到的 "全部" 資料大小, 才能確認一個需求是否已經完成. ( 除了逾時完全無回應以外). Tommy 100/12/17 -- ▄ ◢ ▄▄▄ ▄▄▄ ▄ ▄▄▄ 清大資工 █ █◣◢█ █▄█ █▄█ █ █▄▄ tommy 從 125.232.141.114 █ █◥◤█ █ █ █ █▄▄ █▄▄ 【楓橋驛站】 telnet://imaple.tw