10 серверов по 100мбит, лучше чем 1 сервер с 1 Гбит. Выше отказоустойчивость ( более надежная архитектура )! P.S. При подключении узлов поддержки, главное учитывать гарантированный аплоад и только исходя из этого открывать необходимое количество слотов ( то есть, если вам заявили гарантированную полосу в 20 мбит.с , то и рассчитывать нужно на 20, а не на 100, которые могут быть,так как именно в прайм-тайм канал будет резаться и качественной трансляции может не получится, если этого изначально не учитывать
иными словами разницы нет
если не брать в расчет возможные проблемы с серваками. Но учитывая, что на одном сервере крайне проблематично процессору справиться с задачей по отдаче 1гбита, я запускаю по 2 копии acestream-node с разными портами на 2х серверах. Таким образом удается разделить нагрузку на 2 ядра процессора, можно и 4 было бы запустить, но 2 вроде как уже справляются. Также выясняется, что при указании большого значения параметра --max-outgoing-connects, превышающего значение --max-upload-slots в 4 и более раз общая отдача становится меньше, на данный момент использую опции с такими значениями:
--max-incoming-connects 1000 --max-outgoing-connects 200 --max-upload-slots 80если указать --max-outgoing-connects равным --max-upload-slots эффективность узла также падает, так как получается что он обслуживает только 80 пиров, но которым полностью постоянно отдает поток, а не 200, которым поочередно отдает поток.
На стабильность трансляции ( просмотр без уходов на буферизацию ) влияет не количество пиров, а их качество ( насколько хороший у них аплоад ), К примеру, если вы решите сделать трансляцию, с высоким битрейтом, и причем исключительно для пользователей Укртелеком, вам нужно будет поставить парк серверов, так как у клиентов Укртелеком очень ограниченный/низкий аплоад, а соответственно вся основная нагрузка ляжет непосредственно на узлы поддержки. Чтобы не было уходов на буферизацию и быстро запускалась трансляция, пользовать должен быть законкчен с роем где есть быстрые сиды! ( рой - это тот пул пиров, которые указываются в опциях, как значение "Helping"
учитывая, что нынешние аплоады у многих пользователей составляют от нескольких мегабит до нескольких десятков, трансляцию мегабит до 5 не проблематично провести и на 5 и на 10 и даже на 50 тысяч пиров, имея при этом один узел со 100мбитами. По крайней мере это показывает практика использования сопкаста, при том что там далеко не 100мбит у источника обычно, хотя и довольно большой задержкой в 60 секунд. В TS задержка выбирается хоть и произвольно, но практика показывает, что чем большее количество звеньев от источника до пира, тем дольше у него будет идти буферизация и тем самым больше задержка, которая вырастает от нескольких десятков секунд до нескольких минут, в итоге пир, выставив даже 10 секунд в параметр буфер Live, может получить задержку в 3-5 минут(а иногда и больше) на трансляции, на которой висят несколько тысяч пиров(что уж говорить о нескольких десятков тысяч). При этом статистика трекера, которая может выдать результат о нормальной отдаче/загрузке, может оказаться хоть и правдивой, но при этом о задержке она не может ничего сказать. Это еще раз подтверждает, что есть проблемы в отдаче между пирами, как в скорости аплоада(который режется словно высокоточным шейпером в windows), так и в синхронизации потока. Если в файлах это не играет такую существенную роль, то для Live это важнейший показатель. Конечно, у некоторых пользователей провайдер режет Р2Р, но таких не так уж много, при том что у кого не режет все равно сталкиваются с подобной проблемой, включая меня самого. Даже я, подключаясь к своей же трансляции (приватный источник+4 узла с общим гигабитом), имею задержку от 30 секунд до 2х минут на 2-5 тысячах пирах, при том что буфер Live всего 10 секунд.
P.S. Если вы до сих пор в это не верите могу дать доступ к удаленном рабочему столу, где вы сами это можете увидеть.
поставить флаг приватности в acelive-файл (в соответствии со стандартами протокола bittorrent клиенты при работе с таким acelive-файлом будут получать адреса других пиров только через трекеры, прописанные в acelive; dht и другие способы обмена информацией о пирах будут отключены)
иначе говоря лучше не использовать эту опцию
Автор
Тема: Broadcasting ( организация собственных прямых трансляций на базе TS ) (Прочитано 406638 раз)