Способ восстановления файлов для системы распространения контента

Изобретение относится к области сетей передачи данных, а более конкретно - к способу восстановления файлов для повторного получения файла в системе для распространения контента более чем одному получателям. Технический результат заключается в оптимизации нагрузки потока обмена в сети. Сущность изобретения заключается в том, что принимают набор файлов при многоадресной передаче с активной доставкой от отправителя; сообщают о принятых файлах на сервер; принимают с упомянутого сервера идентификатор второго получателя, который владеет недостающим файлом, который не содержится в упомянутом принятом наборе файлов; и повторно получают упомянутый недостающий файл от упомянутого второго получателя в режиме оперативной доставки с использованием однорангового механизма. 4 н. и 7 з.п. ф-лы, 5 ил.

 

Настоящее изобретение относится к способу для восстановления файлов в системе для распространения контента.

Распространение контента между сервером и многочисленными получателями требует устанавливать двухточечное соединение между сервером и получателем либо многоточечное соединение. Двухточечное соединение дает возможность распространять контент посредством одноадресной передачи каждому получателю и обеспечивает надежное распространение. Однако при значительном количестве получателей, оно требует обременительного управления соединениями. Оно к тому же может заметно увеличивать поток обмена через сеть. Распространение с многоадресной рассылкой предусматривает меньшую сетевую нагрузку при менее надежном распространении. Когда используется распространение с многоадресной рассылкой, должно быть найдено решение для устранения ошибок при приеме, например, посредством запросов повторной передачи. В качестве примера для многоадресной доставки контента, RFC (Рабочие предложения) 3926 IETF (Комитета по инженерным вопросам сети Интернет) определяет протокол доставки файлов через однонаправленную транспортировку, названный FLUTE. Протокол, определенный в этом стандарте, хорошо приспособлен, чтобы удовлетворять задачам масштабируемости в показателях количества клиентов и разнородности в показателях полосы пропускания, поддерживаемой клиентами. Но FLUTE не предлагает совершенно надежное обслуживание распространения, особенно когда передачи имеют конечную продолжительность. Это справедливо в том механизме доставки контента, где необходимо поддерживать периодическое обновление подмножества контента. В таком случае, дополнительный надежный механизм восстановления файлов должен быть надстроен поверх протокола FLUTE. В контексте, где есть значительное количество получателей, механизм устранения должен быть приспособлен для того, чтобы оптимизировать поток обмена по сети.

US 2003/182373 A1 (Сото Джуан Карлос [США] и другие) от 25 сентября 2003 года раскрывает механизм устранения ошибок с использованием однорангового способа. Способ, раскрытый в нем, является децентрализованным.

US 2006/023732 A1 (Видантам Рамакришна [США] и другие) от 2 февраля 2006 года раскрывает механизм устранения ошибок одноадресной передачи.

NTT DOCOMO ET AL: «Point-to-point repair mechanism for MBMS file download service, Tdoc S4-040038» TECHNICAL SPECIFICATION GROUP SERVICES AND SYSTEM ASPECTS, XX, XX, 23 February 2004, pages 1-4, XP002375819 (НТТ Докомо и другие: «Одноранговый механизм восстановления для службы загрузки файлов MBMS, Tdoc S4-040038», Групповые услуги и аспекты системы в техническом описании, XX, XX, от 23 февраля 2004 года, стр. 1-4, XP002375819) также раскрывает механизм устранения ошибок одноадресной передачи.

Настоящее изобретение имеет отношение к эффективному способу восстановления файлов на уровне получателя, одноранговому получателю и серверу индексного поиска информации, которые оптимизируют нагрузку потока обмена в сети.

Для этой цели изобретение относится к способу для повторного получения файла в системе для распространения контента по более чем одному получателям, содержащему, у первого получателя, этапы приема набора файлов при многоадресной передаче с активной доставкой от отправителя, приема идентификатора второго получателя, который имеет недостающий файл, который не содержится в принятом наборе файлов, и повторного получения недостающего файла от второго получателя в режиме оперативной доставки с использованием однорангового механизма.

Так как пересылка файлов от отправителя получателю не является надежной, один или более файлов могут не приниматься безошибочно. Неожиданно, получатель не принимает недостающий файл от отправителя набора файлов. Он принимает адрес другого получателя, которой имеет недостающий файл, доступный для загрузки одноранговым образом. Получатели контента содействуют механизму восстановления файла. Это дает возможность оптимизировать выравнивание нагрузки в сети и снижать перегрузку сервера.

Согласно первому варианту осуществления, этап приема идентификатора второго получателя содержит этапы сообщения о принятых файлах на сервер и приема идентификатора вторым получателем с сервера.

Получатель указывает серверу файлы, которые он принял безошибочно. Это предоставляет серверу возможность опознавать недостающие файлы у каждого получателя, а затем узнавать, какой получатель нуждается и в каком недостающем файле. Он также предоставляет серверу возможность указывать получателю, который обнаружил недостаток файла, получателей, которые безошибочно приняли недостающий файл.

Согласно второму варианту осуществления, этап приема идентификатора второго получателя содержит этапы приема идентификатора набора файлов, которые должны приниматься, обнаружения недостающего файла в числе принятого набора файлов, сообщение о недостающем файле на сервер и приема идентификатора второго получателя с сервера.

Получателю указывается список файлов, которые предполагаются для приема. Затем он обнаруживает недостающий файл и указывает недостающий файл серверу. Это уменьшает поток обмена восходящей линии связи в сети. В самом деле, получатель, который принял все файлы, не отправляет никакие указания на сервер. Запрос серверу отправляет только получатель, который обнаруживает недостающий файл.

Согласно третьему варианту осуществления, этап приема идентификатора второго получателя содержит этапы приема идентификатора каждого получателя контента, приема идентификатора набора файлов, которые должны приниматься, обнаружения недостающего файла в числе принятого набора файлов, широковещательной передачи запроса другим получателям на повторное получение недостающего файла и приема идентификатора второго получателя от второго получателя.

Сервер не вовлечен в механизм восстановления файлов. Повторное получение файлов выполняется между получателями. Этот децентрализованный режим разгружает сервер.

Еще одной целью изобретения является способ для повторного получения файла в системе для распространения контента по более чем одному получателям, содержащий, на сервере, этапы идентификации набора файлов, которые должны приниматься всеми получателями, идентификации для каждого получателя списка безошибочно принятых файлов, указания первому получателю, который не принял файл безошибочно, идентификатора второго получателя, который принял файл безошибочно.

Сервер управляет централизованным способом для восстановления файла. Он идентифицирует список файлов, которые были приняты каждым получателем, а затем, способен прослеживать недостающие файлы у каждого получателя. И, что касается каждого получателя, который не принял файл безошибочно, он указывает однорангового получателя, который принял файл безошибочно.

Еще одной целью изобретения является способ для повторного получения файла в системе для распространения контента по более чем одному получателям, содержащий, у первого получателя, этапы приема набора файлов при многоадресной передаче с активной доставкой от отправителя, приема идентификатора запроса от второго получателя на восстановление файла, если файл имеется в распоряжении в наборе файлов, отправки файла второму получателю, а если файл не имеется в распоряжении в наборе файлов, пересылки запроса другим получателям.

Каждый получатель содействует механизму восстановления файлов. Он делает доступным принятый набор файлов другим получателям для механизма восстановления. Набор файлов является загружаемым в режиме оперативной доставки с использованием однорангового механизма.

Согласно варианту осуществления, после приема набора файлов он содержит этап указания принятого набора файлов серверу.

Получатель выясняет набор файлов, которые он принял безошибочно, и которые доступны для других получателей. Это дает возможность, в централизованном режиме, устранять ошибочные запросы.

Согласно варианту осуществления, контент распространяется согласно протоколу доставки файлов через однонаправленный транспорт, названному протоколом FLUTE, а способ восстановления файлов применяется только к файлу, принимаемому во время текущего сеанса доставки файлов.

Набор файлов доступен у каждого получателя только в течение периода, а именно текущего сеанса доставки файлов. После такого периода, файл больше не пригоден для восстановления. Он мог бы быть доступным на сервере контента через общепринятый клиент-серверный механизм восстановления файлов.

Согласно варианту осуществления изобретения, этап обнаружения недостающего файла выполняется с помощью таблицы доставки файлов, определенной в протоколе FLUTE.

Еще одной целью изобретения является компьютерный программный продукт, содержащий команды управляющей программы для выполнения этапов последовательностей операций согласно изобретению, когда программа приводится в исполнение на компьютере. Под «компьютерным программным продуктом» подразумевается поддержка компьютерной программы, которая может состоять не только в пространстве хранения, содержащем программу, таком как дискета или кассета, но также и в сигнале, таком как электрический или оптический сигнал.

Изобретение будет лучше понятно и проиллюстрировано посредством последующего варианта осуществления и примеров выполнения, никоим образом не ограничивающих, со ссылкой на прилагаемые фигуры, на которых:

- фиг. 1 - структурная схема системы, совместимой с вариантом осуществления;

- фиг. 2 - структурная схема устройства, совместимого с вариантом осуществления;

- фиг. 3 - блок-схема последовательности операций способа распространения по варианту осуществления;

- фиг. 4 - блок-схема последовательности операций механизма восстановления файлов в централизованном режиме; и

- фиг. 5 - блок-схема последовательности операций механизма восстановления файлов в децентрализованном режиме.

На фиг. 1 и 2, представленные этапы являются чисто функциональными сущностями, которые не обязательно соответствуют физически отдельным сущностям. А именно, они могли бы быть сконструированы в виде программного обеспечения, или реализованы в одной или нескольких интегральных схемах.

Обслуживание на основании широкополосной сети цифровых абонентских линий киосков применяется в помещениях торговых отделений, таких как супермаркеты, где потребители могут покупать, цифровые видеодиски, называемые DVD. Каждый киоск оборудован локальным запоминающим устройством для хранения контента DVD при среднем количестве приблизительно в 10000 глав в каждом киоске. Киоск также оборудован средством взаимодействия с пользователем для предоставления потребителю возможности осуществлять просмотр на киоске и выбирать контент в киоске по справочнику контента, DVD прожигается и упаковывается непосредственно внутри киоска. Периодически контент в каждом киоске частично обновляется с сервера контента с помощью инкрементного обновления, которое управляется оператором обслуживания. Преимущество этой системы по сравнению с современными системами видеопроката состоит в том, что потребители имеют доступ к большему количеству ссылок на контент, все эти ссылки никогда не бывают отсутствующими на складе и периодически обновляются. Фиг. 1 описывает устройства, вовлеченные в обслуживание; сервер 5 отправляет контент в несколько киосков 1, 2, 3 через сеть 4, предпочтительно являющуюся сетью Интернет. Киоск является клиентом сервера 5. Фиг. 1 представляет 3 киоска, но обслуживание может содержать тысячи киосков. Конечно обслуживание может нуждаться в применении более чем одного сервера. Каждый из нескольких серверов мог бы поставлять подмножество контента в киоски. Сервер 6 индексного поиска информации управляет повторным получением файлов, как описано ниже. Сервер 5 и сервер 6 индексного поиска информации могли бы быть расположены на одном и том же устройстве или на разных устройствах.

Фиг. 2 представляет компоновочные блоки серверов 5 и 6 и киосков. Модуль 1.2 связи имеет назначение передавать и принимать данные через сеть Интернет с другими устройствами. Модуль 1.3 обработки содержит средство для приведения устройства в действие. Устройство содержит модуль 1.1 хранения для хранения данных, файлы управления и программно-аппаратные средства, которые дают возможность приводить устройство в действие. Все модули соединены внутренней шиной 1.4.

В сервере 5, модуль хранения содержит ссылки на контент. В сервере 6 индексного поиска информации, модуль хранения содержит список файлов для доставки, которые могут выбираться с сервера 5, каждый файл идентифицируется идентификатором. В киоске, модуль хранения содержит контент, пригодный для прожигания и упаковки. Средство для прожигания и упаковки DVD не изображено. Сервер управляет процедурами доставки контента и восстановления файлов. Конечно ссылка на контент могла бы содержаться в первом сервере, который управляет процедурой доставки контента, и по меньшей мере второй сервер мог бы управлять процедурой восстановления файлов.

Полная последовательность операций доставки обобщена на фиг. 3.

Сигнализация 2.1 является этапом, необходимым для инициирования фазы загрузки.

Многоадресная доставка 2.2 является фазой многоадресной доставки контента с сервера набору получателей.

Восстановление файла, 2.3 разделяется на 2 этапа.

Состояние многоадресной доставки, 2.3.1, является этапом, где сервер восстановления файлов, если он существует, получает состояние клиентов касательно загружаемых файлов.

Повторное получение файла, 2.3.2, является этапом, необходимым, чтобы клиенты повторно получали недостающие данные.

Сообщение о приеме, 2.5, является этапом, где клиенты сообщают оператору о полном приеме контента.

Способ для инициализации соединений является следующим. Когда клиент присоединяется к сети распространения, он широковещательно передает запрос протокола разрешения адресов, названный запросом ARP, на IP-адрес (сети Интернет) сервера. Сервер отправляет одноадресный ответ ARP клиенту, указывающий его MAC-адрес (управления доступом к среде передачи). Затем клиент идентифицирует себя по отношению к серверу своей учетной записью и паролем с использованием протокола передачи файлов, названного FTP. В заключение, если идентификация имеет успех, клиент присоединяется к серверу и способен принимать контент. Когда новый киоск добавляется в сеть, он отправляет на централизованный сервер индексного поиска информации свою информацию о соединении (IP-адрес, порт...) и может становиться одноранговым узлом сети.

Способ для распространения файлов по киоскам является следующим. Механизм доставки контента является близкородственным способу Видео по запросу, названному VOD, приписываемому Видео по запросу с активной доставкой, названному VOD с активной доставкой. В самом деле, в способе активной доставки контента, контент сохраняется в устройстве, содержащем локальное запоминающее устройство, такое как жесткий диск, под управлением оператора. Как только загружен, этот контент может воспроизводиться, когда потребитель его запрашивает. Стратегия активной доставки контента предоставляет возможность доставки контента в областях, где доставка в реальном времени невозможна или предрасположена к ошибкам. Она предоставляет возможность доставки многочисленных одновременных услуг при сниженной себестоимости, так как расходование полосы пропускания может быть ограничено по сравнению с действующими услугами или услугами VOD, основанными на протоколах одноадресной передачи, таких как VOD потокового режима или VOD режима загрузки.

Механизм доставки контента VOD с активной доставкой нацеливается на периодическое обновление только подмножества всего контента и метаданных, хранимых на клиентском устройстве. Эта стратегия обновления, названная инкрементным обновлением, может быть разделена на этапы, описанные ниже.

Для инициирования фазы загрузки, механизм внеполосной сигнализации, управляемый оператором, используется для извещения об обновлении подмножества контента в киоски. Этот механизм сигнализации основан на механизме обнаружения служб, используемом в стандарте DVB-IP (цифрового видеовещания по протоколу сети Интернет), который определен в ETSI TS 102034 V1.1.1 (2005-03) Digital Video Broadcasting (DVB): Transport of MPEG2 Based DVB Services over IP Based Networks (V1.1.1 TS 102034 ETSI (2005-03) Цифровое видеовещание (DVB): Транспортировка основанных на MPEG2 услуг DVB по основанным на IP сетям).

После приема извещения, киоски начинают фазу загрузки, и загружаемые данные сохраняются во временном буфере. Этот механизм загрузки основан на протоколе многоадресной доставки контента. RFC 3926 IETF определяет протокол доставки файлов через однонаправленную транспортировку, названный FLUTE. Он хорошо приспособлен, чтобы удовлетворять задачам масштабируемости в показателях количества киосков и разнородности в показателях полосы пропускания, поддерживаемой киосками. FLUTE не предлагает совершенно надежную услугу распространения, особенно, когда передачи имеют конечную продолжительность, как это имеет место в механизме доставки контента, где необходимо поддерживать периодическое обновление подмножества контента. Дополнительный надежный механизм восстановления файлов должен быть надстроен поверх протокола FLUTE. Восстановление файлов является двухуровневым механизмом восстановления файлов.

Первый уровень занимается восстановлением файлов, которое выполняется для повторного получения файлов текущего сеанса обновления. Этот этап восстановления файла назван «Восстановлением файлов для текущего сеанса доставки». Этот механизм восстановления файлов основан на одноранговом протоколе, названном P2P. P2P является сетевым протоколом, который полагается на извлечение информации среди узлов-участников вместо централизованного извлечения с одиночного сервера. В модели P2P, каждый узел-участник может делать информацию доступной для распространения и может устанавливать прямые соединения с любым другим узлом-участником для загрузки информации. В самом деле, после сеанса многоадресной доставки контента FLUTE контент почти распространен по киоскам; некоторые фрагменты контента могут быть недостающими в каждом киоске, но большая его часть была загружена. При условии этого может быть разработано эффективное решение восстановления файлов на основании протокола P2P. Этот способ восстановления файлов может указываться ссылкой как «загрузка P2P с активной доставкой». Контент, то есть набор файлов, принятый получателем в сеансе, делается доступным для других получателей во время текущего сеанса.

Второй уровень занимается восстановлением файлов для повторного получения файлов предыдущих сеансов обновления. Этот этап восстановления файлов назван «Восстановлением файла для предыдущего сеанса доставки» и отличен от стратегии восстановления файлов, используемой для текущего сеанса обновления. В этом контексте, контент, принятый в предыдущем сеансе в киоске, был скомпилирован и сохранен в качестве уровня информации. Он больше не доступен в виде файлов, как в предыдущем сеансе, и, в таком случае, больше не доступен другим получателям. Поэтому он дает возможность не основанного на благоприятствующем сетевому потоку обмена P2P механизма восстановления файлов, а только более традиционного клиент-серверного механизма восстановления файлов. В этом случае, этот уровень восстановления файлов является почти подобным стратегии, перенятой в стандарте доставки данных IP DVB-H, DVB-CBMS, «IP Datacast over DVB-H; Content Delivery Protocols (CDP)», DVB Document A101, 2005 December («Доставка данных IP по DVB-H; Протокол доставки данных (CDP)», Документ A101 DVB, декабрь 2005 года). Стратегия восстановления данных, перенятая в стандарте доставки данных IP DVB-H, является только одноуровневой стратегией восстановления файлов и перенимает централизованный клиент-серверный режим «Восстановления файлов». Она не пользуется возможностью того обстоятельства, что контент почти распространен по киоскам после этапа многоадресной передачи.

Как только подмножество контента и метаданных было загружено и сохранено в буфере памяти, и когда достигается время выдержки контента, заданное во внеполосном извещении, подмножество старых данных заменяется новыми загруженными данными. Этот этап замены между старыми и новыми загруженными данными выполняется, когда киоски не находятся в использовании для потребителей. Киоски применяются в помещениях торговых отделений и не являются работающими ночью. Во время замены между старым и новым контентом, киоски должны стирать некоторый из своего контента. Список файлов или каталог для стирания описан в первом файле доставки сеанса, который соответствует FLUTE/TOI = 1 (идентификатору объекта транспортировки). Этот файл всегда доставляется, даже когда он пуст. В этом случае, не стирается никакой контент. Если этот файл не пуст, но не доставлен никакой файл контента, киоск выполняет операцию стирания без загрузки контента. Механизм замены, конечно, мог бы состояться другим образом, где киоск устанавливается в режим приостановки во время механизма замены.

Как только обновлен и заменен, весь новый контент делается доступным для пользователей.

Далее описан способ восстановления файлов.

Согласно предпочтительному варианту осуществления, используется централизованный режим.

Сервер индексного поиска информации узнает список файлов, которые были переданы с сервера контента, при выборке этой информации на сервер контента.

Во время «этапа состояния многоадресной доставки» каждый киоск сообщает на централизованный сервер индексного поиска информации о принятых файлах. Сервер индексного поиска информации способен создавать индексную таблицу, связывающую реально принятый контент каждого киоска.

Затем, во время «этапа восстановления файла», сервер отыскивает соответствия в своей индексной таблице для каждого киоска, где контент является недостающим. Он указывает каждому киоску список одноранговых киосков, которые владеют недостающим контентом. Киоски, где контент является недостающим, открывают прямое соединение с одним или более одноранговыми узлами, которые владеют недостающими файлами, и загружает их.

Централизованный способ проиллюстрирован на фиг. 4.

На этапе 1, каждый киоск отправляет на сервер индексного поиска информации список файлов, который он совместно использует, с номером TCP-порта (протокола управления передачей), где он доступен для загрузки файла из списка.

На этапе 2, сервер индексного поиска информации подтверждает прием списка файлов каждому киоску.

На этапе 3, сервер обследует принятый список файлов, чтобы найти недостающие файлы в каждом киоске. Он отправляет указание каждому киоску со списком киосков, которые владеют недостающим файлом. На фиг. 4, он отправляет указание в киоск 1. На этом этапе, сервер не указывает киоскам никакой информации о средстве для соединения.

На этапе 4, киоск 1 отправляет запрос на сервер для загрузки запрошенного файла.

На этапе 5, сервер осуществляет многоадресную передачу запроса ARP в киоски, которые удерживают запрошенный файл. Это предназначено для подбора режима соединения киосков.

На этапе 6, киоск 2 является первым, который отправляет ответ на сервер о своей возможности присоединяться к киоску 1 для передачи файлов.

На этапе 7, сервер отправляет IP-адрес киоска 2 как киоска, который владеет файлом.

На этапе 8, киоск широковещательно передает запрос ARP для идентификации киоска с IP-адресом киоска 2.

На этапе 9, киоск 2 отправляет ответ в киоск 1 с указанием его MAC-адреса.

На этапе 10, киоск 1 присоединяется к киоску 2 для получения файла.

На этапе 11, киоск 2 отправляет файл в киоск 1.

Согласно иному варианту осуществления централизованного режима, каждый киоск может полагаться на протокол FLUTE, чтобы определять файлы, которые являются недостающими. В самом деле, протокол FLUTE определяет таблицу доставки файлов, названную FDT, которая содержит информацию о файлах, которые должны передаваться в текущем сеансе. Протокол FLUTE передает FDT с сервера контента в режиме многоадресной передачи во все киоски. Так как это может подвергаться ошибкам передачи, надежность передачи файла FDT может улучшаться механизмами, такими как прямая защита от ошибок, или передачами FDT во время сеанса, которые хорошо известны сами по себе. Значит, в конце «этапа многоадресной доставки контента» каждый киоск точно знает файлы, которые должны быть переданы в сеансе, и файлы, которые были приняты. Каждый киоск затем может указывать серверу индексного поиска информации файлы, которые являются недостающими. Сервер затем указывает киоску адрес(а) другого киоска(ов), который владеет недостающим файлом(ами). Этот иной вариант осуществления дает возможность минимизировать поток обмена по сети; он применим, когда несколько киосков предполагаются принимающими ошибочные файлы.

Согласно второму варианту осуществления, восстановление файлов является децентрализованным. Сервер индексного поиска информации не вовлечен в этап повторного получения файлов. Каждый киоск способен определять множество файлов, необходимых для завершения приема контента, в конце «этапа многоадресной доставки контента». В децентрализованной модели, механизм волнового распространения используется для распространения сообщений «запроса восстановления файла» между киосками.

Алгоритм в запрашивающем киоске является следующим:

- Киоск идентифицирует, что файл является недостающим.

- Он широковещательно передает запрос своим одноранговым киоскам, чтобы спросить о доступности файла.

- Как только киоск принимает сообщение, указывающее, что файл был идентифицирован в другом киоске, он инициирует прямое соединение с этим одним, чтобы получить файл.

Так как в этом случае нет централизованной координации, подобной серверу индексного поиска информации, этап восстановления файла может быть инициирован в начале «этапа восстановления файла» без отдельного «этапа состояния многоадресной доставки».

Алгоритм в киоске является следующим:

- Киоск принимает запрос из другого киоска, в котором файл является недостающим.

- Если киоск не имеет пригодного файла, он пересылает запрос.

- Если киоск имеет пригодный файл, он оправляет ответное сообщение обратно по маршруту, по которому пришел запрос, в то время как сам запрос не содержит идентифицирующей информации киоска, откуда приходит запрос.

Чтобы ограничить распространение сообщений через сеть, каждое сообщение содержит поле времени существования, названное TTL, которое декрементируется на каждом транзитном участке каждый раз, когда запрос достигает киоска. Когда поле TTL является нулевым, сообщение отбрасывается.

Когда новый киоск добавляется в сеть, он отправляет сообщение прямой отсылки в другие киоски, к которым он присоединен, чтобы известить о себе. Киоски отправляют обратно сообщение обратной отсылки, идентифицирующее их, и также распространяют сообщение прямой отсылки по своим соседям. Каждое сообщение содержит «ID описателя» для уникальной идентификации сообщения. Сообщение прямой отсылки не содержит никакой полезной нагрузки, тогда как сообщение обратной отсылки содержит контактную информацию, такую как IP-адрес и порт, и информацию о совместно используемых файлах, таких как номер файла, размер.

Децентрализованный режим проиллюстрирован на фиг. 5.

Два типа сообщений используются в децентрализованном режиме, запрос R и успешный ответ S. Запрос отправляется, чтобы запрашивать соседа о доступности недостающего файла. Сообщение R запроса содержит запрошенный файл, содержащий наименование и размер файла. Когда киоск принимает более чем один раз одно и то же сообщение запроса с одним и тем же «ID описателя», он прекращает пересылать это сообщение для того, чтобы избежать циклов и минимизировать поток обмена. Когда запрошенный файл идентифицирован в киоске, возвращается успешный ответ S. Успешный ответ S содержит контактную информацию (IP-адрес, порт) и файл, соответствующий критериям поиска (наименованию, размеру).

В сценарии, проиллюстрированном на фиг. 5, киоск 1 не принял файл F.

На этапе A, киоск 1 отправляет запрос своим соседям, в киоск 3 и киоск 4.

На этапе B, так как киоск 3 и киоск 4 не содержат пригодный файл F, они пересылают запрос своим соответственным соседям. Киоск 3 осуществляет пересылку в киоск 2 и киоск 4, а киоск 4 осуществляет пересылку в киоск 3 и киоск 5.

На этапе C, киоск 2 владеет файлом F, он отправляет успешное сообщение в киоск 3. Киоск 5 пересылает сообщение запроса в киоск 2.

На этапе D, киоск 3 пересылает успешное сообщение в киоск 1.

Киоск 1 теперь осведомлен о местоположении недостающего файла F. Он открывает соединение с киоском 5 для загрузки файла F.

В самом деле, сообщение запроса может содержать список из более чем одного недостающего файла. Когда киоск владеет некоторыми файлами из списка, он отправляет успешное сообщение с файлами, и, так как он не владеет всеми файлами, он пересылает запрос своим соседям. Инициатор запроса затем выбирает более удобные киоски среди тех, которые отправляли успешное сообщение, для загрузки файлов.

В третьем варианте осуществления, восстановление файла является частично централизованным. Оно использует схему, где сервер управляет доставкой контента, и по меньшей мере один другой сервер управляет восстановлением файлов. Этот другой сервер расположен в суперузле. Суперузлу динамически назначается задача обслуживания небольшого подраздела сети киосков. Суперузел индексирует файлы, совместно используемые киосками, присоединенными к ним, и выполняет поисковые запросы от имени киосков. Все запросы направляются на суперузел подраздела. Время поиска в таком случае сокращается по сравнению с децентрализованной моделью.

1. Способ восстановления файла для повторного получения файла, для использования в системе для распространения контента по более чем одному получателю, содержащий у первого получателя (1) этапы, на которых:
принимают набор файлов при многоадресной передаче с активной доставкой от отправителя (5);
сообщают о принятых файлах на сервер (6);
принимают с упомянутого сервера идентификатор второго получателя (2), который владеет недостающим файлом, который не содержится в упомянутом принятом наборе файлов; и
повторно получают упомянутый недостающий файл от упомянутого второго получателя (2) в режиме оперативной доставки с использованием однорангового механизма.

2. Способ по п.1, отличающийся тем, что этап, на котором принимают
идентификатор второго получателя, содержит этапы, на которых:
принимают идентификатор каждого получателя контента;
принимают идентификатор набора файлов, которые должны быть приняты;
обнаруживают недостающий файл в числе принятого набора файлов;
широковещательно передают запрос другим получателям на повторное получение упомянутого недостающего файла; и
принимают упомянутый идентификатор упомянутого второго получателя от второго получателя.

3. Способ по п.1, отличающийся тем, что контент распространяют согласно доставке файлов по однонаправленному транспортному протоколу, и способ восстановления файла применяют только к файлу, принятому в течение текущего сеанса доставки файлов.

4. Способ восстановления файла для повторного получения файла, для использования в системе для распространения контента по более чем одному получателю, содержащий у первого получателя (1) этапы, на которых:
принимают идентификатор набора файлов, которые должны быть приняты;
принимают набор файлов при многоадресной передаче с активной доставкой от отправителя (5);
обнаруживают недостающий файл в числе принятого набора файлов;
сообщают об упомянутом недостающем файле на сервер (6);
принимают с упомянутого сервера идентификатор второго получателя (2), который владеет недостающим файлом, который не содержится в упомянутом принятом наборе файлов; и
повторно получают упомянутый недостающий файл от упомянутого второго получателя (2) в режиме оперативной доставки с использованием однорангового механизма.

5. Способ по п.4, отличающийся тем, что контент распространяют согласно доставке файлов по однонаправленному транспортному протоколу, названному протоколом FLUTE, и способ восстановления файла применяют только к файлу, принятому в течение текущего сеанса доставки файлов, и этап обнаружения недостающего файла выполняют с помощью таблицы доставки файлов, определенной в протоколе FLUTE.

6. Способ по п.4, отличающийся тем, что контент распространяют согласно доставке файлов по однонаправленному транспортному протоколу, и способ восстановления файла применяют только к файлу, принятому в течение текущего сеанса доставки файлов.

7. Способ повторного получения файла в системе для распространения контента по более чем одному получателю, содержащий на сервере (6) этапы, на которых:
принимают идентификацию набора файлов, которые должны быть приняты всеми получателями;
идентифицируют список безошибочно принятых файлов каждым получателем; и
указывают первому получателю (1), который не принял файл безошибочно, идентификатор второго получателя (2), который принял файл безошибочно.

8. Способ по п.7, отличающийся тем, что контент распространяют согласно доставке файлов по однонаправленному транспортному протоколу, и способ восстановления файла применяют только к файлу, принятому в течение текущего сеанса доставки файлов.

9. Способ повторного получения файла в системе для распространения контента по более чем одному получателю, содержащий у первого получателя (1) этапы, на которых:
принимают набор файлов при многоадресной передаче с активной доставкой от отправителя (5);
принимают запрос от второго получателя (2) на повторное получение файла;
если файл доступен в наборе файлов, отправляют файл упомянутому второму получателю (2); и
если файл не доступен в наборе файлов, пересылают запрос другим получателям.

10. Способ по п.9, отличающийся тем, что после приема упомянутого набора файлов он содержит этап, на котором указывают упомянутый принятый набор файлов серверу.

11. Способ по п.9, отличающийся тем, что контент распространяют согласно доставке файлов по однонаправленному транспортному протоколу, и способ восстановления файла применяют только к файлу, принятому в течение текущего сеанса доставки файлов.