第四章原則的運用-資料下載頁
2025-10-15 13:41本頁面
【導讀】應(yīng)用設(shè)備通道（ApplicationDevice. 配器的存儲區(qū)域來進行網(wǎng)絡(luò)收發(fā)。需要一種隔離應(yīng)用程序的保護機制：。內(nèi)核為每個應(yīng)用程序分配一組用于網(wǎng)絡(luò)收發(fā)的。內(nèi)存頁，并用這組內(nèi)存頁設(shè)置網(wǎng)絡(luò)適配器。網(wǎng)絡(luò)適配器必須保證每個應(yīng)用程序只能從分配。請求中指定的頁屬于P的合法頁集合。樸素的解決方案：。將合法頁的頁號組織在一個線性表中，適配器。哈希函數(shù)計算復(fù)雜度高，最差性能不能保證。令應(yīng)用程序在請求中傳遞一個線索，幫助適配。適配器將不同應(yīng)用的合法頁號保存在不同的數(shù)組。應(yīng)用在讀寫請求中向適配器傳遞一個句柄，指出。適配器使用該句柄快速查找并驗證頁號。通過傳遞線索改進了最壞情況下的性能。ATM適配器可同時支持幾百條已經(jīng)建立的VC. 每條VC上使用流量控制限制其發(fā)送速度。調(diào)度器依次檢查每個VC，尋找一個合格的。為避免查找不合格的VC，可將合格的VC抽出來組。每個包的統(tǒng)計工作要求在64微秒內(nèi)完成。根據(jù)包頭中的協(xié)議域，將包交給相應(yīng)的協(xié)議
【正文】 窗口大小 ? RTT估算：不準確 思考 ? 對于 TCP來說，以上方案是一個好主意嗎？ ? 激進的確認抑制可能會影響 TCP的哪些方面？ ? 流量控制：發(fā)送方不能及時推進發(fā)送窗口，阻塞發(fā)送方 ? 擁塞控制：發(fā)送方不能及時檢測到擁塞，也不能利用確認調(diào)整擁塞窗口 ? RTT估算：不準確 ? Q3：對系統(tǒng)某部分的改變是否會影響系統(tǒng)的其它部分？ 對大數(shù)據(jù)庫的增量訪問 ? 假定用戶連續(xù)讀一個存放在 web網(wǎng)站的大數(shù)據(jù)庫，用戶只想知道自上一次讀過之后變化了的內(nèi)容。 問題 ? 為數(shù)據(jù)庫找到一種高效 地 執(zhí)行增量查詢 的方法 。 ? 令數(shù)據(jù)庫記住每個用戶之前讀的內(nèi)容是不現(xiàn)實 的。 ? 有沒有一個 對數(shù)據(jù)庫來說負擔不那么重的方法 ？ 分析 ? 如果數(shù)據(jù)庫不存儲用戶上一次讀過的內(nèi)容，那么用戶在讀請求中必須傳遞一些與上一次讀請求相關(guān)的信息 （ P10） 。 分析 ? 如果數(shù)據(jù)庫不存儲用戶上一次讀過的內(nèi)容，那么用戶在讀請求中必須傳遞一些與上一次讀請求相關(guān)的信息 （ P10） 。 ? 什么樣的簡單信息可以 刻畫 用戶的上一次請求？ 分析 ? 如果數(shù)據(jù)庫不存儲用戶上一次讀過的內(nèi)容，那么用戶在讀請求中必須傳遞一些與上一次讀請求相關(guān)的信息 （ P10） 。 ? 什么樣的簡單信息可以 刻畫 用戶的上一次請求？ ? 上一次請求的時間 分析 ? 如果數(shù)據(jù)庫不存儲用戶上一次讀過的內(nèi)容，那么用戶在讀請求中必須傳遞一些與上一次讀請求相關(guān)的信息 （ P10） 。 ? 什么樣的簡單信息可以 刻畫 用戶的上一次請求？ ? 上一次請求的時間 ? 在數(shù)據(jù)庫中增加 什么 狀態(tài) （ P12） ， 可以根據(jù) 用戶傳遞的信息 來 加快增量查詢 ？ 分析 ? 如果數(shù)據(jù)庫不存儲用戶上一次讀過的內(nèi)容，那么用戶在讀請求中必須傳遞一些與上一次讀請求相關(guān)的信息（ P10）。 ? 什么樣的簡單信息可以 刻畫 用戶的上一次請求？ ? 上一次請求的時間 ? 在數(shù)據(jù)庫中增加 什么 冗余狀態(tài)（ P12）， 可以 利用用戶傳遞的信息 來 加快增量查詢 ？ ? 數(shù)據(jù)庫更新歷史列表 解決方案 ? 增加一個更新歷史列表，僅保存數(shù)據(jù)庫發(fā)生的更新。 ? 更新記錄按照時間順序排列，越近的更新越靠近表頭。 ? 讀請求 中 包含上一次讀的時間 T， 查詢處理程序從表頭開始掃描更新歷史表，找到 T 之后 所有的內(nèi)容更新。 長標識符的二分查找 ? 假定每個標識符的長度為 W 個字， 匹配一個標識符需要 W 次比較操作。 ? 如果表中有 N 條標識符，且已按字典序排列， 簡單的二分查找需要 W log2N 次比較操作。 ? 若 所有標識符 的 前（ W１）個字都相同 （有共同前綴） ， 理想情況應(yīng)只比較 log2N 次 ，而不是W log2N 次。 ? 希望 修改二分查找，使得比較次數(shù)為 log2N+W。 按列進行二分查找 問題 ? 修正當前的算法，使得經(jīng)過 （ log2N+M） 次操作后得到正確的結(jié)果。 ? 算法出現(xiàn)錯誤的原因： ? 當查找移動到下一列、并且依據(jù)二分查找法確定一個新的查找位置時，假設(shè)該位置上的標識符和所要查找的標識符具有相同的字符前綴。這個假設(shè)一般是不成立的。 ? 問題： 增加什么狀態(tài) 可以 避免做出這樣錯誤的假設(shè)？ 解決方案 ? 給每一個元素增加兩個指針，將二分查找約束在正確的范圍內(nèi)進行 。 解決方案（續(xù)） ? 一般 地 ， 為 每個多字條目 （ W1W2…W n） 保存一個預(yù)先計算好的保護范圍 ，其中 Wi的保護范圍指出前 i 個字為 （ W1W2…W i ） 的條目的范圍 。 ? 如果有 N條標識符，該策略需要 log2N+M次查找 。 ? 代價是給每個元素 增加了 兩個 16位的指針 ，相 當于增加了一倍的內(nèi)存空間。 ? 這里運用了 P12（ 增加狀態(tài) ） 和 P2a（ 預(yù)先計算 ）兩條原則 。 基于 ATM的視頻會議 ? 標準的 ATM允許 “一對多”虛電路（ VC）： ? 源節(jié)點發(fā)送的任何數(shù)據(jù)被交換機復(fù)制，發(fā)送給每個接收者。 manytomany VC ? ATM交換機硬件很容易實現(xiàn)“多對多” VC： ? 交換機將任 何一個 源節(jié)點發(fā)送的數(shù)據(jù)復(fù)制 后發(fā)送 給所有的接收節(jié)點。 ? “多對多” VC的問題 ： ? 如果兩個源節(jié)點同時發(fā)送，它們的數(shù)據(jù) （帶有相同的 VC號）可能以任意 交 錯 的 順序 到達接收節(jié)點，引起混亂。 ? ATM標準不支持“多對多” VC 。 應(yīng)用 ? 設(shè)計一個視頻會議應(yīng)用： ? 每個工作站上建立一個屏幕，顯示當前正在說話的人，并播放其講話。 ? 當兩人進行對話時，能看到兩個人的表情 。 問題 ? 問題：如何在 ATM上實現(xiàn) manytomany 的視頻會議？ ? 最簡單的方法是使用 N2個 點 點 VC。 ? 較好的方法是使用 N個 onetomany VC。但 ATM交換機 的帶寬 要在 N個 onetomany VC之間靜態(tài)劃分 ，限制了參 會的工作站 數(shù)量。 ? 還 有擴放性更好的方案嗎？ 分析 ? 利用交換機硬件支持 manytomany VC的能力 （ P4c） ，但需要解決每次只能一個節(jié)點發(fā)送的問題 。 ? 如何協(xié)調(diào)發(fā)送者 ？ 解決方案 ? 協(xié)調(diào)發(fā)送者（運用系統(tǒng)思維）： ? 誰的視頻最應(yīng)當被輸出：當前說話者。 ? 如何確定當前的說話者 ：給每個工作站添加一個 語音檢測器 （ P5，增加硬件） 。 ? 原理： ? 如果工作站 X 上的語音檢測器檢測到有意義的語音活動，檢測器將 X 的視頻連接到 C。 優(yōu)化預(yù)期情形 ? 最 常見情形是兩個與會者之間對話，保留上一個說話人的視頻圖像可以提供視覺上的連續(xù)性。 ? 為此， 使用兩個 manytomany VC， C和 L： ? C 用于傳輸 當前說話 人的視頻 ? L 用于傳輸 上一次說話人 的視頻
教學課件相關(guān)推薦
鄂ICP備17016276號-1