жного автора є кінцеве безліч елементів даних для завантаження. Видавець знає кількість елементів (наприклад, отримавши список всіх елементів) і має можливість зберегти їх усі. Крім того, ми пропонуємо необмежені можливості зв'язку між читачами і видавцем, але обмежені можливості зв'язку між видавцем і автором. Таким чином, читач має доступ до будь-якого елементу, він стає доступним для читача, як тільки повністю буде завантажений на видавця. Час між першим запитом і завершення завантаження назвемо як В«Час очікуванняВ». Установка всього процесу детально показана на малюнку 7, де набір елементів показаний як (? i), а популярність показана як (Pi).
Цей принцип має сенс коли автор завантажує процеси на видавця і процеси не вимагають складних розрахунків. Наприклад, коли ми переносимо вміст жорсткого диска з об'ємом 500-Гб через Gigabit Ethernet і передачі декількох десятків відео, кожне по 10 Мб, через ADSL з'єднання (максимальна швидкість передачі 128 кбіт/с), обидва зажадають більше години на передачу. Час передачі таке ж як, передача кілька широкоформатних зображенні В«rawВ» (переклад з англ сирої), у 8-мегапіксельною камері, через бездротової мережі 3G. Ми не беремо в рахунок пропускну здатність каналу, але замість цього експортуємо з більш широким спектром час передачі, які можуть пов'язані з конкретними сценаріями, які перераховані вище. p align="justify"> Ми пропонуємо два варіанти розкладу стратегії. Перший з них, є статистичним, в сенсі, що популярність даних елементів фіксована і відома до початку завантаження. Доведено що планування SJF на основі відношення розміру призводить до мінімального часу очікування. p align="justify"> Друга стратегія, дозволяє запитувати дані під час завантаження. За допомогою симулятора, ми покажемо, що в цьому випадку планування SJF на ставленні розміру файлу і популярності, що знижує загальний час очікування, ніж планування на основі розміру та популярності поодинці. І на основі даних їх симулятора, ми виявили що він знижує загальний брешемо коли тільки у нас мало елементів (не більше шести елементів). br/>
3.2 Статичний спосіб
процесор обслуговування завдання стратегія
У цьому випадку ми припускаємо, що популярність кожного елемента фіксована і відома до початку передачі. Це означає, що планувальником потрібно прийняти рішення тільки один раз, на початку передачі. Реплікація файлів з переобтяженого сервера для віддаленого сервера розповсюдження контенту є прикладом такого сценарію. Так як вихідний сервер відповідає на зростання популярності певних файлів, його шаблон доступу може бути використаний для статистичних рішень планування. Визначення і докази в цьому розділі може служити в відправної точки для обговорення наступних секції динамічного планування. p align="justify"> Розглянемо безліч
