Делегация префикса и создание маршрута

Я создаю системы IPTV, и Вы не собираетесь любить его, но у Вас есть очень жесткая задача перед Вами, особенно рассматривая Ваш бюджет.

Давайте пройдем его шаг за шагом (я нацеливаю этот ответ более широкой аудитории, чем просто Вы, если Вы не будете возражать);

• Первая вещь, которую любой создающий такую систему должен сделать, определяют ее клиентов с точки зрения местоположений, OSs, плееров и идеально понимают сетевые аспекты между клиентами и серверами - Вы уже сделали многое из этого. Это важно, поскольку это определяет серверный код, кодеки, скорости передачи и можно ли использовать многоадресную передачу вообще.

• Вторая вещь сделать, понимают Ваше содержание; где делает это, прибывают из, в том, для какого формата, как часто, разногласия по авторскому праву, требования DRM, как быстро это должно быть доступно и сколько времени, это должно быть сохранено. Я думаю, что у Вас есть часть покрытого, но можно, вероятно, задать еще некоторые вопросы вдоль этих строк.

Это далеко от простой задачи, но на основе результатов двух блоков вопросов выше Вас может начать разрабатывать Вашу систему, снова от точки поглощают вниз - как ТОЧНО Вы собираетесь повторно закодировать (при необходимости) свое содержание, этому нужен QA'ing, где это штамповало DRM и как Вы собираетесь иметь дело с риском того, что временно не зашифровали видео, если это имеет значение. Это поглощает/подготавливает системные потребности, которые будут считать честным, Вы не хотите иметь 'ручной заводной рукоятке' этот процесс вообще, потому что это станет повторяющимся очень быстро.

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

Теперь мы добираемся на часть, Вы непосредственно интересуетесь, серверы потоковой передачи.

Этой точкой Вы будете знать свои данные базы пользователей (кто, что, где, когда, как и т.д.), и это поможет Вам вычислить свои пиковые требования пропускной способности (обычно что-то как 'пиковые пользователи' x 'самая высокая скорость передачи').

"Высшее качество" является чем-то вроде неправильного употребления, поскольку я уверен, что Вы не имеете в виду "48-разрядный 8k HD @60fps", но больше как качество SD или так как руководство, я делаю SD на уровне приблизительно 1.5 Мбит/с и HD на уровне приблизительно 6 Мбит/с, но это будет определено Вашим кодеком и требованиями. Таким образом, как пример 1 000 пользователей, воспроизводящих 1.5 Мбит/с одноадресного трафика, очевидно, равняются 1.5 Гбит/с, это - то, где твердый бит входит. Во-первых может Ваша сеть, фактические соединительные линии и сами переключатели последовательно поставляют данные этой природы? Необходимо будет сесть и разработать, где слабые пятна. Можете Вы QoS эти данные для защиты его от кого-то раскрывающего большую загрузку и уничтожающий видео всего сегмента сети? Существует также то, что, если Вы - свой осмотр через 1 Гбит/с на Вашем NICs, необходимо удостовериться, чтобы Вам объединяли их в команду правильным способом так, чтобы второй и последующий член команды на самом деле добрался для переноса, это - доля трафика, этого, или перейдите к NICs на 10 ГБ.

Затем мы на мою область специалиста, устройство хранения данных - к настоящему времени Вы удались, в каком количестве устройства хранения данных Вы будете нуждаться для содержания в запуске, как быстро это вырастет, это - максимальный размер, и это - 'коэффициент текучести' (сколько продвигается и от довольного хранилище по какой период). Это скажет Вам, в каком количестве устройства хранения данных Вы нуждаетесь, но если у Вас есть 1 000 пользователей все рассмотрение каталога хорошего размера содержания, что происходит, то, что необходимо обратить очень пристальное внимание на кэширование и возможность случайного чтения устройства хранения данных.

Если Вы ОЧЕНЬ удачливы, и Ваш сервер может кэшировать 100% Вашего содержания затем, Вы находитесь в удаче, Вам просто нужны достойный сервер, большая память и 64-разрядная операционная система. Если Вы ожидаете, что у пользователей будет доступ к большему довольному хранилище, чем можно кэшироваться затем, необходимо удостовериться, что система хранения может обеспечить пиковые требования потоковой передачи, сказать 1.5 Гбит/с в примере выше, последовательно. Как Вы делаете это зависит от размера довольных хранилище и если Вам нужен больше чем один сервер потоковой передачи для этого (как будто Вы делаете необходимо будет выяснить, идете ли Вы в черепок или совместно используете свое видео).

Вы можете посмотреть на SSD, например, но не смотрите на числа 'заголовка', такие как 500 Мбит/с, в чем Вы нуждаетесь, SSD или диски, на которые можно СОВЕРШИТЬ РЕЙД для обеспечения той пиковой скорости доставки. Существует много SSD и дисков там, которые являются большими для рабочей станции или низких серверов параллелизма, но когда Вы поражаете их требованием, чтобы не отставать, говорят, что 1 000 пользователей все маленькие кусочки получения по запросу больших файлов в другой точке в файлах - хорошо в основном они не поддерживают на высоком уровне, и ни один не делает большинство алгоритмов кэширования - необходимо знать, что устройство хранения данных может сделать работу самостоятельно, если это имеет к.

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

Я надеюсь, что это помогает, как я говорю, что нацелил его на более широкую аудиторию, чем просто этот вопрос, и я могу возвратиться и добавлять/редактировать (после того как у меня была своя первая чашка чая в течение дня!).