Мультикаст & юникаст - что выбрать?

[atx]

Имхо, мертворождено. Слишком дорогая защита, для дешевого IP-транспорта.

Для межблочной коммутации, согласен, из пушки по воробьям. Проще и дешевле поставить/настроить правильный коммутатор.
А вот когда появляется станция с распределенными IP-QAM модуляторами и поток до них доставляется не по самым лучшим каналам, через несколько коммутаторов...

Тут тоже надо считать. Если сеть своя, сегменты не по 1000км, то проще QOS или вообще отдельное волокно.

FEC вещь необходимая для передачи на огромных скоростях (10-100G) по оптике на большие расстояния (>70-100км). Там из-за использования сложных модуляций и особенностей передачи по оптике (дисперсия в первую очередь), необходим большой уровень SNR. FEC помогает хоть как то переложить проблему на вычислительный уровень.

[skarxxl]

сылку не могу дать, оно в закрытом разделе Bridgetech. Запросите у своего поставщика доступ. Там не только инструкции лежат, но и обновления ПО.

Понял, спасибо, доступ в этот раздел есть, был по крайней мере, поищу там.
sky star, вашу схему я, кажется понял: вы с приемников подаете юникастом на модулятор, который помимо QAM ещё вещает и мультикаст...
если честно, то у меня есть некоторые сомнения в целесообразности, вот смотрите, как кто-то здесь правильно написал, UDP (мультикаст) - это броадкаст т.е. если какой-то пакет запоздает или придет битый, он просто отбросится и абонент увидит рассыпание картинки; если же использовать TCP (юникаст), по пакет будет перезапрошен и что в этот момент увидит абонент фриз или пропадание изображение? Думаю второе т.к. QAM - это уже , или я ошибаюсь? И что будет дальше, если ошибок (скажем по видео пиду) будет много, будет происходить рассинхронизация видео и звука?
sky star, что-то меня подобная схема смущает, или я где-то ошибся?

[sky star]

Ну наконец то, опасения однако ошибочны перезапросов не происходит ,
почему рассказывать не буду (хотя бы исходя из того что тот же гармоник позволяет вещать юникаст,
не было бы гарантий качества , тупа не было возможности)
А схема, схема простая, линейная
И не одного меня если посмотреть
http://macatel.ru/forumsmf/index.php?topic=2320.msg51828#msg51828
один я бы мог ошибаться и не замечать фризов или пропаданий,
но вот двое

Фишки юникаста документирована, по этому используется по полной

[sky star]

да и что Вам мешает отправить какой либо канал юникастом в Бриджтех ?
Все у Вас уже там, а один добавить и тупа посмотреть ETR

В 2012 году я схему коммутаций нарисовал очень крутому цискарю (он как раз читал коммутатор станции) будучи на семинаре САТпро,
он отошел пару шагов, еще раз посмотрел, и спросил, а что тебя смущает ?
А сказал что не чего
Потом он сказал что тут проблем не может по логике даже

[atx]

sky star дружище, да никто же не говорит что ваша схема ошибочная =)

имхо, она чутка избыточна, ведь мультикаст можно отдавать сразу с приемного шасси - это в принципе его основной функционал, принять + обработать + отдать потребителю, иначе нафиг вся эта 3G-платформенность? =)

ваша схема слегка напоминает мне мой старенький добрый  Scientific Atlanta D9624 ASI-ремультиплексор со встроенным IP-стримером,
где заводилось все по "юникаст" ASI и выдавалось по "мультикаст" IP.

и еще вопрос, а как вы будете при вашей схеме РТРС-мультикаст заводить? на отдельный порт EMR (лицензия стоит не копейки)?
Ведь просто воткнув его в ваш L2 коммутатор, его не получиться принять без нахождения IP-интерфейса EMR с IP-интерфейсом РТРС (выделенном для вас) в одной IP-подсети. мультикаст просто не польется к вам, т.к. не знает куда =), т.к. собственно сам PIM ничего не маршрутизирует, а только строит путь от потребителя к источнику, маршрутизацией занимается протокол обычной unicast-маршрутизации.

[sky star]

как я завел все внешнии источники , так и сейчас беру с ОРТПЦ сигнал оцифрованного аналога для IP-PAL ,
в тоже волокно вдуют РТРС 1 и РТРС2 и все будет так как работало пару лет назад

[sky star]

Все "местное" все такое вшивое, по этому за имя надо ухи держать в настроенном состоянии,
они могут и битрейт поднять, и пиды поменять, и могут жахнуть в место mpeg2 пульнуть mpeg4,
надо короче бдить, шлюз в этом случае прям меня выручает
Все сделано тоже три года назад было, и сейчас только растет предложение "возьмите нас пожалуйсто"
По этому я тут готов был задоооооооооооооооо ооооооооооооооооооо ооооооооооооооооолг о до РТРС1 & РТРС2

[skarxxl]

Ну наконец то, опасения однако ошибочны  перезапросов не происходит, почему рассказывать не буду

лучше расскажите т.к. отличие юникаста от мультикаста как раз в том, что есть возможность проверить доставку пакетов и в случае необходимости перезапросить её.

[1076]

если же использовать TCP (юникаст), по пакет будет перезапрошен и что в этот момент увидит абонент фриз или пропадание изображение?

Не  увидит,  размер  буфера ,  как  правило  несколько  секунд,  за  это  время  пропавшие  пакеты  будут перезапрошены, но к мульти(уни) касту это  отношения уже не  имеет.

[skarxxl]

Не  увидит,  размер  буфера ,  как  правило  несколько  секунд,  за  это  время  пропавшие  пакеты  будут перезапрошены, но к мульти(уни) касту это  отношения уже не  имеет.

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