※ 引述《[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